Forem: Nik Shevchenko

The Road to GraphQL At Enterprise Scale

Nik Shevchenko — Tue, 07 Nov 2023 15:11:16 +0000

The original one is https://shevchenkonik.com/blog/graphql-at-scale

Intro
Backstory
I. Introduce GraphQL Federation as API Gateway
II. Decompose monolith service to GraphQL Subgraphs (Microservices)
III. Mesh and/or add support to existing services
- Transport Service that consumes many API/Sources types
- GraphQL as a part of existing services written on Java, Kotlin, .NET, etc
IV. Schema Registry
V. Observability
Closing Thoughts

Intro

GraphQL was designed to allow your API to evolve continuously in response to new product requirements without the burden of versioning, simplify the process of getting data from different sources and support typings for API out of the box.

Our team is responsible for developing an API — a single endpoint that provides all the necessary data to render the UI for clients and core web infrastructure for the customer portal. Several years ago, we initially used REST endpoints to gather data from multiple services. However, over time, the number of these API calls has grown, and it has become increasingly difficult to manage this system swiftly and maintain up-to-date synchronization between teams.

We started looking for a solution that would help us easily support the development of the portal and the ability to migrate the current monolith to microservices.
The experience of big tech companies (e.g. Shopify, PayPal, Atlassian, Airbnb, GitHub, Twitter, and so on) with successful usage of GraphQL for their core products that have High Load & High Availability at the same time was a vital sign for introducing GraphQL in our scope.

In this article, I focus on integrating GraphQL within an enterprise as an infrastructure without considering load balancing, external infrastructure, cache configurations and other important things not directly related to our migration from perspective of GraphQL.

Backstory

The situation when you can introduce GraphQL as a core service for an enterprise from the scratch is a dream
because you usually have existing infrastructure, and you need to integrate it into the existing codebase as smoothly as possible.

Our case is not an exception. We had an infrastructure for the customer portal based on multiple REST calls from dozens of UI applications and BFFs to thousands of microservices. In that case, you have the possibility to simplify the work through libraries that contains some needed typings, the logic around HTTP clients, shared configuration, etc.
Services could be written with different protocols, e.g., SOAP, RPC, REST... Most of the services exposes through REST for NodeJS and it expects different HTTP headers.

We already used libraries and shared configurations for our NodeJS services and UI-related applications (React, Vue, Angular, or pure HTML) for these purposes.
But whenever you need to update something in that library or within shared configuration, it takes a lot of work because you should patch every service & application and spend many hours with product teams and infrastructure teams.

The goal was to implement such a system that can be maintained by one team and has everything from the data perspective for portal purposes.
In the meantime, product teams don't need to go deeply into details to realize how to call new services, which headers they should provide, and how to see API (Swagger, Postman, etc.).

GraphQL had the perfect fit for that purpose and contained many additional benefits for us:

Single typed endpoint for different clients (Web, Mobile, BFF, internal services written on Kotlin, Java, .NET, etc.).
Playground with the described schema that is a super helpful feature fo quick testing new features (e.g. GraphiQL).
The unified way of exposing data through a single endpoint.
Language agnostic.

As a team, we are responsible for maintaining the entire portal.
The excellent direction is a simplification of the process of how clients can get all the needed data.
We had a monolith service for the whole portal that combines all needed logic: auth, data about users, features, meta information, analytics, and so on.
A simplified diagram without extra infrastructure (load balancing, caching, etc.) might look like this:

The problem with this approach is the amount of redeploys and the possibility of breaking some core functionality when upgrading product-related modules.
As a team, we looked very carefully at each PR, as product teams could change functions, interfaces, and general code used in different modules in the monolith, and it was essential to keep track of every change in each PR. The number of such PRs could be in the dozens per day, which meant that our team had spent much time manually reviewing and revising. And... As you know, this is a place for mistakes.

I. Introduce GraphQL Federation as API Gateway

First of all, you need add layer for future microservices architecture as a gateway which processes incoming requests to GraphQL.

GraphQL Gateway is primarily responsible for serving GraphQL queries to consumers.
It takes a query from a client, breaks it into smaller sub-queries, and executes that plan by proxying calls to the appropriate downstream subgraphs.
When we started our journey, there was only Apollo Federation in the arena, and we used it.
Still, now you can look at other options (e.g. Mercurius, Conductor, Hot Chocolate, Wundergraph, Hasura Remote Schemas), compare benchmarks and decide what's important and preferable for your needs.
The Gateway provides a unified API for consumers while giving backend engineers flexibility and service isolation.

Our Monolith is GraphQL Subgraph for now.
As usual, it has the same characteristics as microservice, but from the perspective of our migration is still a monolith but with integrated GraphQL.
This step is important to define GraphQL schema based on GraphQL principles and reduce the approach when we move the REST approach to the GraphQL world.
If you're a newbie in GraphQL, I highly recommend these articles:

