A new backend project is on the horizon, and with every new project come new challenges and opportunities. You can implement everything in a way that fits your needs and the project’s goals, but every decision comes with its pros and cons.

Modern software development moves fast, and since your last project, the technology landscape has changed, while libraries, services, and frameworks might have improved drastically.

Questions you may face include: should you build something new from scratch, leverage code from previous projects, or choose something completely different as a base?

Different approaches will deliver various benefits—you might want to save yourself time, or you might choose to go for more flexibility. This article will help you to find the right direction for your given project.

Building your backend from scratch

The most low-level approach is building everything from scratch. But even this has a wide range of possibilities, with some tech companies producing everything from the ground up—hardware, firmware, operating system, web servers, etc.

Pros:

You get to choose everything, meaning maximum flexibility. If you need every ounce of performance you can get, build your system with C or Rust. If you have special security requirements, choose a hardened Linux distribution or Docker image.

Cons:

When you’re building an application from scratch, you will spend most of your time on undifferentiated heavy lifting. This covers everything from authentication, authorization, and identity management to over-sorting, filtering, data validation, and more.

You will also spend a significant amount of time on non-functional requirements. To run systems in the cloud in a controlled way, you need to implement observability and error reporting.

Building this all by yourself can lead to you losing focus on actual business problems very quickly, and even if not, it will still slow you down.

Using templates from past projects

If you’re building the same types of backends again and again, you’re in a lucky spot. This recurrence lets you use boilerplate code from your past projects.

Pros:

No need to start from zero; just copy the code and replace the functional parts of the system.

This also lets you copy the experience encoded in the modules and libraries you’ve built over the years. You don’t need to explicitly think about what exactly you did back when; it’s all there, right in the source code.

Cons:

The problem with this approach is that you now have two codebases that are very similar but distinct. And since you copied the code, you copied the bugs as well, so you need to apply the same fixes to both of them.

Furthermore, you’re copying the old versions of libraries used to build a previous system. While they might be good enough in most cases, this can lead to bugs and difficult maintenance.

Using boilerplates

This approach is like the previous one, but you copy somebody else’s old project instead of your old project. There are many such boilerplates on GitHub that are maintained by communities. Some are very basic, like a Node.js REST API boilerplate, while others are higher level and include frameworks like Express and Socket.IO.

Pros:

The advantage here, versus copying your own backend project, is usually that those boilerplates are made to be copied and thus easier to fit to your task. And since communities maintain them, you get the aggregated experience of many people, not just you or your team. The many eyes looking over these projects lead to bug fixes and library updates, meaning you can get better quality without doing any extra work.

Cons:

The downside of this approach is that it is more generic than your own past projects. The code will not be tailored to your needs but made for a vast number of developers. This might require you to do more integration work and adjustments. Also, you know your code, while a new boilerplate can come with a considerable amount of code, which you’ll need to learn.

Then, there’s the downside of your own codebase copy—after you copy the boilerplate, you’ll have to maintain all the parts that changed from the original.

Using frameworks

Frameworks form the foundation of many modern projects. You can use them when building from scratch or get them alongside a boilerplate that sets up the basic project structure.

Pros:

Like boilerplates, frameworks come with the experience of other developers baked in. But unlike boilerplates, they do this with a package that other people will maintain. You simply update the dependency in your project when bugs are fixed and don’t need to keep track of changes to your code.

Cons:

Frameworks prescribe some structure for your project because they are often opinionated. Your project structure will look different if you build your system with NestJS instead of Sails.js.

Frameworks often have their own terminology and way of doing things as well, which might not be easy for newcomers to grasp. Sure, you know what an API endpoint and a URL are, but do you know what a resolver or a mutation is? You’ll need to learn these things to be productive with a new framework.

Another factor to consider is that if you don’t copy a boilerplate for the framework you’re using, you’ll still need to write some non-functional boilerplate code yourself.

Using Amplication

Amplication is the fast alternative to the approaches mentioned above. It lets you, the developer, configure the data models and relations with a UI or CLI, and it generates a functional backend code with Node.js, NestJS, Prisma, Postgres, Docker files, and more.

Pros:

Amplication lets you configure role-based access control, application data models, and other configurations using a graphical data-model editor or a CLI.

The generated code is pushed continuously to a Git repository. Hence, as with any code, you have complete control over the generated code, and you can customize and extend the code as you wish.

Unlike any other boilerplate solution, the code generated by Amplication includes all the specific models and DTOs your application needs, including data validation, types, and the relation between models.

The code is generated with authentication, authorization, filtering, sorting, pagination, logging, and docker files—it even has formatting and linting rules.

You can select between a GraphQL API, REST API, or both. Plus, you can get a fully functional admin UI for CRUD operations on all your data models, including relations.

Amplication is built around well-known frameworks and libraries, so it comes with the experience of many developers, not just the Amplication team.

With Amplication, you are the owner of the generated code, and you can use it and deploy it any way you like.

Cons:

The code generated by Amplication is highly opinionated, with a specific technology stack, which may not be a good fit for all use cases.

Summary

[There are many different approaches to building your new backend project.]( Depending on your requirements, you can go as deep as you like and build everything from scratch to get maximum flexibility. On the other hand, the open-source ecosystem is extensive, so there might be some boilerplate or framework out there for you to save both time and money.

If you want to move fast and still be flexible in the future, Amplication is a solid alternative. It allows you to build your application by writing minimal code for the infrastructure while focusing your efforts on writing business logic from day one.

Read one of our tutorial articles to get started.