DEV Community: Sergey

What "production-ready" really means for a NestJS backend

Sergey — Tue, 14 Apr 2026 16:56:50 +0000

Three weeks ago I shared an early version of this project and got a lot of thoughtful feedback.

I've since reworked it - here’s the updated version:

https://github.com/prod-forge/backend

What this project is about

The idea hasn’t changed:

Writing backend code is the easy part.
Everything around it is what makes systems reliable.

This project focuses on:

what happens before code
what happens before deploy
what happens when things break

What’s inside

A simple Todo API, but built like a real production service:

CI/CD with rollback
forward-only migrations
observability (Prometheus + Grafana + Loki)
structured logging + correlation IDs
Terraform infrastructure (AWS)
E2E testing with Testcontainers

What changed after feedback

improved structure and documentation
clarified migration and release flow
refined CI/CD and rollback approach
better explanations of key decisions

Important

This is not a boilerplate.

The goal is not to copy configs,
but to understand how production systems are actually put together.

Feedback

If you’ve worked on real systems:

What would you add or do differently?

Monorepo vs Multirepo: How I Changed My Mind After Working on Real Projects

Sergey — Tue, 17 Mar 2026 08:43:56 +0000

When I started building projects from scratch, I kept running into the same question over and over again:

Should I use a monorepo or split everything into multiple repositories?

For a long time, I thought I had a clear answer. Now I'm not so sure anymore.

This is not a theoretical comparison. It's just how my opinion changed after working on real systems with real teams.

At the beginning of my career, I loved monorepos.

They felt simple and natural, especially when I was working alone or in a small team. Everything was in one place, and I didn't have to think too much about boundaries or versioning.

I could change the frontend, update the backend, fix the tests, and ship everything in a single commit. One change, one result. No coordination, no compatibility concerns, no overhead.

At some point I even started wondering why people bothered with multiple repositories at all. It felt like unnecessary complexity.

That illusion didn't last.

The first time my perspective really shifted was when I was leading a team working on micro-frontends for a large product.

There were multiple teams involved. Each team owned a part of the system. Our team was responsible for shared components that were used across many different websites.

Versioning actually mattered there. Not every consumer could instantly adapt to changes, so we had changelogs, migration guides, and some level of discipline around releases.

But everything still lived in one big monorepo.

One morning we came in and the system was broken. Not partially - completely unusable.

After digging through the commit history, I found the cause. A developer from another team had modified one of our shared components to make it work with their API changes. No discussion, no version bump, just a direct change.

We rolled it back and talked to the team. It seemed like a one-off mistake.

It wasn't.

The same thing happened again later, with a different developer.

That's when it clicked for me. In a monorepo, ownership becomes blurry. Even if you define boundaries, the repository itself communicates something else: “this is all one project.”

And once people start thinking that way, they feel allowed to change things outside their domain.

The second time I started questioning monorepos was because of CI.

We had a fairly large codebase, all inside a single repository. To save costs, we were running CI on a relatively weak machine. Every push triggered a complex pipeline, and every pull request depended on it.

At first it was fine. Then the project grew.

Builds became slower. Pipelines became harder to understand. A single change could trigger a chain of checks that had nothing to do with what you actually modified.

We tried to optimize it. Running tests only when certain parts changed, splitting steps, tweaking configurations.

It helped, but only up to a point. There were still global checks — linting, shared validations — that kept everything tied together.

The result was friction. Waiting for CI became part of the development process.

And that's the moment when "convenience" starts turning into "cost".

Today my view is much simpler and much less dogmatic.

If I'm working alone, or with a small team, and the product is evolving quickly without strict requirements for backward compatibility, I would still choose a monorepo. It's fast, it's convenient, and it removes a lot of overhead.

But as soon as multiple teams are involved, or different parts of the system need independent lifecycles, I would split things into separate repositories without hesitation.

Not because it's cleaner in theory, but because it enforces boundaries in practice.

What worked best for me recently is a hybrid approach.

Keeping closely related pieces together makes sense. For example, a frontend app and its UI library can live in one repository. The same goes for a group of tightly coupled backend services.

But mixing everything — frontend, backend, infrastructure — into a single repo just because it's "easier" is something I would avoid now.

It usually is easier at the beginning. And much harder later.

The funny thing is, choosing between monorepo and multirepo is just a small part of a much bigger picture.

What actually makes or breaks a project in production has very little to do with where your code lives.

It's everything around it: CI/CD, migrations, observability, error handling, release processes, and how your team works with all of that.

That's exactly why I started putting together an open-source project where I document how backend systems should actually be built and shipped if you treat them like real production systems from day one.

Not as a boilerplate, but as a walkthrough of decisions — what happens before code, around code, and after code.

If that's something you're interested in, you can check it out here:

https://github.com/prod-forge/backend

There's no universally correct choice between monorepo and multirepo.

There's only context.

And over time, I've learned that good engineering is less about picking the "right" pattern, and more about understanding when your current choice stops working.

Mastering the Dependency Inversion Principle: Best Practices for Clean Code with DI

Sergey — Thu, 28 Nov 2024 17:59:00 +0000

If you're familiar with object-oriented programming, or are just starting to explore it, you've likely encountered the acronym SOLID. SOLID represents a set of principles designed to help developers write clean, maintainable, and scalable code. In this article, we will focus on the "D" in SOLID, which stands for the Dependency Inversion Principle.

But before diving into the details, let's first take a moment to understand the "why" behind these principles.

In object-oriented programming, we typically break down our applications into classes, each encapsulating specific business logic and interacting with other classes. For instance, imagine a simple online store where users can add products to their shopping cart. This scenario could be modeled with several classes working together to manage the store’s operations. Let's consider this example as a foundation to explore how the Dependency Inversion Principle can improve the design of our system.

class ProductService {
 getProducts() {
   return ['product 1', 'product 2', 'product 3'];
 }
}


class OrderService {
 constructor() {
   this.productService = new ProductService();
 }

 getOrdersForUser() {
   return this.productService.getProducts();
 }
}


class UserService {
 constructor() {
   this.orderService = new OrderService();
 }

 getUserOrders() {
   return this.orderService.getOrdersForUser();
 }
}

As we can see, dependencies like OrderService and ProductService are tightly coupled within the class constructor. This direct dependency makes it difficult to replace or mock these components, which poses a challenge when it comes to testing or swapping implementations.

Dependency Injection (DI)

The Dependency Injection (DI) pattern offers a solution to this problem. By following the DI pattern, we can decouple these dependencies and make our code more flexible and testable. Here’s how we can refactor the code to implement DI:

class ProductService {
 getProducts() {
   return ['product 1', 'product 2', 'product 3'];
 }
}


class OrderService {
 constructor(private productService: ProductService) {}