II. Decompose monolith service to GraphQL Subgraphs

The decomposition of the monolith is a long process, it doesn't matter at which language service was written.
From that perspective, think of this step as a long process which not directly connected with GraphQL, but we use the benefits of GraphQL to decompose it into microservices.
We decomposed the first module of the monolith as a GraphQL subgraph and added it as a subgraph to the Federation schema:

For now, Analytics is not a module of monolith service anymore.
It works as a GraphQL subgraph and isolates all needed business logic within itself.

The GraphQL Federation by Apollo offers a way how to decompose GraphQL monolith to several subgraphs, but if you use Mercurius as I mentioned above or something else, you can use the same approach with opensource solutions, like GraphQL Tools by The Guild.
In the current state, two existing subgraphs have identical resolvers for analytics, and we should mark one resolver as deprecated & second one as used.
Technically, you just need to mark migrated GraphQL field with GraphQL directives in two places, as @shareable one in monolith to indicate that field will be received from another subgraph and @override in the new subgraph to indicate a new field.

# GraphQL Monolith

type Query {
  analytics: [Analytics]
}

type Analytics @shareable {
  id: ID!
}

# GraphQL Analytics Subgraph

extend type Query {
  analytics: [Analytics]
}

type Analytics @override(from: "monolith") {
  id: ID!
}

GraphQL Gateway processes it during schema composition and creates a single schema with correctness data sources, all analytics requests go to Analytics Subgraph and you can easily deprecate the legacy part of the monolith in favor of the new service.

If you need to migrate fields between subgraphs with slowly shift traffic to test new service before going to production for all clients, please read article by Reddit team, how they've migrated their schema between subgraphs with Blue/Green Subgraph deployment.

III. Mesh and introduce GraphQL to existing services

We have hundreds of services that were written in the latest 15 years, which means services were developed in different languages by different teams and have different states of support for now.
A bunch of services requires one type of HTTP Headers, which should be provided, another bunch has different HTTP Headers and different API sources (e.g., REST, SOAP, RPC),
and we need to get some data from them to calculate some business data within our particular infrastructure.

We have several ways to manage it and unify the process for GraphQL infrastructure.

Transport Service that consumes many API/Sources types

The transport service is a standalone service, a layer (API gateway) between existing services and our infrastructure.

This approach is adding another layer within the infrastructure to process everything in one place. It has benefits:

Expose GraphQL schema in one place for the whole of our infrastructure and don't mind about other services within GraphQL infrastructure.
Progressively migrate existing non-GraphQL services under a unified GraphQL API.
Use one caching strategy for the whole GraphQL infrastructure and easily maintain it.
Unify the logic for other services in one place.
It can be developed and maintained by a single team, which speeds up the process of migrating the monolith.

Great news, we have an open-source solution by The Guild GraphQL Mesh that covers many APIs and could be easily extended by writing needed plugins.

As usual, every approach has some cons & props. Let’s take a look at the cons:

A transport service is a bottleneck of the system because it processes all requests from subgraphs in one place, and you should be careful because it multiplies the number of requests for complex GraphQL queries. So, you need a good single-core processor because NodeJS runs on a single thread, and be careful with performance. Of course, you should have vertical & horizontal auto-scaling to process traffic spikes.
An extra layer in your infrastructure increased complexity. Better to decrease the complexity of the system (the best code is no code at all).

GraphQL as a part of existing services written on Java, Kotlin, .NET, etc.

More native way of integration GraphQL in existing services is to do it with adding GraphQL servers.
GraphQL is language agnostic, so we don’t have a lock for using different languages.
Let’s take Kotlin as an example, e.g. Kotlin GraphQL Server.
As we integrate Messages Service as a subgraph, we don't need to go through GraphQL Transport Service (GTS) and can get all needed data directly from the source.
The diagram below shows that Java & Kotlin services are integrated into the Federation schema as subgraphs and the system’s complexity is extremely low.

For our flexibility, we can combine both approaches; if we introduce a new service, we can easily get all the needed data from subgraphs,
but if we need some existing data from not integrated services, we can use GTS as transport or add existing service as a subgraph.

After migrating the monolith to microservices, we will still have a core service that may contain some data, or we can get rid of it completely.

IV. Schema Registry

During development and especially in situations when several teams contribute to the GraphQL infrastructure, our schema is growing and changing. To support this healthy schema evolution, we are able to use the GraphQL Schema Registry.

The GraphQL Schema Registry is a persistent system element that retains all schemas and schema modifications for each subgraph.
Its role encompasses validating individual DGS schemas and merged schemas, ensuring compliance.
Lastly, the registry assembles the unified schema and supplies it to the gateway.

