I'm building the place-order feature for my first full-stack project, and it's also my first serious experience working on a backend. I'm trying to understand how data moves through the different parts of the application rather than only focusing on what appears on the screen.
At the moment, I've split the backend into an API layer, application layer, service layer, and data layer. The API layer validates that an incoming order is not empty, calls the next layer, and sends the response. The application layer currently passes the request to the service function.
The service layer is responsible for checking whether the customer, products, and quantities exist; applying business rules; creating the order; and triggering the database operation. This currently involves one database lookup to validate the order data, followed by another operation to write the completed order.
I've finished the initial database lookup and am now connecting the place-order button so I can test how the data flows through the backend.
The most difficult part is the abstraction. I have to mentally picture data being passed between functions and layers, which still feels hard to hold onto. At the same time, that is also what I'm enjoying: learning how functions, data, and backend architecture fit together, and making all the small design decisions.
I'd appreciate practical suggestions, especially around keeping the design simple while still leaving room for the project to grow. I'm also wondering whether the application layer is worthwhile when it currently just forwards the call, and how to handle the gap between checking product data and saving the order. For example, the product price needs to come from the database, but that information is needed when creating the final order. A visual way to trace the request through each backend layer would also be extremely helpful.
1 Answer
You may have one layer more than you need at this stage. Since the application layer currently only forwards the call, a simpler flow could be API route → service → repository/data access → database. The route handles the request and response, the service contains the order rules, and the repository handles the database library. You can always add more structure later when a real responsibility appears, rather than keeping an empty layer just in anticipation of future complexity.
For the order itself, don’t trust prices sent by the client. Use the product IDs from the request to load the current product details from the database, calculate the total on the server, and save those prices with the order items. Also, once the lookup and insert need to behave as one operation, put the relevant work inside a database transaction so stock or pricing changes cannot leave you with an inconsistent order.
A simple diagram such as client → route → service → database → response can make the flow much easier to follow while you’re learning.
That makes sense about keeping the application layer only if it has a job to do. I’m still keeping it for now because I may find a use for it as the project grows, but I can see how it adds another step to follow mentally.
I hadn’t considered the gap between the lookup and the insert. I need the product details from the database to calculate the price, so I’ll look into handling that flow within a transaction. A visual trace of each layer would also help me understand what JavaScript is doing as the data moves between functions.