 getOrdersForUser() {
   return this.productService.getProducts();
 }
}


class UserService {
 constructor(private orderService: OrderService) {}

 getUserOrders() {
   return this.orderService.getOrdersForUser();
 }
}


new UserService(new OrderService(new ProductService()));

We’re explicitly passing dependencies to the constructor of each service, which, while a step in the right direction, still results in tightly coupled classes. This approach does improve flexibility slightly, but it doesn’t fully address the underlying issue of making our code more modular and easily testable.

Dependency Inversion Principle (DiP)

The Dependency Inversion Principle (DiP) takes this a step further by answering the crucial question: What should we pass? The principle suggests that instead of passing concrete implementations, we should pass only the necessary abstractions—specifically, dependencies that match the expected interface.

For example, consider the ProductService class with a getProducts method that returns an array of products. Instead of directly coupling ProductService to a specific implementation (e.g., fetching data from a database), we could implement it in various ways. One implementation might fetch products from a database, while another might return a hardcoded JSON object for testing. The key is that both implementations share the same interface, ensuring flexibility and interchangeability.

Inversion of Control (IoC) and Service Locator

To put this principle into practice, we often rely on a pattern called Inversion of Control (IoC). IoC is a technique where the control over the creation and management of dependencies is transferred from the class itself to an external component. This is typically implemented through a Dependency Injection container or a Service Locator, which acts as a registry from which we can request the required dependencies. With IoC, we can dynamically inject the appropriate dependencies without hardcoding them into the class constructors, making the system more modular and easier to maintain.

class ServiceLocator {
 static #modules = new Map();

 static get(moduleName: string) {
   return ServiceLocator.#modules.get(moduleName);
 }

 static set(moduleName: string, exp: never) {
   ServiceLocator.#modules.set(moduleName, exp);
 }
}

class ProductService {
 getProducts() {
   return ['product 1', 'product 2', 'product 3'];
 }
}


class OrderService {
 constructor() {
   const ProductService = ServiceLocator.get('ProductService');
   this.productService = new ProductService();
 }

 getOrdersForUser() {
   return this.productService.getProducts();
 }
}


class UserService {
 constructor() {
   const OrderService = ServiceLocator.get('OrderService');
   this.orderService = new OrderService();
 }

 getUserOrders() {
   return this.orderService.getOrdersForUser();
 }
}

ServiceLocator.set('ProductService', ProductService);
ServiceLocator.set('OrderService', OrderService);


new UserService();

As we can see, dependencies are registered within the container, which allows them to be replaced or swapped when necessary. This flexibility is a key advantage, as it promotes loose coupling between components.

However, this approach has some downsides. Since dependencies are resolved at runtime, it can lead to runtime errors if something goes wrong (e.g., if a dependency is missing or incompatible). Furthermore, there is no guarantee that the registered dependency will strictly conform to the expected interface, which can cause subtle issues. This method of dependency resolution is often referred to as the Service Locator pattern, and it is considered an anti-pattern in many cases due to its reliance on runtime resolution and its potential to obscure dependencies.

InversifyJS

One of the most popular libraries in JavaScript for implementing the Inversion of Control (IoC) pattern is InversifyJS. It provides a robust and flexible framework for managing dependencies in a clean, modular way. However, InversifyJS has some drawbacks. One major limitation is the amount of boilerplate code required to set up and manage dependencies. Additionally, it often requires structuring your application in a specific way, which may not suit every project.

An alternative to InversifyJS is Friendly-DI, a lightweight and more streamlined approach for managing dependencies in JavaScript and TypeScript applications. It is inspired by the DI systems in frameworks like Angular and NestJS but is designed to be more minimal and less verbose.

Some key advantages of Friendly-DI include:

Small size: Just 2 KB with no external dependencies.
Cross-platform: Works seamlessly in both the browser and Node.js environments.
Simple API: Intuitive and easy to use, with minimal configuration.
MIT License: Open-source with permissive licensing.

However, it's important to note that Friendly-DI is designed specifically for TypeScript, and you'll need to install its dependencies before you can start using it.

npm i friendly-di reflect-metadata

And also extend tsconfig.json:

{
 "compilerOptions": {
   "experimentalDecorators": true,
   "emitDecoratorMetadata": true
 }
}

The example above can be modified with Friendly-DI:

import 'reflect-metadata';
import { Injectable } from 'friendly-di';

@Injectable()
class ProductService {
 getProducts() {
   return ['product 1', 'product 2', 'product 3'];
 }
}

@Injectable()
class OrderService {
 constructor(private productService: ProductService) {}

 getOrdersForUser() {
   return this.productService.getProducts();
 }
}

@Injectable()
class UserService {
 constructor(private orderService: OrderService) {}

 getUserOrders() {
   return this.orderService.getOrdersForUser();
 }
}

@Injectable()
class App {
 constructor(private userService: UserService) {}


 run() {
   return this.userService.getUserOrders();
 }
}

As we can see, we've added the @Injectable() decorator, which marks our classes as injectable, signaling that they are part of the dependency injection system. This decorator allows the DI container to know that these classes can be instantiated and injected where needed.
When declaring a class as a dependency in a constructor, we don’t directly bind to the concrete class itself. Instead, we define the dependency in terms of its interface. This decouples our code from the specific implementation and allows for greater flexibility, making it easier to swap or mock dependencies when needed.
In this example, we placed our UserService in the App class. This pattern is known as the Composition Root. The Composition Root is the central place in the application where all dependencies are assembled and injected — essentially the "root" of our application's dependency graph. By keeping this logic in one place, we maintain better control over how dependencies are resolved and injected throughout the app.

The final step is to register the App class in the DI Container, which will enable the container to manage the lifecycle and injection of all dependencies when the application starts.

import { Container } from 'friendly-di';

const app = new Container(App).compile();

app.run();

If we need to replace any classes in our application we just need to create mock-class following the origin interface:

@Injectable()
class MockProductService {
 getProducts() {
   return ['new product 1', 'new product 2', 'new product 3'];
 }
}

and then use replace method where we declare replaceable class to mock class:

import { Container } from 'friendly-di';

const app = new Container(App)
 .replace(ProductService, MockProductService)
 .compile();

app.run();

Friendly-DI we can make replace many times:

const app = new Container(App)
 .replace(ProductService, MockProductService)
 .replace(OrderService, MockOrderService)
 .compile();

app.run();

That's all, if you have any comments or clarifications on this topic, please write your thoughts in the comments.

Rockpack 2.0 Official Release

Sergey — Tue, 18 Jan 2022 11:36:57 +0000

More than a year has passed since the release of version 1.0. During this time, I received feedback from users, made many fixes, and also updated all dependencies to the current state. And today I would like to proudly present you the release of the second version of this tool.

Rockpack repository is here!