GraphQL Schema Registry serves the main purpose of preventing breaking changes. This empowers you to strategize in advance and implement any required schema modifications promptly.

In the first implementation, we used an approach without a Schema Registry, and we had a dynamic composition of schema during runtime. We had no way to validate changes and prevent breaking schema on production.

Integrated Schema Registry to our scope we can describe by next diagram:

Every subgraph pushes schema in runtime to Schema Registry Service that processes it and validates it for breaking changes. Also, it exposes a unified schema, which is used by Gateway as a main schema of GraphQL infra.

When Schema Registry Service gets a new schema of the updated subgraph, it starts processing the schema from the perspective of composition to the whole schema and checks the main directions:

The updated schema is a valid GraphQL schema & could be executed.
The updated schema composes seamlessly with the rest of the subgraph's schemas to create a valid composed schema for Gateway.
The updated schema is backward compatible and clients shouldn't upgrade their codebase.

If all of the above conditions are met, then the schema is checked into the Schema Registry. The service store schema in Database and cache it in Redis.
The next step is to publish changes through Kafka to Gateway, and we have updated the schema within the environment.

The good news is that we have several options not to create our custom solution from scratch and spend a lot of time on it:

Completely open-sourced solution written with similar tools
The open-sourced solution by The Guild that could be self-hosted
The solution by Apollo, they deliver an utterly outsourced solution, which I don't really like because it has many limitations and questions from the perspective of GDPR and more.

V. Observability

Observability can be achieved with a set of tools that we combine to get the best possible way of detecting ongoing issues and preventing a bunch of them.
We split the observability into three directions:

Alerting - immediately notify when something goes wrong or a metric begins to form that leads to a problem
Discovery - determine what exactly isn't working properly
Finding - debug why something isn't working as expected

As I said at the begging of the article, I will not go into the implementation details. Alerting & discovery can be done similarly as for other services in your company, like with OpsGenie, Grafana, Graylog, and so on.

From the perspective of the realization of GraphQL infrastructure, the interesting direction is "Finding".
How to find the problem? How to find the bottleneck of the system? Distributed Tracing System (DTS) will help answer this question.
Distributed tracing is a method of observing requests as they propagate through distributed environments.
In our scenario, we have dozens of subgraphs, gateway, and transport layer through which the request goes.
We have several tools that can be used to detect the whole lifecycle of the request through the system, e.g. Jaeger, Zipkin or solutions that provided DTS as a part of the solution NewRelic.

For example, let’s take a look at GitHub repository with integrated Open Telemetry to Apollo Federation.

Based on the UI provided by DTS, we can easily find bottlenecks of the system and tune the system’s performance, that important one from the perspective of scaling infrastructure to the whole company.

Closing Thoughts

GraphQL Federation has lowered the connectivity of the monolith and works as a perfect solution for the different client (Web, Mobile) needs.
The addition of GraphQL had fantastic feedback from product teams because they had a typed contract inside their TypeScript/Kotlin codebase and a beautiful playground where
they can make an example of new functionality in a matter of minutes.

Despite our positive experience as a team, GraphQL Infrastructure migration requires high commitment from other teams and seamless cross-functional collaboration,
as you remembered we had several approaches with unification HTTP headers and API protocols and integration GraphQL servers should be on the side of partner teams,
not to overload the core team.
It also requires some work as a developer advocate because explaining how to work/develop properly with GraphQL and what the best practices are is necessary.
The trend of usage is increasing and this improves the situation:

Download statistics for npm graphql package

Technologies are constantly changing and our responsibility to choose aligned technologies for particular purpose.
From my perspective and experience, GraphQL is good candidate for core infrastructure for customer-centric products.

Resilience and fault tolerance of Web Oriented Services

Nik Shevchenko — Tue, 31 May 2022 20:29:27 +0000

The original one is https://shevchenkonik.com/blog/resilience-web-services

Introduction
Resilience methodologies
- Identifying failure points in architecture
Load Balancing
- Load Balancing Algorithms
- Internal-Communication Load Balancing
- External Load Balancing with HAPRoxy
- Health Check
Cache
- In-Memory Cache
- External Cache
- No Cache

Introduction

Microservice architecture have become the new model for building modern cloud-native applications as a part of distributed systems.

One of the key aspects of building modern web-oriented distributed systems is resilience and fault tolerance. Fault tolerance is the ability for a system to remain in operation even if some components used to build the system fail. With synchronous communication between microservices, it is important that the failure of one service doesn't cause other services to fail as well.

Otherwise, the unavailability of a single service can cause further microservice to fail until the entire system is no longer available.

