Apparule turns two phone photos into a complete, private body-measurement profile. Commission Lagos designers who sew to your measurements — no size charts, no guesswork.
CommerceDart · TypeScriptGitHub @cuesoftincOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Apparule Monorepo
Translation pending
Taken from the repository README
Loading the full README.
Read the full README ↗Fashion body-measurement and social-commerce platform — capture body measurements from a phone, keep them in a private vault, and commission outfits from designers with a frozen copy of your measurements.
Apparule is a monorepo containing the clients, backend services, deployment configuration, and documentation for the platform. A Go service owns the product API and all data, a Node gateway takes uploads, one Python service turns two phone photos into body measurements and another makes every payment decision, and a Next.js frontend serves the marketing site and user dashboard. The services talk over the shared Kafka. For the components and how they fit together, see docs/overview.md and the system design.
flowchart LR
subgraph clients
WEB[web + dashboard<br/>Next.js, App Hosting]
MOB[Flutter mobile]
end
GS[Google sign-in<br/>OAuth, Google only]
subgraph server["GCP Cloud Run (scale to zero)"]
AC[api/common, Go<br/>CRUD]
UP[api/uploads, Node<br/>upload gateway]
SG[api/segmentation, Python<br/>pose QC · measurements]
CM[api/commerce, Python<br/>payments · notifications]
end
subgraph data
PG[(managed Postgres)]
CS[(Cloud Storage)]
RD[(managed Redis)]
K[[shared Kafka]]
end
WEB --> GS
MOB --> GS
WEB --> AC
MOB --> AC
WEB --> UP
MOB --> UP
AC --> PG
AC --> RD
UP --> CS
UP --> K
AC <--> K
K <--> SG
K <--> CM
| Layer | Technology |
|---|---|
| Backend API | Go 1.26, Postgres with row-level security (api/common) |
| Upload gateway | Node 24, NestJS, sharp (api/uploads) |
| Measurement | Python 3.12, MediaPipe, OpenCV (api/segmentation) |
| Payments | Python 3.12, Paystack, FCM, Brevo (api/commerce) |
| Messaging | Kafka (a shared managed Kafka service) |
| Web | Next.js, React, TypeScript |
| Mobile | Flutter (primary), native Android/iOS |
| Auth & data | Google-only sign-in (session JWTs from common); managed Postgres (system of record) & Cloud Storage; shared managed Redis |
| Infrastructure | Docker, Helm, Terraform, GCP Cloud Run |
api/
common/ Go, the product API, the only Postgres client; Kafka contract
uploads/ Node, ticketed upload gateway
segmentation/ Python, pose QC and body measurements
commerce/ Python, payment decisions, push and email
web/ Next.js marketing site + user dashboard
mobile/
flutter/ Flutter app (primary mobile client)
android/ Native Android (Kotlin)
ios/ Native iOS (Swift)
deploy/
docker/ Container/compose configuration
helm/ Helm chart (deploys all services to Kubernetes)
terraform/ Infrastructure as code
docs/ Project documentation
scripts/ Developer and CI helper scripts
Additional services follow the same convention: api/common is the shared Go
backend, and every other service lives under api/<service-name> named by its
function (never by its language).
cp .env.example .env
make up # build + start the stack: web (:3000), common (:8080), segmentation (:8081),
# uploads (:8082), commerce (:8083), plus Postgres, Kafka, Redis, S3
make logs # follow logs
make down # stop
Configuration is provided at runtime via environment variables (names in
system-design.md §10.3); the compose defaults need
nothing but the local-only ticket key pair already in .env.example. See
docs/setup.md for details; make help lists all targets.
Never commit credentials or bake them into an image.
Hosted docs — the full documentation site (auto-synced from docs/)
Project overview — architecture and components
System design — services, transports, data ownership, flows
Local setup — development environment and per-service run commands
Contributions are welcome. Please read the Contributing guide and our Code of Conduct before opening a PR.
Please report vulnerabilities privately — see our Security policy.
See LICENSE.