Skip to main content

BeWith repo relationships — full map

Compiled 2026-08-19 through direct interview with the team, cross-checked against each repo's code, GitHub metadata, and commit history where noted. Some of this — which app is being phased out, where product effort is actually going, product framing like "B2B2C" — isn't derivable from code alone; that's the reason this doc exists rather than just reading each repo's README. File-level and infra claims were true as of the verification date below — re-check against current code/GitHub before treating them as fact for anything deploy-critical.

Consumer-facing frontends​

superco-consumer​

  • What it is: Legacy PHP monolith — the end-user-facing app (as opposed to the backoffice, organization-dashboard). Has its own backend and still owns/manages SQL directly, from before backend-services existed.
  • How it connects: Embeds management-webapp iframes for some components. Embeds facility-rentals via iframe during event registration (see that entry for the exact mechanism). Links to partner-portal via plain URL, not embedding. Calls backend-services for new capabilities being built there — only backend-services touches MongoDB.

consumer-mobile​

  • What it is: Flutter mobile app, the consumer counterpart to superco-consumer. Each city ships as its own separate Android + iOS app built from its own branch (branch names are literal bundle IDs, e.g. io.bewith.emekizrael, io.bewith.banningca), not one multi-tenant app. Limited rollout: 1 US city, ~4 Israeli cities. Built by an external developer (Eli), not the core team.
  • How it connects: Uses backend-services.

leaders-app​

  • What it is: Ticket-scanning app for events — checks in registrations so the system knows who actually attended, and verifies access rights to the event.
  • How it connects: Uses backend-services.

Backoffice (customer/org admins — BeWith is B2B2C)​

organization-dashboard​

  • What it is: The current backoffice for customer (B2B) org admins. Replaces the legacy superco-management ("Shemi's"). The team's heaviest investment over the last few years.
  • How it connects: Uses backend-services (HTTP, not direct DB access).

superco-management — DEPRECATED​

  • What it is: The old backoffice, aka "Shemi" (named after its developer). Nearly fully replaced by organization-dashboard — migration almost done. Barely touched now; do not build new admin features here.
  • How it connects: Talks to both superco-consumer's own backend and backend-services.

Central backend​

backend-services​

  • What it is: The core backend — central hub that virtually every other repo depends on. Owns both databases: SQL via TypeORM (*.entity.ts) and MongoDB via Mongoose (*.schema.ts). It is the only place that touches MongoDB.
  • How it connects: Called by superco-consumer, organization-dashboard, management-webapp, partner-portal, facility-rentals, consumer-mobile, leaders-app, support-tool-frontend, and feature-flags/with-calendar consumers. Exception: legacy SQL access that still lives directly in superco-consumer's own backend, predating backend-services.

sqs-consumer — being phased out​

  • What it is: A sibling microservice in the backend-services family — talks to the other microservices via RPC both ways, sharing copied (not packaged) logger/util code. Was declared "single instance," so schedule/cron triggers were parked here to guarantee exactly-once firing.
  • How it connects: Listens to SQS queues and forwards jobs to the right microservice via RPC. Both roles are on their way out: schedules are migrating to a new platform-jobs system inside backend-services; queue listening is migrating to backend-services' own in-house SQS infra. Likely fully retired once both land — don't build new functionality on top of it.

Embedded / iframe apps​

management-webapp​

  • What it is: A collection of iframe widgets (Event Grid, Calendar, Map, Tickets, Newsletter, External Coupons, Seating Chart, Seats.io Designer, and more — see its dev homepage nav for the full list). Some are embedded internally into superco-consumer; some are meant to be embedded directly on a customer's own external website (public-facing — e.g. an org's calendar of events shown to their own customers, powered by with-calendar).
  • How it connects: Backed by backend-services. Has its own separate seating-chart/seatsio-designer pages — same seats.io integration pattern as facility-rentals, but a distinct implementation. Open question: unclear whether this is leftover duplication, a different use case (e.g. staff-side chart design vs. consumer-side booking view), or a migration in progress. Flagging for whoever knows to fill in.

facility-rentals​

  • What it is: Facility/venue rental management with seat-map booking (seats.io SDK — seating charts, event manager, designer, reservations/availability). Early-stage: still the unedited create-next-app README, and — unlike every other frontend — does not use @bewith-dev/design-system, it's on raw MUI 7 instead.
  • How it connects: Embedded into superco-consumer via iframe during event registration — superco-consumer's components/NewDesignView.php injects a JS_FACILITIES_URL global, and assets/webpack/src/js/libs/seating-info.js iframes {JS_FACILITIES_URL}/seating/seating-reports?seatsioEventKey=... in a modal. The booking itself is created by superco-consumer calling backend-services' v2 API directly (createFacilityBooking), not through the iframe. Org-scoped (organization/[organizationId]) and calls backend-services API v2 directly for its own data.

Standalone apps​

partner-portal​

  • What it is: Standalone Next.js frontend for BeWith Partner Management — where partners apply to join an org's program (features: partner-application, partner-hub, organization, auth). Deliberately separate from organization-dashboard (org-admin side of partner management stays there) and not an iframe app like management-webapp.
  • How it connects: Calls backend-services API v2 directly (NEXT_PUBLIC_BACKEND_V2_URL). superco-consumer links to it via plain URL/CTA, not embedding. Uses @bewith-dev/design-system.