What is Rockpack?

Starting a new React project, whether it's a small module or a React component, or vice versa, a large application with SSR support, we spend a lot of time solving routine tasks, slowing down the development process. We can’t dive into solving business problems without setting up Webpack, including all plugins and modules, setting up ESLint, Jest, Babel, TypeScript, as well as dependencies and configurations for them.

But this process can be automated!

Rockpack is a tool that can deploy one of the 4 types of React applications on your computer in one console command, which will be described below, with fully configured Webpack 5, ESLint 8, Babel, Jest, TypeScript and more with perfectly optimized settings, for stable and fast work. You not only get the generated settings, but also the basic framework of the project, based on the best development practices and experience of the entire React community.

Rockpack's main goal is to reduce project setup from weeks to 5 minutes!

What's new in Rockpack 2.0?

As part of the work on Rockpack 2.0, absolutely all dependencies have been updated. Now using the latest version of Webpack 5, Typescript 4.5+, ESLint 8+, Jest 27+, etc. All modules, plugins, loaders have been updated. Configs have been rewritten, taking into account the features of new versions.

The project supports React 17+ versions. It is no longer necessary to import React into every component. Also, the latest React Router 6 is available out of the box.

What does Rockpack support?

Out of the box, you can take advantage of the following features:

TypeScript support 4.5+
Babel 7, Babel-preset-env (> 5%)
Support build nodejs scripts with nodemon
Hot Module Replacement for SPA
Livereload for SSR
Source maps and Extended dev mode
Dotenv support and Dotenv safe support
React optimizations
Monorepo support
Write file webpack plugin (in dev mode)
Copy Webpack Plugin
ESLint support
Templates: HTML/Jade/Handlebars
CSS: CSS/SASS (dart-sass)/LESS + Postcss
Postcss, Autoprefixer
CSS Modules support
Imagemin
Formats support: Markdown, Video, Audio, Fonts, SVG, Script, Shaders etc
SVG + SVGO, SVGR (import SVG like React Component)
Antd optimizations (With optimizations: auto replace momentjs to dayjs, import antd)
Terser minification
Generate stats.json (in production mode)
SEO Optimizations
Bundle Analyze (webpack-bundle-analyzer, Statoscope)
Isomorphic compile support (include isomorphic styles, isomorphic dynamic imports - @loadable)
Vendor array splitting support (You can set dependency libraries to this array to split it on separate vendor.js file)
MD/MDX support
GraphQL support (webpack-graphql-loader)
Сross-env included

Rockpack comes with a set of the best ESLint rules, Babel plugins and Jest plugins.

Why do I need Rockpack when there is create-react-app?

The main difference between Rockpack and create-react-app is that you can generate 4 types of applications, including those with SSR support, using best practices and feature-based project structure approach.

CSR (Client Side Render) is an ordinary Single Page Application that has a project structure Project Structure Article
SSR (Server Side Render) is an application with a configured server to work with Server Side Render support as well as SEO best practices SSR Article
React Component is a boilerplate for building a React Component. If you need to create a React Component and expose it to NPM, then this option is for you.
UMD Library - This option is for you if you just need to create and publish to NPM just a library.

The SSR project will also have a number of best practices for SEO, which will make it possible to get a project with a high level in the lighthouse

How to get started with Rockpack?

It's very simple! To start using Rockpack now, you need to:

Step 1. Install the package globally:

npm install -g @rockpack/starter

Step 2. Run the command:

rockpack folder_name

for example:

rockpack my-awesome-app

Step 3. Select the required project type from the list

In order to learn more, Rockpack readme is here to learn more.

What's next?

The Rockpack project is over 2 years old. During this time, it has become stable and does not require changes to the main API. We will support the project and expand its functionality.

Thanks to everyone who read this article! I hope Rockpack will be handy in your work.

CSS Modules vs CSS-in-JS. Who wins?

Sergey — Thu, 11 Mar 2021 13:29:36 +0000

Introduction

In modern React application development, there are many approaches to organizing application styles. One of the popular ways of such an organization is the CSS-in-JS approach (in the article we will use styled-components as the most popular solution) and CSS Modules. In this article, we will try to answer the question: which is better CSS-in-JS or CSS Modules?

So let's get back to basics. When a web page was primarily set for storing textual documentation and didn't include user interactions, properties were introduced to style the content. Over time, the web became more and more popular, sites got bigger, and it became necessary to reuse styles. For these purposes, CSS was invented. Cascading Style Sheets. Cascading plays a very important role in this name. We write styles that lay like a waterfall over the hollows of our document, filling it with colors and highlighting important elements.

Time passed, the web became more and more complex, and we are facing the fact that the styles cascade turned into a problem for us. Distributed teams, working on their parts of the system, combining them into reusable modules, assemble an application from pieces, like Dr. Frankenstein, stitching styles into one large canvas, can get the sudden result... Due to the cascade, the styles of module 1 can affect the display of module 3, and module 4 can make changes to the global styles and change the entire display of the application in general.

Developers have started to think of solving this problem. Style naming conventions were created to avoid overlaps, such as Yandex's BEM or Atomic CSS. The idea is clear, we operate with names in order to get predictability, but at the same time to prevent repetitions.

These approaches were crashed of the rocks of the human factor. Anyway, we have no guarantee that the developer from team A won't use the name from team C.

The naming problem can only be solved by assigning a random name to the CSS class. Thus, we get a completely independent CSS set of styles that will be applied to a specific HTML block and we understand for sure that the rest of the system won't be affected in any way.

And then 2 approaches came onto the stage to organize our CSS: CSS Modules and CSS-in-JS. Under the hood, having a different technical implementation, and in fact solving the problem of atomicity, reusability, and avoiding side effects when writing CSS.

Technically, CSS Modules transforms style names using a hash-based on the filename, path, style name. Styled-components handles styles in JS runtime, adding them as they go to the head HTML section (<head>).

Approaches overview

Let's see which approach is more optimal for writing a modern web application!

Let's imagine we have a basic React application:

import React, { Component } from 'react';
import './App.css';

class App extends Component {
 render() {
   return (
     <div className="title">
       React application title
     </div>
   );
 }
}

CSS styles of this application:

.title {
 padding: 20px;
 background-color: #222;
 text-align: center;
 color: white;
 font-size: 1.5em;
}

The dependencies are React 16.14, react-dom 16.14

Let's try to build this application using webpack using all production optimizations.

we've got

uglified JS - 129kb
separated and minified CSS - 133 bytes

The same code in CSS Modules will look like this:

import React, { Component } from 'react';
import styles from './App.module.css';

class App extends Component {
 render() {
   return (
     <div className={styles.title}>
       React application title
     </div>
   );
 }
}

uglified JS - 129kb
separated and minified CSS - 151 bytes

