We prefer ReactJS for its ease of use and simplified code debugging. This article will discuss ReactJS`s philosophy, web applications, backend requirements, APIs, backend-for-frontend (BFF), and more.
What is ReactJS?
ReactJS appeared in 2013 and was invented by Facebook while introducing chat to their social network.
ReaсtJS is the library responsible for creating the user interface of a website. It is an interface containing text, interactive elements, dynamics, and events. By interactive events, we mean the ability to "Like" an item, send a completed contact form, and use an administrative panel in an online store, where the product, shopping cart, and payment-sending process have several states.
Components and Elements in React: what they are and why they are not synonymous
Elements are the result of compiling the JSX language that ReactJS works with and the React.createElement method. After rendering inside ReactJS, an element becomes the very object in the DOM tree that the user will see on the screen. In other words, the element is created in the Virtual DOM, and when rendered, it's transferred to the standard DOM of the web application to become a button in the application interface.
Our developers say that markup and logic are closely linked in ReactJS. This means that data about the appearance of the interactive UI element and how it changes as you interact with the web application is not separated into different files but is stored within the component. This is what impresses our developers with React's component-oriented approach. The JSX markup language helps them navigate the UI better, but it is possible to develop in React without it.
Components have boundaries. They can be visually traced by looking at the layout of the future web application.
Look at any website page (whether made with React or not - we're just giving an example now): put a page header, buttons, data collection form, and other visual components into a rectangle. The content of such a rectangle is a component for the developer and an element for the user.
Components should be created according to the principle of sole responsibility: each should be responsible for a single task. If a component still performs several tasks, it is better to break it up into subcomponents. A complex interactive form with multiple fields and buttons would be a single large component, and each field and button would be a subcomponent. If several components can be combined into one large rectangle, it will be a parent component, and its components will be children.
Frequently recurring and simply complex functionality should be designed as components. Components don't have to be interactive because you can make static sites in ReactJS.
- Can be a function or class that takes in some data and returns elements, other components, strings, and numbers
- Works on a lifecycle
- Contains markup
- Can change its state (mutable)
- Is what components always return
- Is the representation of the object in the DOM node
- Is created and not modified (immutable)
- Doesn't work with React hooks because it doesn't change
What impact does the component-oriented approach of the React library have on developer time and budget for your project:
- The reusability of components allows you to avoid writing different code for closely related features. This saves developers time and your money.
- Since changes in one part of the application do not lead to changes in other parts, the time spent searching for bugs is reduced.
- With React hooks, developers no longer need to spend time rewriting functional components into class components.
We provide IT staff augmentation services and can assist your team in MERN stack development.
React and single-page applications (SPAs)
If the load is taken off the server, it increases on the user side. But statistics say that client machines have enough RAM to render website pages in React in the browser.
However, if it is necessary to get the fastest response from the interface, the SPA (Single Page Application) approach is used. Its essence is that the entire website is a single page that React is constantly redrawing.
In the case of SPA, the user is formally on the same page while switching between different sections of the website, but the scripts and styles files are already there. The only thing left is to add the missing elements. For example, if the website header is the same on every page, and only some block has changed, there is no need to redraw the header.
This saves resources and gives a faster and more responsive interface. The owners of an online store need to treasure every moment as there is a chance to lose a customer if he or she waits 5-10 seconds after clicking a button.
React and Search Engine Optimization (SEO)
Search engine optimization is the weakest part of React applications. The harm to business from bad SEO is clear: if search engines can't see your website, it doesn't exist.
There is a Server Side Rendering approach to solve the problem. Part of the work of rendering websites happens on the server (yes, that's right, we've come to the same thing we were trying to get away from), which NextJS, a React-based framework, is responsible for. When requested from the browser, the server gives you a pre-drawn page.
Then those elements start behaving like React components on the client side. Thus, what the user sees is partially rendered on the server, and the rest is assembled in the browser. Otherwise, the pages of the website would be indexed worse.
Together with the SPA approach, this gives isomorphic applications. Users of such applications get a responsive interface and fast content display in an already-loaded application. The second advantage is that it solves SEO problems: if a search engine finds the page, it gets its markup immediately and can index it without waiting for the scripts to work. But the difference between an isomorphic application and a simple one is that when the user leaves one page for another, the application is already running as a SPA.
What's required from a React web application backend?
And here it's time to talk about clean architecture. An application with a clean architecture is characterized by:
- Readable code. A newcomer to the project will fit in quickly if he or she sees that it uses familiar practices.
- Extensibility. Even during the process, something can be changed or added to what has already been done.
- Optimized performance. A fast web application is nicer than a slow one.
Web applications with clean architecture are easier to maintain, track, and fix bugs. By building such a web application, our developers control data flows, markup, and styling. They are ideally familiar with programming patterns that make building web applications faster and more flexible.
What is the importance of a clean architecture when discussing React web application development?
Although related, the client and the server (frontend and backend) are different applications.
For the frontend, the backend implementation details are not as important as the API (Application Programming Interface) - a set of agreements between the client and server side to use certain procedures to perform operations with a certain result at the end. Once you get API, you can separate and develop them in parallel. This is one of the features of ReactJS web development.
In the pursuit of clean architecture, the backend and frontend are often separated because as a monolithic application grows, it becomes increasingly difficult to maintain them.
Let's say there is a form on the site in which something needs to be changed, and the developer likely needs to change the CMS settings to display the form. If the user interface was developed in React, all the necessary changes to the form would be made on the client side without involving the server. It is the same on the backend. For example, there is an online store where the logic of charging a discount or delivery has changed. When the frontend and backend are separated, the developer makes changes on the backend, but the display may not be affected.
So, on ReactJS projects, the architectural style of API used by the backend application to communicate with the frontend application is important.
We'll talk about GraphQL because we're familiar with the technology and think it's the most appropriate for ReactJS applications. Some say it's a query language for APIs and an environment in which to run them. Someone (like us) calls it a description of a standard that can be implemented in different ways. Either way, it's the next step in evolving client-server communication after SOAP and REST APIs.
How GraphQL makes life better when developing ReactJS web application
Unlike its predecessors, GraphQL has even more specific and parsimonious requests to the server. When the project has a lot of resources and uses the REST API architectural style, the client refers to multiple data entry points (endpoints). With GraphQL, the client sends requests via only one endpoint and defines in what format they want to receive data.
For example, your React application is an aggregator of electronics stores. According to the special rules that the GraphQL standard dictates, the client sends the server a data request in JSON format about the phone model and the stores where it is sold. If the server is properly written and configured, it will understand the request and send everything needed. Consequently, the main thing about GraphQL is that the client can choose which data he wants from the server.
GraphQL has three types of queries:
- Query - a request to retrieve data
- Mutation - a request for updating data after some operations like creating an order
- Subscription - automatically notify the client through a WebSocket connection that some changes have been made and the data on the page needs to be updated
What is a WebSocket connection, and how can it help us? Most protocols do not open the door for data: the client sends a request, the server responds - that's all; the connection can be closed. But WebSocket was created for constant data exchange. It is a protocol based on HTTP.
Unlike the usual HTTP protocol connections, this protocol is not closed after the server response. Therefore, it is indispensable for projects such as online games, online stores, chat rooms, and others, where the client and the server must communicate constantly. Of course, it is also suitable for creating interactive and high-load React applications.
The advantages of GraphQL are:
- You don't need to create multiple REST queries. You only need to enter a single query to retrieve data - even if the data lies in different sources.
- It is not tied to a specific database or storage mechanism.
- GraphQL uses a strict data type system that defines the various data formats used in the application.
Since GraphQL is not a specific development but rather a standard, a tool is needed to implement it. One way to implement it is the Apollo state management library, which consists of two libraries: Apollo Client and Apollo Server.
You don't have to have your server with data and business logic as part of the application. The Backend-for-Frontend (BFF) pattern, introduced by Soundcloud in 2015, is now popular. The idea is that the backend can be written in anything and give data away how you want. Nevertheless, it and the frontend will still understand each other because GraphQL runs as a separate service, taking data from the server and giving it to the client.
Imagine you have an old legacy project where the client and server communicate via SOAP. You don't need to rewrite the whole backend with the BFF pattern. You just need to add a GraphQL. As for new web applications, it makes sense to use GraphQL immediately.
So, using React on the client does not determine the choice of technology for the server side:
- Data exchange via WebSockets can be built on NodeJS, Python, and C#.
In other words, using already known know-how, the backend for a ReactJS application can be built on anything popular, used, that your team likes, and that they know how to work with.
MaybeWorks expertise in ReactJS web development
In one of our latest projects, our ReactJS developers augmented the client`s team to develop a training platform for medical students. The user carries out the learning process through various scenarios that simulate the diagnosis. Each scenario consists of several stages, at which the user collects anamnesis and symptoms and chooses diagnostic methods. Finally, the user can listen to an audio file with the correct answers for all stages.
Several MaybeWorks frontend developers were hired for MVP development. It was necessary to implement a working version of the application for further testing by the focus group. The work began with refactoring the existing code since the client`s development team partially implemented the front end. At the end of the refactoring, our developers began to work on implementing the necessary functionality:
- Finishing chat widget
- Ensure widgets are independent modules, so it is easy for us to define new widgets (MRI, doctor notes, Cancer test, etc.)
- Ensure the navigation button changes colors/pattern based on unlock/progress
- Make widgets dynamic (layout should automatically display widgets based on config. If there is "blood" data in the lab config, then the lab should include a blood widget)
- Finishing clue analyzer
Our IT staff augmentation services allowed our client to finish MVP developer 2 times faster. Feel free to contact us right now!