DEV Community

Cover image for Front-end must be dumb
Duca
Duca

Posted on

Front-end must be dumb

One of the problems I faced recently was the need to make the front-end application I am working on more dumb.

Responsibilities

The main need that moves us to create a dedicated back-end is to separate its responsibilities and methods from the front-end.

Think about this: your front-end is messy almost every time, and this may be a red flag to make you rethink about how much do you trust in your front-end.

Personally: I do not trust a bit on mine front-end applications, and this is why we need to make sure that the back-end is the smart one with more responsibilities.

webdev structure schema

Splitting applications

Let us suppose this scenario: your front-end does not have a service API layer, which means that your requests are created directly on the page like this:

sample axios request

If you are creating these requests with no personalized service or a state machine and also using its response data in order to validate a rule or behavior, once you update your endpoint, entity or DTO, you will need to go at each one of the requisitions and change their behavior manually, so it can now work along with the new changes.

Yin-Yang

Your web application must have its responsibilities well stablished and more importantly: well divided in each one of the endpoints.

Your front-end must be concerned on rendering the visual aspects of the application and your back-end must be the source of the intelligence of the business.

Once you understand this, let us now try to make the axios request work as it should:

axios request that works along the back-end

This may be a really silly example of how things should work, but you need to focus on the behavior of the front-end: it only receives the information and send it to the user, having zero concern or any further validation about the response.

The back-end side

There are some things you need to consider while creating a resilient back-end that will not allow any unwanted information or payloads to reach the front-end:

  • Early return - get rid of those elses. your code legibility will be much superior after using early return.
  • Try/catch - make sure that your back-end will be prepared for all of the known issues that could happen.
  • Observability - your unknown bugs or error reports must go somewhere, and this magical place should be some observability tools.

observability 3 steps

Final considerations

Knowing that your front-end has limitations and your back-end does it as well will change your way of thinking about how web applications should work, and this kind of concern will be very healthy for your development career.

Top comments (0)