The CSS Modules version will take up a couple of bytes more due to the impossibility of compressing the long generated CSS names.

Finally, let's rewrite the same code under styled-components:

import React, { Component } from 'react';
import styles from 'styled-components';

const Title = styles.h1`
 padding: 20px;
 background-color: #222;
 text-align: center;
 color: white;
 font-size: 1.5em;
`;

class App extends Component {
 render() {
   return (
     <Title>
       React application title
     </Title>
   );
 }
}

uglified JS - 163kb
CSS file is missing

The more than 30kb difference between CSS Modules and CSS-in-JS (styled-components) is due to styled-components adding extra code to add styles to the <head> part of the HTML document.

In this synthetic test, the CSS Modules approach wins, since the build system doesn't add something extra to implement it, except for the changed class name. Styled-components due to technical implementation, adds dependency as well as code for runtime handling and styling of <head>.

Now let's take a quick look at the pros and cons of CSS-in-JS / CSS Modules.

Pros and cons

CSS-in-JS

cons

The browser won't start interpreting the styles until styled-components has parsed them and added them to the DOM, which slows down rendering.
The absence of CSS files means that you cannot cache separate CSS.
One of the key downsides is that most libraries don't support this approach and we still can't get rid of CSS. All native JS and jQuery plugins are written without using this approach. Not all React solutions use it.
Styles integration problems. When a markup developer prepares a layout for a JS developer, we may forget to transfer something; there will also be difficulty in synchronizing a new version of layout and JS code.
We can't use CSS utilities: SCSS, Less, Postcss, stylelint, etc.

pros

Styles can use JS logic. This reminds me of Expression in IE6, when we could wrap some logic in our styles (Hello, CSS Expressions :) ).

const Title = styles.h1`
 padding: 20px;
 background-color: #222;
 text-align: center;
 color: white;
 font-size: 1.5em;
 ${props => props.secondary && css`
   background-color: #fff;
   color: #000;
   padding: 10px;
   font-size: 1em;
 `}
`;

When developing small modules, it simplifies the connection to the project, since you only need to connect the one independent JS file.
It is semantically nicer to use <Title> in a React component than <h1 className={style.title}>.

CSS Modules

cons

To describe global styles, you must use a syntax that does not belong to the CSS specification.

:global(.myclass) {
    text-decoration: underline;
}

Integrating into a project, you need to include styles.
Working with typescript, you need to automatically or manually generate interfaces. For these purposes, I use webpack loader:

@teamsupercell/typings-for-css-modules-loader

pros

We work with regular CSS, it makes it possible to use SCSS, Less, Postcss, stylelint, and more. Also, you don't waste time on adapting the CSS to JS.
No integration of styles into the code, clean code as result.
Almost 100% standardized except for global styles.

Conclusion

So the fundamental problem with the CSS-in-JS approach is that it's not CSS! This kind of code is harder to maintain if you have a defined person in your team working on markup. Such code will be slower, due to the fact that the CSS rendered into the file is processed in parallel, and the CSS-in-JS cannot be rendered into a separate CSS file. And the last fundamental flaw is the inability to use ready-made approaches and utilities, such as SCSS, Less and Stylelint, and so on.

On the other hand, the CSS-in-JS approach can be a good solution for the Frontend team who deals with both markup and JS, and develops all components from scratch. Also, CSS-in-JS will be useful for modules that integrate into other applications.

In my personal opinion, the issue of CSS cascading is overrated. If we are developing a small application or site, with one team, then we are unlikely to encounter a name collision or the difficulty of reusing components. If you faced with this problem, I recommend considering CSS Modules, as, in my opinion, this is a more optimal solution for the above factors. In any case, whatever you choose, write meaningful code and don't get fooled by the hype. Hype will pass, and we all have to live with it. Have great and interesting projects, dear readers!

Project Structure. Repository and folders. Review of approaches.

Sergey — Wed, 17 Feb 2021 12:30:32 +0000

When we take the first steps in project creation, we need to make many fundamental decisions. One of those steps is a project structure. The project structure is the foundation. The correctness of the choice affects the introduction of new functionality into the project, support, onboarding new people into the project, etc.

In this article, I would like to review structure's approaches for Frontend applications, especially React-based ones. React-based examples are interesting to review because the folder structure and project organization are very different from project to project.

There are many ways to organize your project structure. Some developers do not pay enough attention to the structure of the project, placing files without logical connection. Some developers even write JS code in one file. But the purity of our code starts with the project structure. I will describe my experience using different approaches, the impact on the team and development time, and more.

When you define a project structure and choose a repository approach, you should understand your project goals, the approximate team size, business development paths, etc.

Let's start our journey with the repository.

Monolith

The vast majority of projects are regular GIT repositories. React Component, Website, Single Page Application, Backend API, whatever!

Working in a regular repository is usually focused on speed. With this approach, the team has a mix of backend, frontend, QA, Business Analyst specialists, as well as an assigned Product Owner or Project Manager. So that, the team is completely independent and holistic, but at the same time small.

Code splitting is minimal with this approach. For example, when making a website, the project is divided into 2 repositories - SPA, Backend API. Or the frontend part is stored in the server repository. The work going forward, without worrying about versioning.

Many Repos

It is a collection of GIT repositories. We can move the UI into a separate repo and use it in several applications, micro services, reusable parts, etc.

This approach is great for large projects. For projects where we build an ecosystem of many applications. As soon as we choose this approach, it is very important to understand that each repository must have its own command. The team should be like a full-fledged unit, have its own QA, product owner, etc.

In a multi-repository approach, versioning and understanding breaking changes are very important. Your teams, assigned to their own parts of the system, use other parts of the system as a black box. If the UI command changes the interface of the components, then many applications that depend on these changes will stop working. At the same time, using versioning, the transition to the new version will have a smoother transition.

It is worth considering that working with multi repositories we can speed up the development process by doing tasks in parallel, increasing the speed. At the same time, due to separate commands for the repository, the costs increase. Integration between major versions becomes more difficult as changes are likely to affect other teams.

Monorepo

This is a repository that includes related modules

This is a kind of balance between logic separation and simple implementation. Large projects like Babel, React-Router have a mono repo system. Thus, it is easier to add new modules, there is no need to worry too much about backward compatibility, since the current version is taken as a basis, as in option Monolith.

This approach allows you to avoid unnecessary pull requests, for example, you have updated the UI library and you need to update this dependency in all applications. In the monorepo approach, you only need one PR to accomplish this. In many repos, you need to create a PR for all repos where the dependency needs to be updated.

This approach is good for a small team on a fairly large project.

Folder structure

The project folder structure should be as intuitive as a map. Showing where and what you have. We will look at examples in SPA React applications.

Splitting into components

