Newmew — eyewear e-commerce backend
Three NestJS services from one codebase: storefront API, admin API and an outlet inventory sync service.
Background
Newmew sells spectacles online and in physical outlets. Products have variations, lens prices and customer prescriptions, and stock lives in outlet POS systems that need to stay in sync with the web store.
The problem
Stock truth lives in the outlets, not the web store. Overselling a frame that was sold in a shop an hour ago is the failure the client cared most about. The storefront, the admin panel and the sync worker also needed to share business rules without deploying as one monolith.
Approach
- One NestJS codebase with three entry points: client, admin and sync. Shared Prisma schema and services, separate guards, decorators, Dockerfiles and PM2 processes.
- A sync service that reconciles inventory, variations and transactions from outlet POS data on a schedule, with a sync log row per run for support to inspect.
- Domain model for eyewear: prescriptions stored per user, lens prices attached to variations at checkout.
- eSewa payments, vouchers, Redis-backed recently-viewed and caching, Google and Facebook OAuth via Passport, Brevo transactional email, admin stats.
- Swagger spec drives the storefront's generated client. Dev and prod Docker Compose.
Architecture
client.main.tsStorefront API.
admin.main.tsAdmin API and stats.
sync.main.tsOutlet POS reconciliation worker with sync logs.
new-mew-nextNext.js storefront. Team-built.
Outcome
- Backend staged at staging.api.newmew.com and handed over with all three services containerised.
Lessons
- Multiple entry points on one Nest codebase is a good middle ground between monolith and microservices for a three-person project.