I would like to repeat definitions given by Adrian Hornsby from AWS Patterns for Resilient Architecture, AWS, 2019:

Resilience is:

art of being able to run system with failures.

ability for a system to handle and eventually recover from unexpected conditions.

Also, one more thing in terms of architecture is prevented cascading failures.

This article will cover only the questions of resilience and fault tolerance with high availability. The issues of monitoring, alerting, logging, CI/CD, health checks, etc. will not be considered in this article.
Some examples will use TypeScript & NestJS.

Resilience methodologies

Before we start looking at ways how to solve the problems relevant with resilience and fault tolerance, let's understand how to index these issues. One of ways is Chaos Testing, you can find more details here, and this is brilliant article about Chaos Testing. Think about scenarios like below and find out how the system behaves:

Service X isn't able to communicate with Service Y.
DB isn't accessible.
Service X isn't able to connect to the Service Y with HTTP, e.g. Service Y supports only HTTPS.
Server is down or not responding.
Inject timeouts into the tested services.

Identifying failure points in architecture

If you have been troubleshooting your services and individual service performance, you have already likely identified a few services that either receive or send a lot of requests.

Optimizing those requests is important and potentially could help you to prolong availability of whole system. But, given a high enough load, the services sending or receiving those requests are likely failure points for your application.

Load Balancing

Microservices have the benefit that each microservice can be scaled independently of the other microservices. For that it is needed that the call to a separated microservice can be distributed to several instance by a load balancer. Load balancing solutions allow an application to run on multiple network nodes, removing the concern about a single point of failure

The good approach for Load Balancing is HAPRoxy, which stands for High Availability Proxy, is a popular open source solution TCP/HTTP Load Balancer and proxying solution.

Load Balancing Algorithms

The load balancing algorithms that are used determines which server will be selected when load balancing. HAPRoxy offers several options for algorithms. In addition, to the load balancing algorithm, servers can be assigned a weight parameter to manipulate how frequently the server is selected, compared to other servers. In HAPRoxy Configuration Manual you can find all existing algorithms, I would like to use roundrobin (as a default one) for our purposes but if you have specific needs, please use your own algorithm.

Internal-Communication Load Balancing

The idea of internal load balancing can be implemented with a load balancer for each microservice. The load balancer must obtain the information about the currently available microservices from the service discovery:

Decentralized load balancing is great idea, we could deploy our microservices canary and load balancer is single point of failure only for one microservice. The entire microservices' system should work without one microservice, important that the failure of one microservice doesn't cause other microservices to fail as well.

External Load Balancing with HAPRoxy

HAProxy is a very performant open source reverse proxy that works with both Layer 4 and Layer 7 protocols.
It’s written in C and is designed to be stable and use minimal resources, offloading as much processing as possible to the kernel. Like JavaScript, HAProxy is event driven and single threaded.

We should provide multiple HAPRoxy instances per each our Data Center to be able that we don't have a failure point of this layer for high availability.

Floating IPs let you redirect all incoming network traffic between any of existing HAPRoxy within the same datacenter (EU1 in the scheme below). It can be resolved with Keepalived and Virtual Router Redundancy Protocol. As a result you can use floating IPs to create server infrastructures without single points of failure.

Health Check

HAProxy uses health checks to determine if a backend server is available to process requests. This avoids having to manually remove a server from the backend if it becomes unavailable. The default health check is to try to establish a TCP connection to the server i.e. it checks if the backend server is listening on the configured IP address and port.

If a server fails a health check, and therefore is unable to serve requests, it is automatically disabled in the backend i.e. traffic will not be forwarded to it until it becomes healthy again. If all servers in a backend fail, the service will become unavailable until at least one of those backend servers becomes healthy again.

For certain types of backends, like database servers in certain situations, the default health check is insufficient to determine whether a server is still healthy.

Cache

Caching is a great and simple technique that helps improve your app's performance and resilience. It acts as a temporary data store providing high performance data access. I would concentrate on three different strategies which could be combined are In-Memory Cache, External Cache (Redis, Memcached, etc.), No Cache strategy.
But how cache help us increase fault tolerance and resilience? If the service X had a successful request to service Y, we cached the response in Redis. But then some problems happened in service Y, we get the same request for the data again, we can go to the cache and return the user the correct information from the cache. But it is important to remember the right caching strategy.

In-Memory Cache

The simplest cache is based on the In-Memory Cache. In-Memory Cache represents a cache stored in the memory of the web server.

This is the fastest one, but it has a strong disadvantage in terms of data compatibility. The cache is destroyed between crashed, re-deployments, deployments of services. One of potential cases for storing data in memory cache of the web server is store sensitive data. Because Redis was designed not for maximum security but for maximum performance and simplicity. That means, every engineer within trusted environment can read non-encrypted data in key-value store.

Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.

