Article

Code

Category: Expert stories

Effective ways to work with Backend

In the realm of front-end solutions, the vital role of back-end applications cannot be overstated. They enable smoother interactions and empower developers to deliver top-notch front-end solutions. In this article, emagineer Kamil Naja delves into the world of backend development, uncovering effective methods to optimize the process.

Kamil Naja, Warsaw, 19. July 2023

To create front-end solutions, we usually fetch data from a back-end application. In this article, I would like to present ways to improve and speed up this process.

The key factors I considered during the analysis were the flexibility of work and whether a programmer using the API could edit the data returned by the back-end.

 

Working with a locally running back-end server

This solution works best for simple back-ends. It involves configuring the back-end application locally (usually with the database), starting it, and connecting to the local API.

One significant advantage is the ability to stay up-to-date with code changes. If we want to use a particular API, we don't have to wait for it to be deployed on the server; we can pull the latest changes and restart the application.

Middle-text-front-end-emagine_2

This approach is also beneficial when working as a full-stack developer, developing both frontend and backend simultaneously. However, the downside of working with a local backend is that modern backends are often more than just a single service. In newer applications, they might consist of multiple microservices, and in long-developed ones, they could have many dependencies. In such cases, locally configuring and running the backend can be time-consuming.

Another challenge could be the absence of data in the database, which might require writing migrations. For example, if we want to test a table displaying a lot of data, we first need to add that data to the database somehow.

 

Using a Docker container for a locally running backend application

Packaging the backend application into a Docker container allows for significant simplification of the configuration process. The container will contain everything needed to run the application, and we can connect to it on the appropriate port, just like with a locally deployed application.

 

The downside of working with a local backend is that modern backends are often more than just a single service. In newer applications, they might consist of multiple microservices, and in long-developed ones, they could have many dependencies.

 

However, one drawback is the additional work required to build the container image. Also, this approach may not allow for as dynamic a reaction to backend changes. For instance, if the endpoint changes, the application needs to be "dockerized" again.

This approach can be combined with a locally running backend. In a microservices architecture, less actively developed services can be dockerized, while actively developed ones can be run locally. Similar data challenges as in the previous approach may arise here as well.

 

Connecting to a backend running on a server

The backend operates in an appropriate environment, and we connect to it from the front-end application. Modern frameworks like Angular allow switching between different backends using proxies.

The advantage of this approach is that there's no need to configure the backend locally. There's no requirement to run a database or install Docker. However, the downside is that changes take longer to be implemented compared to working with a local backend. Every change needs to be deployed, which, in the case of many changes (and slow CI), can slow down work. If we need additional data in the database, it needs to be added there.

Using a mock server

In this approach, we don't connect to a real backend server; instead, we use an application that returns data with a similar structure to the server. The key question is whether such a mock service is developed more on the backend side or using technologies closer to front-end developers.

code illustration

Mock on the backend side

If the backend application utilizes various APIs and returns them for the frontend application without having a database, then the mock can be organized in the form of a backend application. It simulates responses from multiple services and returns data, for example, in the form of JSON files. During work on higher environments, the mock server connected to the backend is automatically replaced by connections to real services.

This solution is less dynamic from the front-end perspective, but it allows for effective testing using Selenium, for example. Editing data can be straightforward as it can be done with simple JSON files. I've also come across a backend mock service containing basic logic for data storage. Of course, the more complex such a server is, the more time it will take to develop.

Mock server on the frontend side

In this approach, we can receive some data from the backend and use them as mocks, or generate data based on the API documentation. A good approach here could be using a data generator, such as faker.js. Data can also be copied from Swagger Schemas examples.

This solution is beneficial because it enables rapid changes to response data. As a result, on the frontend, we can test the application's behavior with:

  • Responses longer than usual
  • Different response codes (including errors)
  • Missing data (empty response)
  • Different response times

Such flexibility cannot be found in any other approach. A real example of why such a mock server is useful is when resolving errors. If a user encounters a frontend error in a certain scenario, it is possible to copy the JSON file used during the request from the environment and mock it locally. This usually allows for reproducing the error.

The mock server has a drawback - it is not a fully functioning backend application. For example, if a new piece of data is added, the server will not react in a standard way and will only return additional data if we mock it accordingly. This should not be a problem for a more experienced developer.

 

  An example of an application that allows creating a mock server is node-mock-server. Writing a similar project in node.js should take little time, but its development can be time-consuming. It is necessary to mock all endpoints, but once the data is mocked, it can be reused multiple times.

 

Read also:
AI support in the development of front-end solutions

Ready to grow?

Get help with your CV and profile and be found for rewarding projects.

Register your profile