The problem
A lot of small backend projects mix HTTP handling and business rules in the same route handler, so the logic is hard to test and hard to move if the framework changes. I wanted an e-commerce API where the HTTP layer stays thin and the rules that actually matter, what a cart can hold, what an order needs, live somewhere they can be tested on their own.
What I built
CloudBackend is a working pre-deployment prototype, not deployed to production. It keeps requests, controllers, services, and data models in separate layers, and routes every request through validation before it reaches business logic.
Authenticated accounts
Signup and login validate input, hash passwords with bcrypt, and issue a 1-hour JWT.
Product management
Products support full CRUD, an approval state, and filtering.
Carts and orders
Carts enforce quantity limits before an order is placed.
Manual test coverage
HTTP request files exercise every endpoint by hand ahead of automated tests.
How it works
A request passes through a validated Express route into a controller and a service layer, which is the only layer allowed to talk to the Mongoose models and MongoDB.
Tech stack
- API
- Node.js: Runtime
- Express: HTTP routing and validation
- Data
- MongoDB: Persistence
- Mongoose: Schema and model layer
- Auth
- JWT: Session tokens, 1-hour expiry
What I learned
A backend isn’t production-ready until tests, authorization middleware, and observability exist.
Writing the HTTP request files for manual testing made the gaps obvious: the endpoints worked, but nothing was verifying that they kept working, and nothing would tell me if they stopped.