Hey everyone! I’m building the back end for my full-stack project to really understand how everything works together. But I’m hitting a wall, and I can’t seem to find a solid answer anywhere. When I make an API call, how many layers should it really be passing through?
Right now, it feels like a lot. On the front end, a simple PUT request hits Redux to update the state. Then, it might ping the Next.js API router to keep things secure between the front end and back end. Next, it goes to the back end, runs through authentication, then hits the controller, which passes it to a service for business logic. The service then calls the repository for CRUD methods, and finally, the ORM interacts with the database.
The response comes back through all those same layers. And that’s not even touching on middleware or microservices. Is this normal for production apps? It just feels like a ton of performance overhead. Plus, I’m rewriting the same fetches and methods over and over with only slight variations… Anyone else run into this? Should I be doing things differently?
Honestly, that many layers isn’t too bad. You can go even deeper if you dive into microservices, like you mentioned. The layers are there for a reason—keeping concerns separate, making refactoring easier, and giving everyone a common structure. It’s all about predictability. Need a new feature? Sure, you’ll have to touch several places, but at least you know where!
It also makes debugging way easier—you can rule out whole sections of code. Think of it as turning spaghetti code into lasagna. Messy, but it’s all stacked neatly. I usually stick with 4 backend layers myself: App, Lib, Persistence, Infrastructure, and Core. Keeps things clean!
You rarely need to stress about the number of layers on either side of the wire. Don’t invent problems for yourself! Just keep an eye on performance issues when they show up.
Most of the time, it’s because a package is being misused and causing things like nonstop database connections or constant re-renders. Once you find the culprit, you can fix it by adding batching, throttling, or caching, and boom, everything’s smooth again.
That’s the price of good architecture! All those layers keep things modular and maintainable, but yeah, it can be a lot to manage. I’d say this is pretty typical, but you can always experiment with slimming down parts that don’t need all that complexity. Also, in prod, you might use things like background processing to handle some of the heavy lifting behind the scenes.
Sounds like you’ve got the right idea. All those layers are common, but it does feel like overkill at times. You could try using some utility libraries to abstract out those fetch calls, so you’re not writing everything over and over. Look into memoization too—basically caches your data so you’re not hitting the server for everything every time.
Dude, I feel you! The first time I set up something similar, I thought I was doing too much too, but turns out a lot of those layers are necessary. Over time, you’ll learn what you can optimize. One thing that helped me was using an API gateway in prod—cuts down some of those layers by centralizing a lot of the logic.
Yeah, welcome to backend dev! It’s normal for things to start feeling like a maze, especially when you’re dealing with separation of concerns, security, and business logic. But production apps do sometimes get a bit more streamlined. You can look into things like caching to reduce redundant calls, or even try batching requests if it’s making multiple trips for no reason. Definitely think about refactoring some of those layers if you’re seeing repeated code!
Is this normal for production apps? It just feels like a ton of performance overhead. Plus, I’m rewriting the same fetches and methods over and over with only slight variations… Anyone else run into this? Should I be doing things differently?
I usually stick with 4 backend layers myself: App, Lib, Persistence, Infrastructure, and Core. Keeps things clean!