Backend developers: How to start down the career path

Have you ever wondered what it would be like to join the dark side of the force? Have you ever imagined fearlessly traversing the galaxy on board of a stormtrooper, discovering new worlds and building powerful Death Stars? It sounds tempting and scary at once. At Concise Software we believe that the dark side of the force is not that bad, as this is what we call backend development.

Anyway, our Backend Developers are not afraid of it.They are more like Jedi Knights following the Jedi Code, a set of good practices and rules, and conquering their dark side through their skills and tools. 

If you want to learn how we embrace “the dark side” and start down the career path of a backend developer, we are happy to share our knowledge about the tools and practices that are applied at Concise Software to develop high-quality backend solutions.  

The dark side of the force

The leading technology of “the dark side of the force”, as we usually call backend at Concise Software, is JavaScript running in Node.js environment. Our backend developers work on projects using Express, usually NestJS, which is, by the way, a framework based on Express/Fastify. We take advantage of TypeScript to make development more fun and ensure that the code is easy on the eye. We test all our solutions by unit testing with Jest, the top JavaScript testing library.

When creating a project, our backend developers take a modular-layered approach so that development and maintenance of an application does not look like Mission: Impossible. Code that is created in such a way goes through three stages of verification: code review, syntax checking and running unit tests with CI, as well as manual tests performed by a tester. We automate everything as much as possible. Thanks to containerization with Docker, our work environments are consistent. The backend developers keep track of code versions using GIT, while repositories are located in the internal GitLab.

The dark side is not that bad. Please accept these flowers from Darth Vader as encouragement and keep reading.

Stormtrooper equipment

When you decide to join the dark side of the force at Concise Software, you need to equip yourself with basic stormtrooper tools. So what do you need? You certainly need Node.js and npm. Their version, however, depends on the project backend developers are involved in. Therefore, we recommend that you take on board e.g. nvm, which is easy to use when you need to change versions. 

It is obvious that you need a suitable work environment. We do not have specific rules, but we recommend Visual Studio Code or PHPStorm which we have a license for. In addition to IDE, another must-have is Docker, since most environments are containerized ecosystems. Thanks to Docker you don’t need to run a local database instance or a queue. Instead, you can take advantage of ready-made images.

And while on the subject of databases, you will need a client that allows you to introduce changes and read data easily. There is no point in bothering yourself with the SQL console, though you are free to use it if you wish to do so. There may be more than one solution, but we recommend DBeaver that supports many database systems, including NoSQL.

Another mandatory element is the REST Client allowing you to test APIs manually. No one can prevent you from using cURL, however we strongly recommend working in friendly environments. Most of our backend developers use Postman, but we are happy with Insomnia as well. 

As mentioned at the beginning, we use GIT for software versioning. In this case, the console is sufficient, but it would be advisable for more demanding users to take advantage of IDE plugins or a dedicated GUI software.

• JavaScript: https://developer.mozilla.org/en-US/docs/Web/JavaScript
• Node.js: https://nodejs.org/en/
• Express: https://expressjs.com/
• NestJS: https://docs.nestjs.com/
• TypeScript: https://www.typescriptlang.org/
• Jest: https://jestjs.io/
• CI/CD: https://www.redhat.com/en/topics/devops/what-is-ci-cd
• Docker: https://www.docker.com/
• GIT: https://git-scm.com/
• GitLab: https://about.gitlab.com/ 
• nvm: https://github.com/nvm-sh/nvm 
• Visual Studio Code: https://code.visualstudio.com/ 
• PHPStorm: https://www.jetbrains.com/phpstorm/ 
• DBeaver: https://dbeaver.io/ 
• Postman: https://www.postman.com/ 
• Insomnia: https://insomnia.rest/ 

Building a Death Star