The simplest implementation of In-Memory Cache based on the interface:

interface CacheClientInterface {
    get<T>(key: string): Promise<T | null>;
    put<T>(key: string, value: T, time: number): Promise<T>;
    delete<T>(key: string): Promise<void>;
}

I would like to use memory-cache package as a quick solution. An example of using combined with default lifecycle events from NestJS, onModuleInit and onApplicationShutdown help us initialize in-memory cache when application is started and clear in-memory cache when application is off.

import inMemoryCache from 'memory-cache';

interface CacheClientInterface {
    get<T>(key: string): Promise<T | null>;
    put<T>(key: string, value: T, time: number): Promise<T>;
    delete<T>(key: string): Promise<void>;
}

class InMemoryCacheClient implements CacheClientInterface {
    private inMemoryCache;

    constructor() {}

    async onModuleInit() {
        this.inMemoryCache = new inMemoryCache.Cache();
    }

    onApplicationShutdown() {
        this.inMemoryCache?.clear();
    }

    async get<T>(key: string): Promise<T> {
        return this.inMemoryCache.get(key);
    }

    async put<T>(key: string, val: T, time: number): Promise<T> {
        this.inMemoryCache.put(key, val, time);
    }

    async delete(key: string): Promise<void> {
        this.inMemoryCache.del(key)
    }
}

External Cache

It's slower than an in-memory cache but should be faster than hitting the source of truth.
It also prevents the cache from being wiped out between crashes and deployments,
or when 3rd party service has issues for some reasons, and we can prevent starting cascading failures.
We have several opensource options of noSQL key-value in-memory data storage systems, e.g. Redis, Memcached.
I would like to use Redis (but if you need more details of comparing these two opensource solutions, please read Redis or MemCached).
Also, we should implement CacheClientInterface from the example below. I will consider a third-party cache using Redis as an example:

Redis can be accessed by all the processes of your applications, possibly running on several nodes (something local memory cannot achieve).
Redis memory storage is quite efficient, and done in a separate process.
Redis can persist the data on disk if needed.
Redis can replicate its activity with a master/slave mechanism in order to implement high-availability.

No cache

In this approach, an application talks directly with external services.

Let's start with external cache, we have several options:

Redis
ElasticSearch Cache

Redis is a powerful service exposing several useful data structures while providing many commands to interact with them. But Redis has a limitation: the data stored in a Redis instance must fit completely in memory. For this reason, Redis is best used only as a cache, not as a data source.

Where the rest of the problem is and how to solve it we are going to explore in Part 2 of our series.

React, TypeScript & Mobx

Nik Shevchenko — Sun, 23 Aug 2020 17:09:55 +0000

The original post: https://shevchenkonik.com/blog/react-typescript-mobx

I want to share my R&D process of using React, TS, and Mobx. It’s about conceptual approaches to building large scalable applications. The second part of this article series will talk about building real application with 3rd services and ML preprocessing 🔥

Overview

I built a web application that allows us to work with Mobx, TypeScript, React, and 3rd API Services. This article focuses on practical examples as the best way to understand the concepts of technologies and part of patterns theory.

I'll use two ways of organizing React Components for showing different ways of using stores, Class-based Components, and Functional Components with React Hooks.

Setup Application

I'll provide a short introduction to the setup process, you can skip this section if you already know it. If you need a more specific application, please use custom webpack/rollup/parcel or something else, but we'll use Create React App with TypeScript support for simple process of setup:

Install create-react-app with TypeScript

npx create-react-app typescript-mobx-react --template typescript

Install types needed for TypeScript as development dependencies

npm i --save-dev typescript @types/node @types/react @types/react-dom @types/jest

Install Mobx and its connection to React

npm i mobx-react

App's source code is nested beneath the src directory. And structure of application will be:

├── src
│   ├── components
│   ├── containers
│   ├── contexts
│   ├── hocs
│   ├── hooks
│   ├── pages
│   ├── services
│   ├── stores
│   └── index.tsx
├── dist
├── node_modules
├── README.md
├── package.json
└── .gitignore

Setup Services & Stores

I started developing my application by designing stores in the domain area. A few main concepts of stores composition that I need for my application:

Easy communication between stores.
Root store composition with children stores.
Separate communications and stores.

So I designed my application approach with MVC like Design Pattern and layered architecture as follows:

All backend communications (in our case we use only Spotify API as 3rd Service) are done by Service Layer.
The store has a state of the application so it consumes service Defining data stores. All service functions will be called in the only store, components execute Store actions when the state is needed.
Presentational Component can use the store directly by injecting the store or Props from Container Component can be passed in it.
Container or Presentational Component can invoke store actions and automatic rendering of components will be done by Mobx.