support-tool-frontend​

  • What it is: Internal tool for the support team only, super-admin access. Held to a lower engineering bar than customer-facing apps — internal-only, not production-grade.
  • How it connects: Talks to backend-services' internal gateway.

Shared packages (npm, not services)​

design-system​

  • What it is: Shared @bewith-dev/design-system npm package — theme + UI primitives, MUI/Emotion-based.
  • How it connects: Consumed by essentially all frontend repos — confirmed in management-webapp, partner-portal, organization-dashboard, support-tool-frontend. Notably not used by facility-rentals, which is on raw MUI instead.

with-calendar​

  • What it is: @bewith-dev/with-calendar npm package — the calendar component, built via Vite/tsc in its own repo.
  • How it connects: Powers management-webapp's calendar iframe, which organizations embed on their own external website to publicly display events. Also used in organization-dashboard. No reference found in superco-consumer.

feature-flags​

  • What it is: @bewith-dev/feature-flags — a shared npm package built on the OpenFeature standard, wrapping backend-services as the flag backend (resolves via a /effective endpoint). Ships both a React entry point (/react) and a Node entry point (/node) — explicitly meant for both frontends and backends, one package, one-liner API either side.
  • How it connects: Backend consumers fetch /effective at boot and cache flag state; frontend consumers wrap the app once and call useFlag(). Confirmed adopted in organization-dashboard and backend-services. Not yet found wired into management-webapp, partner-portal, support-tool-frontend, or superco-consumer — adoption looks partial/early (package created 2026-07-02, still v0.x).

Tooling​

migrations-tool​

  • What it is: Manual, one-off migration/backfill scripts — mostly MongoDB, sometimes cross-referencing SQL (e.g. backfilling a Mongo field from a MySQL table). Triggered manually via GitHub Actions workflow_dispatch per environment (us-prod, fr-prod, fr-staging, ir-staging), which builds/runs a Docker image with a chosen command. New migrations are added under src/scripts now; older ones used NestJS CLI-style commands (node ./dist/main <domain> <command>).
  • How it connects: Runs directly against the Mongo/SQL databases owned by backend-services. Separate from routine SQL migrations, which run automatically as part of superco-consumer's own deploy, not through this tool.

Infrastructure​

IAC-Terraform​

  • What it is: Terraform IaC repo for AWS resource provisioning — SQS queues/DLQs, S3 buckets, ECR repos. Created 2025-08-12, actively maintained. The only live SQS owner — 12 queue modules, applies running as recently as 2026-08-05.
  • How it connects: Provisions the cloud infrastructure that backend-services and other services run on. Replacement for the Pulumi-based provisioning that used to live in Kubernetes-deployments.

Kubernetes-deployments​

  • What it is: GitOps repo for k8s — Helm charts (packages/helm-charts, apps/chart) + ArgoCD sync configs (configurations/{prod,staging}/argocd). Actually two branches, not one config: main serves US production (EKS use1-prod), staging serves IR staging (EKS staging) — they've diverged 200+ commits, so any config/env-var change needs a separate PR to each branch. CI auto-commits image-tag bumps (change tag: us-prod-vX.Y.Z) on the relevant branch per deploy; ArgoCD syncs from there.
  • How it connects: Deploys built images from the app/service repos into EKS for those two environments. No AWS infra provisioning anymore — see the deprecated-repos section below.

Deprecated / dead repos​

Worth knowing so nobody builds on them by mistake — some look plausible at a glance, which is exactly the trap:

RepoStatusWhy it looks alive
superco-managementDeprecated, mid-migration to organization-dashboardStill gets occasional touches until the migration finishes
Kubernetes-deployments's pulumi/ folder (not a separate repo)Zombie — deleted from main 2026-08-03, still present on stagingStill attracts dependabot PRs; a queue declared here was never actually created and caused a production incident before Terraform picked it up
with-terraform, cdk-infra, infrastructure, deploymentFully dead, last pushed 2022–2023, no CI runsPlausible-sounding names for infra repos that no longer do anything
sqs-consumerNot dead, but both of its jobs are actively migrating into backend-servicesStill running in production today — don't extend it, but don't assume it's already gone either

A stale local git clone hides all of this — pulumi/ looks alive in any checkout that predates its removal, because the files are still on disk. Always git fetch and check origin/main (or the relevant branch) before trusting what a local clone shows for any of the infra repos above.

For environment-by-environment infra detail beyond this doc's scope — which branch/file each deployment actually reads, live-vs-dead evidence with GitHub run history, and commands to re-verify — see the bewith-provision-sqs-queue skill's references/environments-and-repos.md.

Re-verifying​

# Confirm a repo's last real activity (not a stale local clone)
gh api repos/bewith-dev/<repo> --jq '"\(.name) pushed=\(.pushed_at) archived=\(.archived)"'

# Confirm whether a directory still exists on the branch that's actually deployed
git -C <repo> fetch origin --quiet && git -C <repo> ls-tree origin/<branch> --name-only

# Confirm which repos declare a given @bewith-dev/* package as a dependency
grep -l '"@bewith-dev/<package>"' ~/source/with/*/package.json

Verified 2026-08-19.