This approach is suitable when you are developing a React module that will integrate into your application. For example, you are making a chat that will be embedded in the site. In this case, the components that will make up the chat will be independent, have their own local state, and will be used by the index.jsx file as a generated module.

Separation into entities

This approach is offered in many frameworks like AngularJS, Angular 2+, etc. I bumped into this approach often both in React and in various other programming languages, especially on the Backend.

In large applications, the contents of folders become a dump. It is very difficult to find the required file and determine the dependencies.

Separation by features

Separation by features promotes the idea of separating business logic from the presentation by bringing logic into independent and independent units - features.

In this example, we see the routes folder, which corresponds to the routing of the application and collects the entire page structure, components, and interaction with features.

Features are separated from views. This is a set of logic dealing with state and callbacks that will be delegated to components on routes.

An example of this approach can be found at the link

I would especially like to note that with the advent of React hooks, this approach fits very succinctly into the structure of the application. The example above uses hooks.

Real life example

A couple of years ago, a friend of mine and I were working on a large project called Cleverbrush. It was a startup, we had no money, we needed to release a production-ready application as soon as possible.

Since the Cleverbrush project consisted of several applications (graphics editor, photo collage, admin panel, and landing page), we used the Monorepo approach to bring common parts such as UI, utils, etc. into separate packages. Monorepo allowed us to work faster if we worked in different repositories.

The folder structure reflected the approach of separating features from views, much like the example.

This allowed us to separate our business logic and delegate it to components.

Also, we had to develop many components from scratch, for this purpose we used the folder structure of option Separation into components.

Thus, we mixed different approaches to achieve maximum quality, minimize time to our project.

Conclusion

As with all aspects of application development, there is no silver bullet, no one right approach. It all depends on the team, project, time, money. Experiment! Consult with colleagues as the project structure affects the entire team. All good mood and interesting projects!

Log-Driven Development

Sergey — Tue, 02 Feb 2021 12:54:04 +0000

If we compare the application with the alive organism the bug could be compared with a disease. The cause of this "disease" can be a number of factors, including the environment of a particular user. This is really relevant when we are talking about web platform. Sometimes the reason is very complicated and the bug that was found through testing - the result of a number of actions.

As with human illnesses, no one can explain their symptoms better than a patient, any tester can tell what happened, better than the program itself.

What to do?

To understand what is happening, we need to have a history of the actions that the user performed in our application.

In order for our program to tell us that it hurts, we will take the logrock module and link it to ElasticSearch, LogStash, and Kibana for further analysis.

LogRock

The logrock module was born when we started working on the Cleverbrush product. This is software for working with vector graphics. Working with a graphics editor implies a huge number of application use cases. We are trying to save money and time, so we optimize everything, including testing. Covering each option with test cases is too expensive and irrational, especially since it is impossible to cover all options.

This module can organize modern logging approach for your application. Basing on the logs we test our application. In this article, I am going to tell you about how you can organize your logging system for searching bugs.

ElasticStack

ElasticSearch is a powerful full-text search engine.
LogStash is a system for collecting logs from various sources that can send logs to ElasticSearch as well.
Kibana is a web interface for ElasticSearch with many addons.

How does it work?

In case of an error (or just on demand), the application sends logs to the server where they are saved to a file. Logstash incrementally saves data to ElasticSearch - to the database. The user logs to Kibana and sees the saved logs.

Above you see a well set up Kibana. It displays your data from ElasticSearch. That can help you to analyze your data and understand what happened.

In this article, I am NOT considering setup ElasticStack!

Creating logging system

For example, we are going to integrate a logging system to single page application based on React.

Step 1. Installation:

npm install logrock --save

Step 2. Setup React Application

We need to wrap up the application with a component

import { LoggerContainer } from "logrock";

<LoggerContainer>
  <App />
</LoggerContainer>

LoggerContainer is a component that reacts to errors in your application and forms a stack.

A stack is an object with information about the user's operating system, browser, which mouse or keyboard button was pressed, and of course, the actions subarray, where all the user actions that he performed in our system are recorded.

LoggerContainer has settings, consider some of them.

<LoggerContainer
  active={true|false}
  limit={20}
  onError={stack => {
    sendToServer(stack);
  }}
>
  <App />
</LoggerContainer>

active enables or disables the logging.
limit sets a limit on the number of recent actions saved by the user. If the user performs 21 actions, then the first one in this array will be automatically deleted. Thus, we will have the last 20 actions that preceded the error.
onError is a callback that is called when an error occurs. The Stack object comes to it, in which all information about the environment, user actions, etc. is stored. It is from this callback that we need to send this data to ElasticSearch or backend or save it to a file for further analysis and monitoring.

Logging

In order to produce high-quality logging of user actions, we will have to cover our code with log calls.

The logrock module comes with a logger that is linked to the LoggerContainer.

For instance, we have a component:

import React, { useState } from "react";

export default function Toggle(props) {
  const [toggleState, setToggleState] = useState("off");

  function toggle() {
    setToggleState(toggleState === "off" ? "on" : "off");
  }

  return <div className={`switch ${toggleState}`} onClick={toggle} />;
}

In order to correctly cover it with a log, we need to modify the toggle method:

import React, { useState } from "react";
import logger from "logrock";

export default function Toggle(props) {
  const [toggleState, setToggleState] = useState("off");

  function toggle() {
    let state = toggleState === "off" ? "on" : "off";

    logger.info(`React.Toggle|Toggle component changed state ${state}`);

    setToggleState(state);
  }


  return <div className={`switch ${toggleState}`} onClick={toggle} />;
}

We have added a logger in which the information is divided into 2 parts. React.Toggle shows us that this action happened at the level of React, the Toggle component, and then we have a verbal explanation of the action and the current state that came to this component. This division into levels is not necessary, but with this approach, it will be clearer where exactly our code was executed.

We can also use the "componentDidCatch" method, which was introduced in React 16, in case an error occurs.

Interaction with the server

Consider the following example.

Let's say we have a method that collects user data from the backend. The method is asynchronous, part of the logic is hidden in the backend. How to properly add logging to this code?

Firstly, since we have a client application, all requests going to the server will pass within one user session, without reloading the page. In order to associate actions on the client with actions on the server, we must create a global SessionID and add it to the header for each request to the server. On the server, we can use any logger that will cover our logic like the example from the frontend, and if an error occurs, send this data with the attached sessionID to ElasticSearch, to the Backend plate.

Step 1. Generating SessionID on the client:

window.SESSION_ID = `sessionid-${Math.random().toString(36).substr(3, 9)}`;

Step 2. Requests.

We need to set the SessionID for all requests to the server. If we use libraries for requests, it is very easy to do this by declaring a SessionID for all requests.

let fetch = axios.create({...});

fetch.defaults.headers.common.sessionId = window.SESSION_ID;