Services are a place for communication between application and Backend Services. We use this separation for a more flexible and elegant way to organize our codebase, cause if we'll use service calls inside the store then we'll find complicated stores with harder test writing process when an application will scale. Inside a store, we call the service method and update the store only inside the @action decorator of Mobx. Service methods are needed only for communication and they don’t modify Stores, we can modify observable variables only inside @action calls in Stores.

The main responsibilities of Stores:

Separate logic and state with components.
A standalone testable place that can be used in both Frontend and Backend JavaScript. And you can write really simple unit tests for your Stores & Services with any codebase size.
A single source of truth of Application.

An alternative, more opinionated way of organizing stores is using mobx-state-tree, which ships with cool features as structurally shared snapshots, action middlewares, JSON patch support, etc out of the box.

But Mobx-State-Tree (MST) is a like framework based on Mobx and when you start using MST you need to implement practices and API from MST. But I want to use more native way of my codebase and less overkill for my needs. If you want to see the big codebase of MST and Mobx, you can check my previous big opensource project of data labeling and annotation tools for ML on React, Mobx, and MST - Label Studio and Frontend Part of Label Studio. In MST we have many awesome things like a Tree, Snapshots, Time Travelling, etc.

Organizing Stores

The primary purpose of Mobx is to simplify the management of Stores. As application scales, the amount of state you manage will also increase. This requires some techniques to break down your application state and to divvy it up across a set of stores. Of course, putting everything in one Store is not prudent, so we apply divide-and-conquer instead.

And don't write your business logic in your components, because when you writing it, you have no way to reuse it. Better way is writing the business logic with methods in the Stores and call these methods from your containers and components.

Communication between stores

The main concept of stores communication is using Root Store as a global store where we create all different stores and pass global this inside a constructor of Root Store. Stores are the place of the truth for application.

Root Store collects all other stores in one place. If your children store needs methods or data from another store, you can pass this into a store like as User Store for easy communication between stores. The main advantages of this pattern are:

Simple to set up your application.
Supports strong typings well.
Makes complex unit tests easy as you just have to instantiate a root store.

/**
 * Import all your stores
 */
import { AuthStore } from './AuthStore';
import { UserStore } from './UserStore';

/**
 * Root Store Class with
 */
export class RootStore {
  authStore: AuthStore;
  userStore: UserStore;

  constructor() {
    this.authStore = new AuthStore();
    this.userStore = new UserStore(this); // Pass `this` into stores for easy communication
  }
}

And then you can use methods from Auth Store in User Store for example:

import { observable, action } from 'mobx';
import { v4 as uuidv4 } from "uuid";
import { RootStoreModel } from './rootStore';

export interface IUserStore {
  id: string;
  name?: string;
  pic?: string;
}

export class UserStore implements IUserStore {
  private rootStore: RootStoreModel;

  @observable id = uuidv4();
  @observable name = '';
  @observable pic = '';

  constructor(rootStore?: RootStoreModel) {
    this.rootStore = rootStore;
  }

  @action getName = (name: string): void => {
    if (rootStore.authStore.id) {
      this.name = name;
    }
  }
}

Context Provider to pass Store

Context provides a way to pass data through the component tree without having to pass props down manually at every level. Nothing spectacular about it, better to read React Context if you are unsure though. Let's create Provider for our Application:

import React, { FC, createContext, ReactNode, ReactElement } from 'react';
import { RootStoreModel } from '../stores';

export const StoreContext = createContext<RootStoreModel>({} as RootStoreModel);

export type StoreComponent = FC<{
  store: RootStoreModel;
  children: ReactNode;
}>;

export const StoreProvider: StoreComponent = ({
  children,
  store
}): ReactElement => {
  return (
    <StoreContext.Provider value={store}>{children}</StoreContext.Provider>
  )
}

And you can use in the entry point of Application:

import React from 'react';
import ReactDOM from 'react-dom';

import { StoreProvider } from './store/useStore';

import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <StoreProvider>
      <App />
    </StoreProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

Class and Functional Components

We can use both ways of our components — Class-based components and Functional components with React Hooks as a modern way to organize React Application.

If you are using use only Functional Components with React Hooks, you can use mobx-react-lite instead of mobx-react to reduce size bundle. If you are using Class-based components and Functional components, please use only mobx-react@6 which includes mobx-react-lite and uses it automatically for function components.

Custom HOC to provide Store into a Class-based Components

React Context replaces the Legacy Context which was fairly awkward to use. In simple words, React Context is used to store some data in one place and use it all over the app. Previously, Mobx had Provider/inject pattern, but currently this pattern is deprecated and we must use only one way - Context. And again, it's not mandatory to use React Context with Mobx but it's recommended now officially on the mobx-react website. You can read more info about it here - Why is Store Injecting obsolete?

