Microservices + Micro-frontends + Modular UI
Three layers the CLI scaffolds together: services own data, remotes own UI surfaces, host owns session and composition. SnapNGo keeps those cut lines aligned so adding a module does not fork the architecture.
Three cuts, one map
- Microservices — HTTP ownership boundaries (auth, billing, domain MS)
- Micro-frontends — independently buildable remotes loaded by the host
- Modular UI — shared tokens/components so remotes feel like one product
Alignment
Host shell ──loads──► Auth MFE · Billing MFE · Domain MFE
│ │
│ ▼
│ api-gateway
│ │
└──────────────────► matching MS (auth / billing / domain)
Shared: @snapngo/* contracts · product UI package
Why align the cuts
If the UI is a monolith but the backend is microservices (or the reverse), every feature crosses political and deploy boundaries. SnapNGo treats a “module” as optional UI remote + service + package surface that can ship together.
Lab path
TanStack host + remotes against a real gateway/auth (and domain MS when present) — federation learning without fake backends for the happy path.
Same names on both sides of the gateway: auth MFE → auth MS, catalog remote → catalog MS. Shared packages keep headers and error shapes aligned across remotes and services.