Tech Talk

Backend Controlled Forms & SSR

Startappz

Startappz

— 4 min read

Backend Controlled Forms & SSR

LET’S GENERALIZE THE APPS

The modern web app has a few standard significant pieces:

  • Frontend
  • Backend
  • Database

In the modern web development world, most of the front and backend communication is carried out via REST APIs. The fundamental mechanism of all web apps is pretty typical:

  • The frontend makes a REST API call to the backend
  • Backend reads the request and decides what to fetch from the database
  • Backend fetches data from Database
  • The data is sent to the frontend
  • Frontend reads the data and renders the UI

So, the thing in question is point 6 - “Frontend Reads the data and renders the UI.” Again, this rendering can be of multiple types - 

  • Tablular data
  • Image, document and other types of binary payloads
  • User profile.
  • FORM
  • Etc.

For this blog post, we will focus on FORMS with an example. 

Suppose there is a web app that has the requirement of having 100 pages, each having a different type of form.

Let’s calculate the work done by the frontend engineer:

  • Create 100 pages
  • Create 100 Forms
  • Add handling for 100 forms submission

(Let’s assume that time taken for the entire frontend development is 50 hours (30 minutes per form))

Work done by backend engineer:

  • Create 100 API endpoints to serve forms (Or one API filling 100 forms as per the configuration)
  • Add handling of 100 forms submission

(Let’s assume that time taken for the entire backend development is 50 hours (30 minutes per API))

You can see that the total development time, in this case, totals up to 100 hours. From the architectural point of view, it will look like this:

On top of that, if a new change is requested or a new form is added, that will add extra development cost (It is not that scalable).

ENTER THE BACKEND-CONTROLLED FORMS

What is a JSON form?

Many libraries can render complete, fully functioning forms based on JSON schema. You can get a list of such libraries here.

How does it work?

JSON data is associated with NoSQL. They don’t have a structure. JSON Schema is an IETF standard providing a format for what JSON data is required for a given application and how to interact with it. This structure is enough to get the application running. These JSON Schemas can be stored in the backend and served to the frontend.

Let’s reevaluate the given task with the above new data:

Work to be done by Frontend Engineer:

Create one page with a JSON schema-based form renderer

Create one submit API handler

Estimated work: 5 hours

Work to be done by Backend Engineer:

Create one API to serve JSON schemas

Estimated work: 10 hours

Agnostic work (Can be done by either Frontend Engineer, Backend Engineer or independently by the business Analyst):

Create JSON schema for 100 forms

Estimated work: 10 hours

Thus, you can see that the work has been reduced by 75% 🎉

But every coin has two sides - JSON forms can shine where the UI is functional using standard HTML elements. At the same time, JSON form can add complications where the designer has added custom nonstandard form controls. Some libraries extend the functionalities of the JSON forms. In the worst case, a custom form that does not use JSON forms can be developed.

Talking about the benefits, adding a new form is just as easy as adding a new schema. The front-end work is reduced to zero.

SERVER-SIDE RENDERING

The concept of Server Side Rendering is not new. Adding Server Side Rendering in this setup can speed and secure the system.

What is Server Side Rendering?

Modern Web Apps use REST for communicating with the Backend Server. The entire front end resides in the user’s browser. If the app grows too big, with complex UI, navigation, images, and app state, the front end can be pretty heavy. Though there are solutions such as code splitting, dynamic imports, etc., they can add extra complexity to the app.

On the other hand, Server Side Rendering uses the power of both the client browser and backend server. The SSR-powered apps keep pre-rendered pages on the server. When the client requests, the backend server simply serves the pre-rendered page. For dynamic functionality, almost all the SSR-enabled frameworks provide the feature of hydration.

Back to the original problem

If we apply the concept of SSR in the 100 forms problem, then there will be only one page in the front end, which will be server-side rendered, thus increasing its speed.

Epilogue

A few years ago, JSON-based forms were not that promising, as the Frontend was evolving as well as the concept of NoSQL. But now, we are living in a world ruled by JavaScript. Such architecture can make the application highly scalable and efficient while reducing the development cost.

Read more