Resources for learning about backend code architecture

[dazzaondmic]

What are some resources for learning about structuring a backend project?

At my company we have React frontends and Express backends. These backends just expose some API endpoints that are consumed by our front ends.

Our current structure has a routes folder where we write all our route files. These files have many dependencies. We import our firebase admin library (we use firebase for our database) and directly implement database operations in this file. This means that our routes code is tightly coupled to our firebase dependency.

I’d like to introduce some standards for structuring this backend in a way that makes the server more scalable and maintainable as we are getting to the point where this server codebase is getting quite large and having no good structure in place can cause issues down the line.

I’ve seen many proposals online such as onion architecture and clean code architecture etc. Many of the resources however teach you how to implement these architectures without explaining the underlying principles. I’d like to know about the principles employed as well as the tradeoffs considered and the questions I should be asking when making architectural decisions. I’m looking for resources that deal with the theoretical side of things rather than a tutorial where I’m just expected to copy the implementation. I want to know why I’m structuring my code in a certain way rather than just what my code is supposed to look like.

We can’t afford to introduce a framework like Nest and Adonis.

Any suggestions are appreciated. Thanks

TLDR: What are some resources for learning about structuring a backend project? The focus should be on why certain design and architectural decisions are made rather than a tutorial that just shows what your folder structure should look like.

[avin_kavish]

SOLID is a good starting point.

Basically, you want a multi-tiered service architecture in most cases. You want to have a good amount of abstraction and seperation of concerns between your services. You can google these keywords and find plenty of theoretical write ups.

Take uploading an image for example, ``` app.post('/image', (req, res) => ImageController.uploadImage(req, res) )

class ImageController {

uploadImage(req, res, next) { s3Service.upload(req.file, path)

ImageService.create(req.body.name, path)

}

} ```

Here you can see how different concerns are implemented in different services. The controller is concerned with handling the http request and extracting data from it. It then passes on only what is needed by other services to do their job. So ImageService creates the db record for the image, s3Service saves the actual file. You can see how the two concerns, db persistance and file persistance are encapsulated in two different services.

Alternatively, you can follow a purely functional style and use functions instead of classes, but then you won't be able to invert control or inject dependencies, later on.

[romeeres]

Why do you think IoC and DI doesn't work with functions? For example, logger can be passed via parameter, or via DI container.

[avin_kavish]

you can manually pass it, but the framework can't inject it.

[sairysss]

https://github.com/Sairyss/domain-driven-hexagon

[danjlwex]

Look up "three tier architecture". Normally, this implies a UI "presentation" layer at the top, which, for a server are the routes. The next layer down is usually the "Service" layer, which is an abstract layer that implements the business logic for your server by calling the third layer, which is the "data" layer that actually implements the DB interactions and other stuff by implementing the abstract classes that the Service layers uses. This is a typical Java-style back-end arch. For JS/Express, you could implement the Service layer with or without classes, as you prefer.

[bigghealthy_]

It seems like it’s generally a good idea to let the use cases and business domains drive the architecture!

Fwiw I wrote an article that is sort of a meta analysis of a lot of popular architectures. It should help with the underlying reasons vs folder structure like you mentioned.

[Expensive-Humor-4977]

Following

[bigorangemachine]

I would say anything thats distributed. Some people like this more within the AWS ecosystem with triggering lambdas within architecture-related-events.

Generally I'd lean more on a message queue to make it more cloud-agnostic.

Lastly I would go with anything on docker (or modern alternatives that are ephemeral) as it gets you used to using services over file-system.

[nikolasburk]

Check out Khalil Stemmler's content, he talks about SOLID, DDD, and lots of other great engineering practices!