Step 3. Connect SessionID to Log stack.

The LoggerContainer has a special field for SessionID:

<LoggerContainer
  active={true | false}
  sessionID={window.SESSION_ID}
  limit={20}
  onError={stack => {
    sendToServer(stack);
  }}
>
  <App />
</LoggerContainer>

Step 4. Interaction with backend.

The request (on the client) will look like this:

logger.info(`store.getData|User is ready for loading... User ID is ${id}`);

getData('/api/v1/user', { id })
  .then(userData => {
    logger.info(`store.getData|User have already loaded. User count is ${JSON.stringify(userData)}`);
  })
  .catch(err => {
    logger.error(`store.getData|User loaded fail ${err.message}`);
  });

How it works:

We write a log, before the request on the client. From our code, we can see that the download of data from the server will start now. We have attached the SessionID to the request. If our backend logs are covered with the addition of this SessionID and the request fails, then we can see what happened on the backend.

Thus, we monitor the entire cycle of our application, not only on the client but also on the server.

QA Engineer

Working with a QA engineer deserves a separate description of the process.

As we are startup, we have no formal requirements and sometimes not everything is logical.

If the tester does not understand the behavior, this is a case that at least needs to be considered. Also, often, a tester simply cannot repeat the same situation twice. Since the steps leading to the incorrect behavior can be numerous and non-trivial. In addition, not all errors lead to critical consequences such as Exception. Some of them can only change the behavior of the application, but not be interpreted by the system as an error. For these purposes, at staging, you can add a button in the application header to force the sending of logs. The tester sees that something is wrong, clicks on the button, and sends a Stack with actions to ElasticSearch.

In case, a critical error has occurred, we must block the interface so that the tester does not click further and get stuck.

For these purposes, we display the blue screen of death.

We see above the text with the Stack of this critical error, and below - the actions that preceded it. We also get the error ID, the tester just needs to select it and attach it to the ticket. Later this error can be easily found in Kibana by this ID.

For these purposes, the LoggerContainer has properties:

<LoggerContainer
  active={true | false}
  limit={20}
  bsodActive={true}
  bsod={BSOD}
  onError={stack => {
    sendToServer(stack);
  }}
>
  <App />
</LoggerContainer>

bsodActive enables / disables BSOD (disabling BSOD applies to production code)
bsod is React component. By default, it looks like the above screenshot.

To display the button in the UI LoggerContainer, we can use the hook:

const { getStackData, triggerError } = useLoggerApi();

triggerError(getStackData());

User interaction

Some logs are useful to the user. To output the user needs to use the stdout method:

<LoggerContainer
  active={true | false}
  limit={20}
  bsodActive={true}
  bsod={BSOD}
  onError={stack => {
    sendToServer(stack);
  }}
  stdout={(level, message, important) => {
    console[level](message);

    if (important) {
      alert(message);
    }
  }}
>
  <App />
</LoggerContainer>

stdout is the method that is responsible for printing messages.

In order for the message to become "important" it is enough to pass true to the logger as the second parameter. Thus, we can display this message to the user in a pop-up window, for example, if the data loading has failed, we can display an error message.

logger.log('Something was wrong', true);

Tips and tricks

Log applications, including in production, because no tester will find bottlenecks better than real users.
DO NOT forget to mention the collection of logs in the license agreement.
DO NOT log passwords, banking details, and other personal information!
Redundancy of logs is also bad, make messages as clear as possible.

Conclusion

When you release an app, life is just beginning for it. Be responsible for your product, get feedback, monitor logs, and improve it.

Server-Side Rendering from zero to hero

Sergey — Tue, 19 Jan 2021 07:45:40 +0000

In this article, we will analyze the impact of SSR on SEO optimization of the application.
We will walk with you through the way of porting a regular React application to SSR.
We will look at the processing of asynchronous operations in SSR applications.
We will see how to do SSR in applications with Redux Saga.
We will configure Webpack 5 to work with an SSR application.
We will also consider the intricacies of SSR: Generating HTML Meta Tags, Dynamic Imports, working with LocalStorage, debugging, and more.

A couple of years ago, while working on our Cleverbrush product, a friend of mine and I faced an SEO optimization problem. We created the website, which in theory, was supposed to sell our product, and it was a regular Single Page React Application, hasn't appeared in Google search results! In the course of several detailed analyses, the iSSR library was born, and our site finally appeared on the first page of Google search results. So let us work this out!

The Problem

The main problem with Single Page applications is that the server gives back a blank HTML page to the client. Its formation occurs only after all JS has been downloaded (this is all your code, libraries, framework). In most cases, this is more than 2 megabytes in size + code processing delays.

Even if a Google-bot knows how to execute JS, it only receives content after some time, which is critical for the site's ranking. Google-bot simply sees a blank page for a few seconds! This is a bad thing!

Google starts issuing red cards if your site takes more than 3 seconds to render. First Contentful Paint, Time to Interactive are metrics that will be underestimated with Single Page Application. Read more here.

There are also less advanced search engines that simply do not know how to work with JS. They will not index the Single Page Application.

Many factors still affect the ranking rate of a site, some of which we will analyze later in this article.

Rendering

There are several ways to solve the problem of a blank page when loading, consider a few of them:

Static Site Generation (SSG). Make a pre-render of the site before uploading it to the server. A very simple and effective solution. Great for simple web pages, no backend API interaction.

Server-Side Rendering (SSR). Render content at runtime on the server. With this approach, we can make backend API requests and serve HTML along with the necessary content.

Server-Side Rendering (SSR)

Let's take a closer look at how SSR works:

We need to have a server that executes our application exactly as a user would do in a browser. Making requests for the necessary resources, rendering all the necessary HTML, filling in the state.
The server gives the client the full HTML, the full state, and also gives all the necessary JS, CSS, and other resources.
The client receives HTML and resources, synchronizes the state, and works with the application as with a normal Single Page Application. The important point here is that the state must be synchronized.

A schematic SSR application looks like this:

From previously described SSR work, we can highlight the following problems:

The application is divided into the server and client sides. That is, we essentially get 2 applications. This separation should be minimal, otherwise, support for such application will be difficult.
The server should be able to handle API requests with data. These operations are asynchronous and are called Side Effects. By default, React's renderToString server-side method is synchronous and cannot handle asynchronous operations.
On the client, the application must sync state and continue to work as a normal SPA application.

iSSR

This is a small library that can solve the problems of asynchronous processing of requests for data and synchronization of state from the server to client. This is not another Next.JS killer, no! Next.JS is a great framework with many features, but in order to use it, you will need to completely rewrite your application and follow the rules of Next.JS.

Let's look at the example of how easy it is to port a regular SPA application to SSR.

For example, we have a simple application with asynchronous logic.

