All projects
Full-stack · E-commerce
Digital E
An electronics storefront and operations dashboard, connecting discovery, checkout, and order management.
FocusDiscovery, checkout & operations
Project typePersonal project · Jun 2024 - Present
Technology
React
NestJS
MySQL
TypeScript
Prisma
Firebase
Tailwind CSS
Docker
Vercel
Cloudflare Workers
ReactNestJSMySQLTypeScriptPrismaFirebaseTailwind CSSDockerVercelCloudflare WorkersInside the product
Choose a screen, then open it for a closer look.My contribution
What I worked on
Full-stack development · Personal project
- 01
Product experience
Built an electronics storefront and admin experience for product discovery, checkout, order tracking, and store operations.
- 02
API & data
Developed a NestJS API on Express with MySQL as the primary runtime store and Prisma for typed models and migrations; used Zod to validate write payloads.
- 03
Payments & access
Integrated PayOS and cash-on-delivery checkout, Firebase identity, cookie-backed sessions, and role-aware administration.
- 04
Quality & delivery
Verified the client and API with Vitest, Testing Library, database integration suites, k6 profiles, and package-local CI; deploys as separate client and server packages.
01
Overview
Digital-E pairs a React storefront and operations dashboard with a NestJS API. MySQL is the primary runtime store; Prisma supplies typed models and migrations for a partial database projection.
02
The challenge
Search, cart, inventory, payments, and order tracking must stay consistent across the client and API. Guest checkout adds secure order access without requiring an account, while payment callbacks and stock reservations need server-side verification.
03
Engineering approach
Let the server own checkout
Why this choice
The server creates a quote from current products, stock, discounts, and checkout data; the browser return page cannot mark an order paid.
Trade-off
More API and database work on the critical path, but payment and inventory state cannot be trusted to a stale client view.
Record payment events before acknowledging
Why this choice
PayOS signatures are checked and provider events are durably recorded before business state changes are acknowledged.
Trade-off
Recovery and duplicate-event handling add state and persistence logic, while keeping transient failures retryable and replays safe.
Keep SQL and transaction work behind repositories
Why this choice
Checkout reservation SQL and transaction-specific persistence live in the repository boundary while NestJS modules own business orchestration.
Trade-off
A clearer test seam and ownership boundary means extra repository interfaces and mapping to maintain.
04
Product capabilities
Search, facets, filters & product comparison
Guest/authenticated carts and order tracking
PayOS, cash on delivery & optional Stripe
Admin workflows for inventory, orders and promotions
05
System overview
Source-backed architectureDigital E
Implemented structureSource repository ↗A separate React client calls a modular NestJS API; MySQL remains the primary runtime store.
React storefront & admin
REST / JSON
NestJS API · Express adapter
SQL transactions
MySQL
Identity & payments
Firebase Authentication
PayOS checkout & webhook
Based on the current repository architecture and payment/authentication source.
06
Evidence & validation
The repository documents Vitest, Testing Library, database integration suites, k6 profiles, and package-local CI.
The architecture document traces the client, API, primary MySQL store, identity, and payment boundaries.
07
Design considerations
The repository treats MySQL as the primary runtime database and keeps the React client and NestJS API in separate deployable packages. Vitest, Testing Library, k6, package-local CI, and optional OpenTelemetry cover different parts of the delivery path.
gRPC
PostgreSQL
Kafka