Some absolute truths about React
To begin with, let’s recall what React.js or just React is. React is a JavaScript library used for fast and convenient development of dynamic interfaces that perform various tasks or scripts. When users do something with interface elements, they launch these tasks – the browser sends a request to the server, the server processes this request and retrieves data from the database to let the users see the likes they left in social media, place selected products in online shop basket, overlay effects on photographs in browser editors, view test results and much more depending on the application tasks.
React uses the client-side rendering approach. The browser gets HTML, CSS, and JS files from the server and then sends server requests only for the data needed to render the page interface changes that took place at this specific minute. And what has to be requested from the server if the user, say, hits the Like button on a web page and does nothing else on this page? Right, only the function that will increase the number of likes. This economy of queries and responses reduced the server load. This turns React into a tool used to develop websites which, as their owners hope, will be simultaneously visited by thousands, hundreds of thousands, and millions of people. This approach also allows developers to build only dynamic elements of the site on React, not the entire site.
Websites built on pure React are poorly indexed by search engines due to the client-side rendering but the situation is saved by the server-side rendering approach and the React-based framework Next as the tool that implements this approach.
Compared with standard sites, React-based websites have a clearer architecture. You will read below what this observation means for this post.
And the last moment, which might still remain unclear: can React be used to develop the backend? The answer is no, as this tool is designed only for interface development.
Basic principles of back-end development
Irrespective of whether we choose React or something else for the client part, the general principles of server part development can be boiled down to the following:
- Server technologies are selected depending on the expected number of users, project specifics, and load test results.
The server part is developed using different languages that consume different amounts of server resources. If your project involves high loads or large data volumes, this must be taken into account when selecting the technologies. The budget is also affected – you can scale up a well-designed application almost endlessly, but there are languages which can formulate a business task in such a way as to let it take less resources from the processor and random access memory making the computations cheaper.
- Data is sent between the client and server over HTTP protocol.
Data transmission protocol is the language the computers combined into a system use to communicate. The purpose of these systems determines the choice of protocol. When it comes to data exchange via the Internet, HTTP protocol is used or rather HTTPS as its safe alternative that has already become a sanitary standard.
- The server part of an application is generally written in PHP, Python, Ruby, C#, or JavaScript.
It is only fair to say that none of these languages was designed as the language strictly for one environment – even PHP, which is the most popular language in back-end development. All of them are more or less suitable for the development of all sorts of things: desktop applications, video players, text editors etc. But it is JavaScript that was initially developed as the browser language to program the user’s interaction with interface elements. Later it also became a general-purpose language because of Node.js that turned it into the universal machine code.
One would think that if the client part of an application is written in React, the backend stack should include something JavaScript-oriented, for example, Node.js. Right? Not exactly. When it comes to the backend for an application where the client and the server are separated, the main thing is to define how they will interact.
And so it’s high time to talk about clear architecture.
Clear architecture
Applications with a clear architecture are easier to support. It’s easier to track and eliminate bugs in such applications. When the application is built, the developer controls data streams, layout, and styles and, ideally, knows the programming patterns that allow building applications quicker and more flexibly.
Applications with a clear architecture are characterized by:
- legible code. A new recruit who sees familiar practices will integrate quickly into the project team;
- scalability. Even in the midst of the process it’s possible to make changes or add something to what has already been done;
- optimized operation. A fast application is more attractive than a slow one.
What does the clear architecture mean when we are talking about React apps?
Though the client and the server (the frontend and the backend, respectively) are connected, these are different applications. For the frontend, the details of backend implementation are not as important as API (Application Programming Interface), which is the set of agreements between the client and the server sides concerning the use of certain procedures for some operations with a specific end result. After the agreement is reached, they can be divided and developed in parallel. This is a peculiarity of development in React.
In the pursuit of architectural clearness, the backend and the frontend are often separated because as the monolithic application grows, it becomes increasingly hard to support. Think, for instance, of Drupal, where these parts are closely related. Say, the site has a form where you need to change something, and it’s highly probable that the developer will need to change the form presentation in CMS settings. If the user interface is developed in React, all necessary changes will take place on the client side without involving the server. The same is true for the backend. For example, there is an online store where the logic of discount calculation or delivery has changed. If the frontend and the backend are separated, the developer will make changes in the backend, which will not necessarily affect the representation.
Architectural styles of API and data formats
As we mentioned before, from the perspective of software products architecture, the frontend and the backend are regarded as two independent applications. They communicate through an agreement called API.
So, today’s most relevant API architectural styles are:
- SOAP;
- REST API;
- GraphQL.
Let’s have a closer look at API architectural styles.
SOAP
SOAP (Simple Object Access Protocol) is the protocol web services use to communicate with each other or with clients. Web service SOAP API that uses this protocol serves to exchange messages between servers. Summing up the main drawbacks of SOAP you might say that in order to exchange data, you have to write cumbersome messages strictly in XML format and get one answer to one request. Large messages increase the traffic and, consequently, the server load, which doesn’t make the protocol convenient for the mass use.
Nevertheless, it is still used in in-house corporate applications such as bank applications.
REST
REST (or RESTful) is an architectural style used to create an API with the help of HTTP protocol. The abbreviation stands for the Representational State Transfer. REST API supports not only XML format but also JSON, TXT, CSV, HTML, and instead of a complex XML query you have to pass a correct URL to the client. For instance, if a user wants to view data about a certain product, a click on this product will make the client side form a URL as a server request in order to get the data (GET-request) including the ID of this product. This makes this method easy and clear and reduces the server load and so allows creating high-performance scalable applications.
REST is used in the following situations:
- limited server bandwidth;
- need to cache requests;
- future extension of the project;
- the client and the server communicate by the AJAX method.
GraphQL
GraphQL has different definitions. Some say that this is a query language for API interfaces and the environment where the queries are handled. Others (we, for example) call this the standard description that can be implemented in different ways. In any case, this is the next stage in the evolution of client-server communication and our personal favorite.
As compared with its predecessors, GraphQL has still more specific and economic server requests. When the project involves many resources and uses the architectural style REST API, the client accesses several endpoints. With GraphQL, the client sends queries only through one endpoint and formulates what data is needed and in what format. For example, there is a React application – an electronic equipment comparison website. Based on special rules defined by the GraphQL standard the client sends a data query to the JSON server about the phone model and the shops where the phone is available. If the server was written and configured correctly, it will understand the query and send the required information. So the main feature of GraphQL is that the client is free to select what data has to be sent from the server.
GraphQL has the three types of queries:
- query is a data request;
- mutation is a request to update data after certain operations such as order creation;
- subscription is an automatic notification sent to the client through a WebSocket connection to inform that certain changes took place and the data on the page has to be updated.
What is so interesting about a WebSocket connection? Most protocols don’t keep the doors opened wide for data: the client sends a query, the server responds. That’s all, the connection is terminated. However, WebSocket – a HTTP-based protocol – was created for continuous data exchange. Unlike connection over standard HTTP protocol, this protocol is not closed as soon as the server responds. This is why it is indispensable for such projects as online games, online shops, chats and the like where the client and the server have to exchange data constantly. Surely, it also works well if you want to create interactive and high-load React applications.
Advantages of GraphQL:
- it’s not necessary to create several REST queries. To retrieve the data, it’s enough to make one query, even if the data has different sources;
- it’s not tied to a specific database or storage mechanism;
- GraphQL uses a strict data type system defining various data formats present in the application.
Since GraphQL is not a specific product but rather a standard, you need a tool to implement it. One method of implementation is the state management library Apollo consisting of two libraries: Apollo Client and Apollo Server.
Backend-for-frontend
Your server with data and business logic doesn’t need to be a part of the application. Today, the Backend-for-Frontend (BBF) pattern presented by Soundcloud in 2015, is greatly popular. It implies that the backend can be written in any language and can send data in any way. It will still be able to understand the frontend because GraphQL works on the backend as a separate service retrieving data from the server and sending it to the client side.
Just imagine that you have an old legacy project where the client and the server communicate over SOAP. With the BBF pattern, you don’t need to rewrite the whole backend, it’s just necessary to add an interlayer in GraphQL. As for new applications, of course, it makes sense to use GraphQL from the very beginning.
Conclusion
The backend of any application appreciates mindful selection of technologies for its development. Criteria for database and server technology selection are as follows:
- the task;
- resources (team and budget);
- anticipated application load;
- quantity of users;
- data processing scope and complexity.
The use of React for the frontend doesn’t determine the selection of technology for the backend. First of all, data exchange via WebSockets can also be built on Node.js, or Python, or C#. Secondly, though the frontend and backend written in JavaScript will make your full-stack developer feel comfortable, the Backend-for-Frontend method is good just because it allows creating a GraphQL interlayer between the client and the server without giving much thought to the technology compatibility on both sides. In other words, by using a number of well-known know-hows you can build the backend for React applications in any popular language or the language your team knows and likes.
Useful links