import React, { useState, useEffect } from 'react';
import { render } from 'react-dom';

const getTodos = () => {
  return fetch('https://jsonplaceholder.typicode.com/todos')
    .then(data => data.json())
};

const TodoList = () => {
  const [todos, setTodos] = useState([]);

  useEffect(() => {
    getTodos()
      .then(todos => setTodos(todos))
  }, []);

  return (
    <div>
      <h1>Hi</h1>
      <ul>
        {todos.map(todo => (
          <li key={todo.id} style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>{todo.title}</li>
        ))}
      </ul>
    </div>
  )
}

render(
  <TodoList />,
  document.getElementById('root')
);

This code renders a list of completed tasks using the jsonplaceholder service to emulate API interaction.

Let's move the application to SSR!

Step 1. Install dependencies

To install iSSR you need to do:

npm install @issr/core --save
npm install @issr/babel-plugin --save-dev

Install dependencies for the webpack 5 build system:

npm install @babel/core @babel/preset-react babel-loader webpack webpack-cli nodemon-webpack-plugin --save-dev

One of the non-obvious aspects of SSR application development is that some APIs and libraries can work on the client but not on the server. One such API is **fetch. This method is absent in **nodejs* where the server logic of our application will be executed. In order to work the same here, install the package:*

npm install node-fetch --save

We will use express for the server, but it doesn't matter, you can use any other framework:

npm install express --save

Let's add a module for serializing the application state on the server:

npm install serialize-javascript --save

Step 2. Configuring webpack.config.js

const path = require('path');
const NodemonPlugin = require('nodemon-webpack-plugin');

const commonConfig = {
  module: {
    rules: [
      {
        test: /\.jsx$/,
        exclude: /node_modules/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: [
                '@babel/preset-react'
              ],
              plugins: [
                '@issr/babel-plugin'
              ]
            }
          }
        ]
      }
    ]
  },
  resolve: {
    extensions: [
      '.js',
      '.jsx'
    ]
  }
}

module.exports = [
  {
    ...commonConfig,
    target: 'node',
    entry: './src/server.jsx',
    output: {
      path: path.resolve(__dirname, './dist'),
      filename: 'index.js',
    },
    plugins: [
      new NodemonPlugin({
        watch: path.resolve(__dirname, './dist'),
      })
    ]
  },
  {
    ...commonConfig,
    entry: './src/client.jsx',
    output: {
      path: path.resolve(__dirname, './public'),
      filename: 'index.js',
    }
  }
];

To compile an SSR application, the webpack config file must consist of two configurations (MultiCompilation). One for building the server, the other for building the client. We are passing an array to module.exports.
To configure the server, we need to set target: 'node'. Target is an optional for the client. By default, webpack config has target: ‘web’. target: 'node' allows webpack to handle server code, default modules such as path, child_process, and more.
const commonConfig - common part of the settings. Since the server and client code share the same application structure, they must handle JS the same way.

You need to add a plugin to babel-loader:
@issr/babel-plugin

This is a helper @issr/babel-plugin that allows you to track asynchronous operations in your application. Works great with babel/typescript-preset, and other babel plugins.

Step 3. Modification of the code.

Let's move the general logic of our application into a separate file App.jsx. This is necessary so that only the rendering logic remains in the client.jsx and server.jsx files, nothing else. Thus, we will have the entire application code in common.

App.jsx:

import React from 'react';
import fetch from 'node-fetch';
import { useSsrState, useSsrEffect } from '@issr/core';

const getTodos = () => {
  return fetch('https://jsonplaceholder.typicode.com/todos')
    .then(data => data.json())
};

export const App = () => {
  const [todos, setTodos] = useSsrState([]);

  useSsrEffect(async () => {
    const todos = await getTodos()
    setTodos(todos);
  });

  return (
    <div>
      <h1>Hi</h1>
      <ul>
        {todos.map(todo => (
          <li key={todo.id} style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>{todo.title}</li>
        ))}
      </ul>
    </div>
  );
};

client.jsx:

import React from 'react';
import { hydrate } from 'react-dom';
import { App } from './App';

hydrate(
  <App />,
  document.getElementById('root')
);

We changed the default React render method to hydrate, which works for SSR applications.

server.jsx:

import React from 'react';
import express from 'express';
import { renderToString } from 'react-dom/server';
import { App } from './App';

const app = express();

app.use(express.static('public'));

app.get('/*', async (req, res) => {
const html = renderToString(<App />);

  res.send(`
  <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
    <div id="root">${html}</div>
</body>
</html>
`);
});

app.listen(4000, () => {
  console.log('Example app listening on port 4000!');
});

In the server code, note that we have to share the folder with the built SPA webpack application:
app.use (express.static ('public'));
Thus, the HTML received from the server will continue to work as a regular SPA

Step 4. Handling asynchronous functions.

We have separated the common part of the application, connected the compiler for the client and server parts of the application. And now let's solve the rest of the problems associated with asynchronous calls and state.

To handle asynchronous functions, you need to wrap them in the useSsrEffect hook from the @issr/core package:

App.jsx:

import React from 'react';
import fetch from 'node-fetch';
import { useSsrEffect } from '@issr/core';

const getTodos = () => {
  return fetch('https://jsonplaceholder.typicode.com/todos')
    .then(data => data.json())
};

export const App = () => {
  const [todos, setTodos] = useState([]);

  useSsrEffect(async () => {
    const todos = await getTodos()
    setTodos(todos);
  });

  return (
    <div>
      <h1>Hi</h1>
      <ul>
        {todos.map(todo => (
          <li key={todo.id} style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>{todo.title}</li>
        ))}
      </ul>
    </div>
  );
};

In server.jsx, replace the standard renderToString with the serverRender from the @issr/core package:

import React from 'react';
import express from 'express';
import { serverRender } from '@issr/core';
import serialize from 'serialize-javascript';
import { App } from './App';

const app = express();

app.use(express.static('public'));

app.get('/*', async (req, res) => {
  const { html } = await serverRender(() => <App />);

  res.send(`
  <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
    <div id="root">${html}</div>
    <script src="/index.js"></script>
</body>
</html>
`);
});

app.listen(4000, () => {
  console.log('Example app listening on port 4000!');
});

If you run the application straight away, nothing will happen! We will not see the result of executing the getTodos asynchronous function. Why not? We forgot to sync state. Let's fix this.

In App.jsx, replace the standard setState with useSsrState from the @issr/core package :

App.jsx:

import React from 'react';
import fetch from 'node-fetch';
import { useSsrState, useSsrEffect } from '@issr/core';

const getTodos = () => {
  return fetch('https://jsonplaceholder.typicode.com/todos')
    .then(data => data.json())
};