And I wrote HOC (High Order Component) for support Class based Components:

import React, { ComponentType } from 'react';
/**
 * https://reactjs.org/docs/higher-order-components.html#static-methods-must-be-copied-over
*/
import hoistNonReactStatics from 'hoist-non-react-statics';

import { useStores } from '../hooks/useStores';

export type TWithStoreHOC = <P extends unknown>(
    Component: ComponentType<P>,
) => (props: P) => JSX.Element;

export const withStore: TWithStoreHOC = (WrappedComponent) => (props) => {
    const ComponentWithStore = () => {
        const store = useStores();

        return <WrappedComponent {...props} store={store} />;
    };

    ComponentWithStore.defaultProps = { ...WrappedComponent.defaultProps };
    ComponentWithStore.displayName = `WithStores(${
        WrappedComponent.name || WrappedComponent.displayName
    })`;

    hoistNonReactStatics(ComponentWithStore, WrappedComponent);

    return <ComponentWithStore />;
}

And Class based Component will be:

import React, { Component } from 'react';
import { observer } from 'mobx-react';

import { withStore } from '../hocs';

class UserNameComponent extends Component {
    render() {
        const { store } = this.props;
        return (
            <div>{store.userStore.name}<div>
        )
    }
}

export default withStore(observer(UserNameComponent));

This one is an elegant way to use Stores inside Components. If you want to use decorators, the code will be:

import React, { Component } from 'react';
import { observer } from 'mobx-react';

import { withStore } from '../hocs';

@withStore
@observer
class UserNameComponent extends Component {
    render() {
        const { store } = this.props;
        return (
            <div>{store.userStore.name}<div>
        )
    }
}

export default UserNameComponent;

React Hook with Stores for Functional Components

We add a function to help us to get the stores inside the React Functional Components. Using useContext that React provides us, we pass the previously created context to it and get the value we spicified.

import { useContext } from 'react';
import { RootStore } from '../stores';
import { StoreContext } from '../contexts'

export const useStores = (): RootStore => useContext(StoreContext);

Functional Components

If you want to use functional components, you need to use only observer function from mobx-react bindings and useStores hook of our Application:

import React from 'react';
import { observer } from 'mobx-react';

import { useStores } from '../hooks';

const FunctionalContainer: FC = observer((props) => {
  const { userStore } = useStores();

  return (
      <div>Functional Component for ${userStore.name}</div>
  )
});

export default FunctionalContainer;

Services Layer

Services layer is the place of communications with Backend, 3rd API. Don't call your REST API Interfaces from within your stores. It really makes them hard to test your code. Instead of, please put these API Calls into extra classes (Services) and pass these instances to each store using the store's constructor. When you write tests, you can easily mock these API calls and pass your mock API Instance to each store.

For example, we need a class SpotifyService where we can use API and this class is Singleton. I use Singleton pattern because I want just a single instance available to all Stores.

import SpotifyWebApi from 'spotify-web-api-js';

export interface APISpotifyService {
    getAlbums(): Promise<void>;
}

class SpotifyService implements APISpotifyService {
    client: SpotifyWebApi.SpotifyWebApiJs;

    constructor() {
        this.client = new SpotifyWebApi();
    }

    async getAlbums(): Promise<void> {
        const albums = await this.client.getMySavedAlbums();

        return albums;
    }
}

/**
 * Export only one Instance of SpotifyService Class
*/
export const SpotifyServiceInstance = new SpotifyService();

And you can use in your Stores in this way:

import { action } from 'mobx';
import { SpotifyServiceInstance } from '../services';

export class UserStore implements IUserStore {
    @action getAlbums = (): void => {
        SpotifyServiceInstance.getAlbums();
    }
}

Conclusion

To sum up, this guide shows how we can connect React with Hooks and Classes with Mobx and TypeScript. I think this combination of MVC pattern with Mobx, React and TypeScript produces highly typed, straightforward and scalable code.

The source code will be available on my github & will be under the MIT License for your using when I'll publish the second part of the article series.

I hope this walkthrough was interesting and you can could find some information that helped in your projects. If you have any feedback or something else, please write to me on twitter and we will discuss any moments.

Resources

Memory size of Javascript Boolean

Nik Shevchenko — Thu, 20 Feb 2020 19:43:12 +0000

Introduction

Javascript in the browser works a level above Javascript Engine (V8, Rhino, JavaScriptCore, SpiderMonkey). These engines follow the ECMAScript Standards. ECMAScript defines the standard for the scripting language. [1]

In this post, we will use V8 Engine by Google. The V8 Engine:

The V8 Engine is written in C++ and used in Chrome & in Node.js, among others.
It implements the ECMAScript Standard as specified in ECMA-262. [1]