In our daily life, we tend to categorise things in order to make it easier for us to get organised and to work. We divide into categories literally everything: we have an HR department and an accounting department, we have companies specialized in alpaca breeding and businesses selling Star Wars action figures. What we want is one specialized fragment of a larger whole to do only what it knows best and what it does best. Backend developers can take the advantage of the same approach in software development, as all the logic related to a specific issue is concentrated within individual blocks. Imagine the situation, where in case of errors or a need for new functionalities you don’t have to wander around the entire system, but you just open a module directory for the respective logic.

Having a modular architecture is not yet the key to success. Modules must be transparent to each other. After all, a company selling Star Wars figures can buy itself an alpaca for a corporate mascot. It may or may not be aware of who fed the animal or in which cage the alpaca was held until it was purchased. The same applies to application modules, because Death Stars’ creation model is not allowed to know how to create an employee’s access password, but must be able to verify this employee using a mechanism shared externally by the employee module. The module A can only see things that the module B has made available to others for use.

We are now modular and have divided our responsibilities appropriately, so that basically each block has a role to play. But what happens inside? We provide a structure which looks beautiful from outside, but internally things are happening which physiologists have never dreamed of. The remedy for such a problem is another division, this time inside the module in the form of … layers. After all, ogres have layers, onions have layers and … modules can have layers too.

Layers set the boundaries of the data flow and the logic within a module. The method of communication between layers depends largely on the architectural pattern. Due to the fact that at Concise we most often use MVC, we can point to three major layers: UI layer, logic layer and data access layer.

The user’s query goes first to the UI layer, where it is validated, enabling a mechanism for implementing business logic. In the simplest case, it will be a service class that stores data with use of DAL (data access layer) after performing its task. The data access layer is at the lowest level, where the actual communication with the database, file system or other location takes place. The process is shown on the diagram below. 

Going deeper we come across the code. The software quality is manifest both in simplicity and purity of the written code. In order to provide high-quality solutions we have developed effective combinations of design and architectural patterns. We recommend using reliable and proven solutions , as well as following mainly the principles of SOLID and GRASP, which are considered the Holy Grail of successful project work. In addition, there are also several recommendations facilitating the development and maintenance of software like creating reusable components and their simplicity.

Jedi library for backend developers

At Concise we all try to improve our skills constantly in order to create robust products that developers want to come back to. There’s no other way to bring it off than learning continuously. You will find below a list of issues Backend Developers should be familiar with. Have a great read!

1. Construction plans of Star Destroyers

• Model View Controller: https://www.youtube.com/watch?v=DUg2SWWK18I 
• Domain Driven Design part 1: https://concisesoftware.com/domain-driven-design/
• Domain Driven Design part 2: https://concisesoftware.com/domain-driven-design-discovering-domains/
• Domain Driven Design part 3: https://concisesoftware.com/domain-driven-design-domain-building-blocks/
• Domain Driven Design: https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
• Modular Monolith: https://www.youtube.com/watch?v=5OjqD-ow8GE 
• Event Sourcing: https://www.youtube.com/watch?v=8JKjvY4etTY 
• Event Driven Architecture: https://www.youtube.com/watch?v=STKCRSUsyP0 

2. Jedi Code of Backend Developers

• SOLID: https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design 
• GRASP: https://en.wikipedia.org/wiki/GRASP_(object-oriented_design) 
• Code reusability vs. programming principles: https://concisesoftware.com/code-reusability-vs-programming-principles/ 

3. Building R2-D2

• Factory Method pattern: https://refactoring.guru/design-patterns/factory-method 
• Adapter pattern: https://refactoring.guru/design-patterns/adapter 
• Decorator pattern: https://refactoring.guru/design-patterns/decorator 
• Facade pattern: https://refactoring.guru/design-patterns/facade 
• Strategy pattern: https://refactoring.guru/design-patterns/strategy 
• Command pattern: https://refactoring.guru/design-patterns/command 
• Repository pattern: https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design 
• Proxy pattern: https://refactoring.guru/design-patterns/proxy

You may like to read:
Backend Developer vs Frontend – differences and responsibilities
The Skills You Need to Be a Back-End Developer
QA in software development – everything you should know
10 frontend developer skills the market wants right now