export const App = () => {
  const [todos, setTodos] = useSsrState([]);

  useSsrEffect(async () => {
    const todos = await getTodos()
    setTodos(todos);
  });

  return (
    <div>
      <h1>Hi</h1>
      <ul>
        {todos.map(todo => (
          <li key={todo.id} style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>{todo.title}</li>
        ))}
      </ul>
    </div>
  );
};

Let's make changes to client.jsx to synchronize the state transferred from the server to the client:

import React from 'react';
import { hydrate } from 'react-dom';
import createSsr from '@issr/core';
import { App } from './App';

const SSR = createSsr(window.SSR_DATA);

hydrate(
  <SSR>
    <App />
  </SSR>,
  document.getElementById('root')
);

window.SSR_DATA is an object passed from the server with a cached state for synchronization on the client.

Let's make the transfer state on the server:

import React from 'react';
import express from 'express';
import { serverRender } from '@issr/core';
import serialize from 'serialize-javascript';
import { App } from './App';

const app = express();

app.use(express.static('public'));

app.get('/*', async (req, res) => {
  const { html, state } = await serverRender(() => <App />);

  res.send(`
  <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <script>
      window.SSR_DATA = ${serialize(state, { isJSON: true })}
    </script>
</head>
<body>
    <div id="root">${html}</div>
    <script src="/index.js"></script>
</body>
</html>
`);
});

app.listen(4000, () => {
  console.log('Example app listening on port 4000!');
});

Please note that the serverRender function passes not only HTML but also the state that passed through useSsrState, we pass it to the client as a global variable SSR_DATA. On the client, this state will be automatically synchronized.

Step 5. Build scripts

It remains to add scripts to package.json:

"scripts": {
 "start": "webpack -w --mode development",
 "build": "webpack"
},

Redux and other State Management libraries

iSSR perfectly supports various state management libraries. While working on iSSR, I noticed that React State Management libraries are divided into 2 types:

Implements working with Side Effects on a React layer. For example, Redux Thunk turns the Redux dispatch call into an asynchronous method, which means we can implement SSR as in the example above for setState. The example of redux-thunk is available here.
Implement working with Side Effects on a separate layer from React. For example, Redux Saga brings work with asynchronous operations to Sagas.

Let's look at the example of SSR implementation for an application with Redux Saga.

We will not consider this example in as much detail as the previous one. The complete code can be found here.

Redux Saga

For a better understanding of what is happening, read the previous chapter

The server runs our application through serverRender, the code is executed sequentially, performing all the useSsrEffect operations.

Conceptually, Redux does not perform any asynchronous operations when working with sagas. Our task is to send an action to start an asynchronous operation in the Cag layer, separate from our react-flow. In the example from the link above, in the Redux container, we execute:

useSsrEffect(() => {
 dispatch(fetchImage());
});

This is not an asynchronous operation! But iSSR realizes that something has happened in the system. iSSR will go through the rest of the React components doing all the useSsrEffect and upon completion of the iSSR will call the callback:

const { html } = await serverRender(() => (
 <Provider store={store}>
   <App />
 </Provider>
), async () => {
 store.dispatch(END);
 await rootSaga.toPromise();
});

Thus, we can process asynchronous operations not only on the React level but on other levels too, in this case, firstly we put the sagas we need to execute, then which we started the serverRender callback and wait for them to end.

I have prepared many examples of using iSSR, you can find them here.

SSR tricks

There are many challenges along the way in developing SSR applications. The problem of asynchronous operations is just one of them. Let's take a look at other common problems.

HTML Meta Tags for SSR

An important aspect of SSR development is using correct HTML meta tags. They tell the search bot the key information on the page.
To accomplish this task, I recommend you to use one of the modules:
React-Helmet-Async
React-Meta-Tags
I have prepared some examples:
React-Helmet-Async
React-Meta-Tags

Dynamic Imports

To reduce the size of the final application bundle, the application can be divided into parts. For example, dynamic imports webpack allows you to automatically split your application. We can move individual pages into chunks. With SSR, we need to be able to handle the data pieces of the application as a whole. To do this, I recommend using the wonderful @loadable module.

Dummies

Some components may not be rendered on the server. For example, if you have a post and comments, it is not advisable to handle both asynchronous operations. Post data takes precedence over comments to it, it is this data that forms the SEO load of your application. Therefore, we can exclude unimportant parts using type checks:

if (typeof windows === 'undefined') {
}

localStorage, data storage

NodeJS doesn't support localStorage. We use cookies instead of localStorage to store session data. Cookies are sent automatically on every request. Cookies have limitations, for example:

Cookies are an old way of storing data, they have a limit of 4096 bytes (actually 4095) per cookie.
localStorage is an implementation of the storage interface. It stores data without an expiration date and is only cleared by JavaScript or clearing browser cache/locally stored data - as opposed to cookie expiration.

Some data needs to be passed in the URL. For example, if we use localization on the site, then the current language will be part of the URL. This approach will improve SEO as we will have different URLs for different localizations of the application and provide data transfer on demand.

React Server Components

React Server Components might be a good addition to SSR. Its idea is to reduce the load on the Bundle by executing the components on the server and issuing a ready-made JSON React tree. We saw something similar in Next.JS. Read more at the link

Routing

React Router supports SSR out of the box. The difference is that on the server the StaticRouter is used with the current URL passed, and on the client Router determines the URL automatically using the location API. Example

Debugging

Debugging on the server can be performed just like any debugging of node.js applications via inpsect.
To do this, add to the webpack.config for the nodejs application:

devtool: 'source-map'

And in the NodemonPlugin settings:

new NodemonPlugin({
  watch: path.resolve(__dirname, './dist'),
  nodeArgs: [
    '--inspect'
  ]
})

Also, to improve work with the source map, you can add the module

npm install source-map-support --save-dev

In nodeArgs of NodemonPlugin options add:
‘--Require =“ source-map-support / register ”’
Example

Next.JS

If you are building an application from scratch, I recommend you to pay attention to this framework. It is currently the most popular solution for building SSR-enabled applications from scratch. One of the advantages is that everything comes out of the box (build system, router). The minus - it is necessary to rewrite the existing application, use the Next.JS approaches.

SEO isn't just about SSR!

Google bot SEO criteria include many metrics. Renders data, gets the first byte, etc. this is just a part of the metrics! When SEO optimization of the application, it is necessary to minimize image sizes, bundles, use HTML tags and HTML meta tags correctly, and so on.
To check your site for SEO optimization, you can use:
lighthouse
sitechecker
pagespeed

Conclusion

In this article, I have described the main problems, but not all of developing SSR applications. But the purpose of this article is to show you that SSR is not that bad. With this approach, we can live and make great apps! I wish everyone who has read to the end successful and interesting projects, fewer bugs, and good health at this difficult time for all of us!