More specific documentation of the V8 Engine is available at docs.

The main scheme of compilation JavaScript code to Machine Code:

Each object takes a specific size in memory and C++ or ECMAScript specify on this size.

Boolean

Size: 4 bytes or 1 byte

A boolean is actually 1 byte. But alignment may cause 4 bytes to be used on a 32-bit platform or 8 bytes on a 64-bit platform. This old trick comes from the observation that allocated memory takes up at least 4 or 8 bytes, and are aligned in the way that the least significant bit or three will be zero.

In C++, the size of the type boolean is implementation-defined (expr.sizeof[p1]) and is usually equal to 1 (the size of the type char, and the smallest size a type can have), but is not required to be (expr.sizeof[fn77]): in particular, in Visual Studio up to version 4.2, it was 4. More information about C++ boolean values is available at docs[expr.sizeof(7.6.2.4)].

Resources

[1] –– https://www.ecma-international.org/publications/standards/Ecma-262.htm

[2] –– https://www.quora.com/In-C%2B%2B-what-is-the-size-of-type-bool/answer/Sergey-Zubkov-1?ch=10&share=2471829a&srid=lXWU

[3] –– https://www.freecodecamp.org/news/understanding-the-core-of-nodejs-the-powerful-chrome-v8-engine-79e7eb8af964/

[4] –– https://stackoverflow.com/questions/32733314/in-v8-how-are-primitive-types-such-as-null-undefined-and-boolean-stored-in-me

GraphQL Fragments

Nik Shevchenko — Thu, 20 Feb 2020 19:16:45 +0000

Introduction

GraphQL Fragment is a reusable part of the query. Fragments let you construct sets of fields and then include them in different queries of your application. You can think of it as functions in programming languages, that are reusable units of your code. Here's an example of how you could solve the above situation using fragments and support of DRY practice in your queries and components.

Fragment description

# Fragment
fragment name on Type {
  id
  name
}

A fragment consists of parts:

Fragment name (name)

This is the custom name of the fragment and every fragment will be with own name

Object Type (Type)

This is a type of object where you use a fragment

Body of fragment (id, name)

This defines the fields of the shared query

How to use GraphQL Fragments

Let's use the Artsy API, artists and artworks collections:

# Fragment of Artist
fragment artistInfo on Artist {
  id
  name
  bio
}

# Queries
{ 
  trending_artists(name: ARTIST_INQUIRY) {
    artists {
      ...artistInfo
    }
  }

  popular_artists {
    artists {
      ...artistInfo
    }
  }
}

The syntax of using a fragment is similar to the JavaScript spread operator. And the idea of a fragment is the same –– to assign the keys and values of one object to another object. ... give GraphQL command assigns the fields from the custom fragment to the current selection set. In our example we are able to select the name, bio, and id in two different queries using one instance of a fragment, it's cool.

Playground of this example on GraphQL Arty's.

Why do you need to use GraphQL Fragments?

Reusable part of queries

You can organize your queries into small units with reusable parts with fragments. This is the best practice for performance and components architecture of your application.

Caching

The fragments are also frequently used in frontend caching clients like ApolloClient or Relay. ApolloClient provides methods for interacting with cached data (https://www.apollographql.com/docs/react/caching/cache-interaction/).

In Relay, we have the so-called fragment container, which defines the component’s data requirements of the component.

Static typing

We can generate static types from GraphQL for TypeScript or Flow.

Resources

Official documentation from GraphQL Fragments –– https://graphql.org/learn/queries/#fragments
Interacting with cached data in Apollo –– https://www.apollographql.com/docs/react/caching/cache-interaction/
Public GraphQL APIs list –– https://github.com/APIs-guru/graphql-apis
Artsy's GraphQL API –– https://github.com/artsy/metaphysics

Forem: Nik Shevchenko

The Road to GraphQL At Enterprise Scale

Table of contents

Resilience and fault tolerance of Web Oriented Services

Table of contents

Introduction

Resilience methodologies

Identifying failure points in architecture

Load Balancing

Load Balancing Algorithms

Internal-Communication Load Balancing

External Load Balancing with HAPRoxy

Health Check

Cache

In-Memory Cache

External Cache

No cache

React, TypeScript & Mobx

Overview

Setup Application

Setup Services & Stores

Organizing Stores

Communication between stores

Context Provider to pass Store

Class and Functional Components

Custom HOC to provide Store into a Class-based Components

React Hook with Stores for Functional Components

Functional Components

Services Layer

Conclusion

Resources

Memory size of Javascript Boolean

Introduction

Boolean

Resources

GraphQL Fragments

Introduction

Fragment description

How to use GraphQL Fragments

Why do you need to use GraphQL Fragments?

Resources