DEV Community: Vsevolod Rodionov

Running next.js in cluster mode (dead simple)

Vsevolod Rodionov — Wed, 17 Aug 2022 13:06:00 +0000

Honestly, I feel like an idiot - I've been maintaining Next.js apps last few years, and thought Next.js is automatically running clustered in production.

Moreover, I did not find any nice solutions for running Next.js clusterized - everything is over-complicated with ton of code.

Well, turned out (at least for Next 12) it is really simple - and Google did not give me any nice answer, so I had to research on it by myself today.

So, here's the solution - mostly simply based on node cluster docs:

const cluster = require('node:cluster');
const process = require('node:process');
const { cpus } = require('node:os');

const numCPUs = cpus().length;

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`);
  // all the magic goes here. 
  // `setupPrimary` is altering cluster behaviour
  // see docs: https://nodejs.org/api/cluster.html#clustersetupprimarysettings
  cluster.setupPrimary({
    // node_modules/.bin is directory for all runtime scripts,
    // including `next`.
    // we can work with it like with a common node package,
    // so require.resolve simply gives us path for `next` CLI 
    exec: require.resolve('.bin/next'),
    // args should skip first 2 arguments, 
    // "node" path and file to execute path
    args: ['start', ...process.argv.slice(2)],
    // just directly passing all the IO to not handle pipes
    stdio: 'inherit',
    // making stdout and stderr colored
    shell: true,
  });

  for (let i = 0; i < numCPUs; i++) {
    cluster.fork();
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`worker ${worker.process.pid} died`, { code, signal });
  });
}

// we do not need to do "else" here as cluster will run different file

What are template strings really for?

Vsevolod Rodionov — Wed, 09 Sep 2020 20:40:46 +0000

Since template strings (aka template literals) were released I was feeling that they were kind of unappreciated.

No, of course everyone loved an ability to write like hello${world}, and tricks like this

escape`<html/>`

worked great, but for years I was sure they can do more.

I love one not-so-well-known NoSQL graph database - Neo4j, and I've been building projects with it occasionally.

It was nice, but query syntax was not so great, so I had to write like this:

s.run('MERGE (alice:Person {name : $nameParam, age : $ageParam})', {
    nameParam: 'Alice',
    ageParam: 21
})

and I was literally struggling to think out the name for each variable.

For more context: this is complex query database for research with ton of capabilities and no schema, you cannot simply create an ORM for it, so I had to write raw queries. Simple example of todo list query: "do this task has dependent tasks of infinite deep that are blocked not by other dependencies of this task?".

So, turned out template strings can actually solve this problem and make this simple as hell. I've created a lib for this - cypher-talker and now I'm writing like this, feeling myself really happy for it:

s.run(...t`MERGE (alice:Person {name : ${'Alice'}, age : ${21})`)

I'm planning to simplify it more and write a monkey-patch to write like this:

s.run`MERGE (alice:Person {name : ${'Alice'}, age : ${21})`

but it requires some other driver extensions - like transactions Realms wrapper, but I'll write on it when I'm done with it.

So, what is the trick?

Template strings are expected to be a pure functions. This is important: you are generally not intended to alter something in it. You can, but generally even ESLint will stop you - no-unused-expressions rule prevents you from doing it by default.

Template literal (yes, that's how function to use with template strings called) should have a following signature:

(literals: TemplateStringsArray, ...placeholders: string[]): any

What is cool: typescript fully understands signature of template function, so it will detect an error here:

const t = (literals: TemplateStringsArray, ...placeholders: string[]) => null

t`hello${'world'}${2}`

// and even here!

const t = (literals: TemplateStringsArray, ...placeholders: [string, number, ...string[]]) => null

t`hello${'world'}${true}`

With typescript 4 and its advanced tuples it now works amazing!

If you're curious, what TemplateStringsArray is - it is simply ReadonlyArray<string>, nothing special.

Note that literals size is always 1 time bigger than placeholders length. It will always has a string - even empty, so its reduction may be a bit complicated.

Second magic is that it can return anything

For my lib I needed to produce something spreadable - I mean, iterable. You can return anything: object, array, WeakRef or function. It will simply work.

I know, this looks obvious, but when you really understand what that does mean - you will see a world of possibilities.

Imagine NestJS, but with template string decorators

@Get`docs`
@Redirect`https://docs.nestjs.com`(302)
getDocs(@Query`version` version) {
  if (version && version === '5') {
    return { url: 'https://docs.nestjs.com/v5/' };
  }
}

I think, it looks amazing. Simply remove brackets - and now it looks really declarative. It starts to look not like bunch of function calls all around, but like a some kind of DSL, really.

If you forget how it looks like right now:

@Get('docs')
@Redirect('https://docs.nestjs.com', 302)
getDocs(@Query('version') version) {
  if (version && version === '5') {
    return { url: 'https://docs.nestjs.com/v5/' };
  }
}

Or imagine tests, but with decorator fns

it`tests error with async/await and rejects`(async () => {
  expect.assertions(1);
  await expect(user.getUserName(3)).rejects.toEqual({
    error: 'User with 3 not found.',
  });
});

Looks simple, but what if we will drop some parametrized testing in it?

[2, 3, 5, 7].forEach((value) => {
  it(`should return true for prime number ${value}`, 
() => {
    expect(isPrime(value)).toEqual(true);
  });
});

//vs

it(`should return true for prime number ${[2, 3, 5, 7]}`, 
(value: number) => {
  expect(isPrime(value)).toEqual(true);
});

note: yes, I know that DoneCallback usually should be there, but I'm speaking on general concept, not specific framework

If you think it is not possible with types: it works on nightly TS 4.1. There is issues right now with recursive conditional types in latest TS, but they are fixing it. TS playground

// a bit of functional magic
type car<T> = T extends [infer R, ...any[]] ? R : never
type cdr<T> = T extends [any, ...infer R] ? R : []

type pickType<T> = T extends Array<infer R> ? R : never

type pickFirst<T extends [...unknown[][]]> = T extends [] 
    ? [] 
    : [pickType<car<T>>, ...pickFirst<cdr<T>>]

const it = <T extends [...unknown[][]]>(
    literals: TemplateStringsArray, ...placeholders: T
) => {
    return (fn: (...args: pickFirst<T>) => void) => {

    }
}

it`hello${['world']} ${[true, 5]}`(
(v: string, g: number | boolean) => {
 // test it!
})

Conclusion

I really think that template strings are damn unappreciated. They can bring you DSL you want - and keep the glory of types.

Try to love them more!

I decided to create my own Node.js router/http-server, performance and devops-aimed. What should I consider?

Vsevolod Rodionov — Sun, 26 Apr 2020 16:16:26 +0000

I decided to create yet another "express-killer" (work already in progress) pet project.
Of course, not NIH syndrome: I'm going to make it Express middleware-compatible.
Target is to make it fast as hell in its core and modern tooling integration-aimed without losing friendliness and already known experience.
What should I consider?

What I already keep in mind:

blazing-fast generic router package, which can be mounted over both Koa and Express. Better than common trie solutions - I've inspected popular ones and I know parts of code that can be done in a more efficient way by adding the "compile" step. I'm also going to try WASM router implementation, but unsure whether interop will degrade the performance. Routes will be path-to-regexp-compatible (like Express), with the ability to define regex paths with the lowest priority order.
separation of endpoints and middlewares, while keeping in mind that endpoints can end the request (like "if not authorized, redirect to home"), and integration with documentation extractors like Swagger (or any other generic solution).
simple integration possibility with modern APMs like New Relic, Prometheus, and other popular ones. Not full integration at the first step, but the ability to extract nice metrics (like per-path) in the core.
built-in forever or other Cluster and auto-reload package; also, support of sticky-session
СSP declarative configuration and tracing ID out-of-the-box (middleware call-style, but working differently inside)
profiling-friendly - middlewares will be not in a stack, instead, they will have a flat call structure and this will allow a profiler to show separate calls instead of call stacks.
some kind of Dependency Injection solution - still thinking on it, not a lot of ideas, however.
Node 14-tuned - if something is improving performance on 14, but breaks or degrades 10 or 12, this is good. Not expecting to release before 14 go to LTS.

Just to clear things out - I'm team-/tech-lead/architect working on frontends and backends-for-frontends in large scale projects (~10k pages per second served on a current one) with 8+ years of experience, this is not a newbie post - I'm really struggling to hear pains in modern solutions.

State vs knowledge: you should make your apps a bit more complex to keep them simple

Vsevolod Rodionov — Tue, 17 Mar 2020 15:49:11 +0000

Generally, every client web app - SPA, PWA, whatever - real soul is state.

We may brag on React, Vue or Svelte, we may shamefully (or proudly) continue to use jQuery, but what really defines the way we think, the way we tighten up with back-end, APIs and storage? State and the way you manage it.

And ton of people are struggling from state manager fatigue. Redux? Yes, yes and yes. RxJS? Sure. MobX? Why would it have pitfalls.html page in docs if it simple?

I think there is a solution, but first we have to fully draw the problem.

When choosing the state manager, you are choosing the way you think. There is a lot of choices nowadays. Most popular are:

Flux/Redux-style state, a global store with actions & reducers - well, tons of them. I would personally note Redux itself, Effector, Storeon, Unstated, and Reatom. This is not "best of" list. It is about different ways on how it can look like. Also, each of them has something very unique (from my point of view), so all of them are worth giving a glance - just to check out various concepts, not to use in production!

This approach can be defined as imperative/Turing-complete & global.

Observables & pipes. Most well-known ones are RxJS and MobX. Less known - Kefir, Bacon, CycleJS. Svelte goes here too. They differ a lot, but it comes from one core difference - RxJS allows "strange loops", when you can pipe observables through observables, and MobX just creates "reactive" boxes over the variables and computations.

It may sound weird, but they are aiming to be local/ad-hoc & declarative, yet still Turing-complete (I will write an article about that one day). They allow you to describe how data will be transformed, not what exactly to do with it. On some level of, um, enlightment, RxJS developers starts to avoid writing functions as much as possible, preferring to use libraries like Lodash, or Ramda, or io-ts, and their code actually starts tasting LISPy and looking like JSON or YAML, not real code.

Speaking on local, I mean that you may have component-level observable, or application-level, or you can pass observable as an argument - you can do whatever you want with any of data sources.

GraphQL-alike. Apollo and Relay are best of examples, but you can find ton of them. Special mentions goes to Falcor (Netflix alternative to GraphQL query language), GunDB and PouchDB. Moreover, there are implementations & integrations with Redux, MobX, RxJS - any of them. But actual store does not matter; what really matters is the way to state the expectations. It is 100% declarative - in comparison to Flux-way imperative data reducement. And it is global.

So we have 2 dimensions of state management. One is local/global, second - declaration/imperative orders. And that makes us to ask the questions.

	imperative	declatative
GLOBAL	Flux	GraphQL
LOCAL	Observables	?????

I should probably make a note here. Terms "global" and "local" may be a bit confusing here, as long as you can place Rx observable as a global variable, and you can dynamically load redux stores.

Rule of thumb here is: if something is forced to have globally unique ID getter as intended behavior - it is global. No matter how ID is used - it can bewindow[key], or require('stores/' + key), or dynamicModuleLocator.get(key).

If something is intended to emerge within some other entity lifecycle - say, React or Angular component, or API queue manager, or whatever else - it is local, despite the fact you can assign it to window[key]. Otherwise you would have to consider everything possibly global.

The missing link

This may seem weird.

I cannot recall any local & declarative state manager. With chances, you will name some esoteric or experimental state managers, but nothing from "state of js" list & nothing I was able to find.

And, probably, the answer is the following:

We are blending two different entities into one.

We have state, which is runtime-level, and we do not care on whether it is local or global; but what we do know is that it is best manipulated in imperative manner.

And we have knowledge about what is happening. We can affect this knowledge, but we can always predict the consequences of our affection; so, we can declare that we want to know something about our system state.

When we are using single store for both state and knowledge, we're doing something fundamentally wrong.

Models

We've been thinking for the whole time that anything we were manipulating were just models. Model of checkbox, model of blog post, of SQL record, or relation graph; however, we were struggling a ton of times when we were curious on how to handle and marry our local state and remote state knowledge.

But it is a way of thinking we brought from our experience of building the APIs.

However, when you start to ask people how they make various complex applications with internal state on server, you will get the answer: they differ state and API responses.

Usually, they use the following combination:

knowledge layer: automatically caching wrappers around API calls with some invalidation logic. What is tricky here is that it is usually hidden.
explicit state layer: sometimes it is finite state machine or statechart, sometimes it is some class with data. Sometimes - observables (RxJava, RxRuby, RxSwift, RxWhatever - you got the point) with logic encoded in its topology. Sometimes - some in-house or even ad-hoc solution, maybe even blended with other application parts.

The solution

I think it is the time to separate state and knowledge. This is even more vital for modern web apps than logic and view separation. We need to keep in mind that some variables we use are ones that came from external system (back-end or 3rd party), and we must keep in mind they were provided to us. And some - are fully ours and we can manipulate them as we wish.

We should clearly understand, that some of our strings, arrays and objects are coming from state, and some - from knowledge on system. Knowledge is something global, something that describes the whole system - or parts of it that are available for us. Every single piece of knowledge should be labeled: you should know where this entity came from, and when it should be invalidated. GraphQL is nice solution for it, but you can choose or build your own. Every piece of knowledge should be transferable. Consider them as DTOs. Knowledge cannot have JS functions, or bindings to your local system - but if you need Turing-complete logic, you can transfer some Lisp-flavored object. I once had that experience, and keeping something like {extractor: ["$fn", ["useMax"], ["return", ["ifelse", "useMax", "getMaxViewport", "getMinViewport"]]]} felt weird, but it worked.

State is how you represent current application state. It is OK if it is local - but keep in mind you will probably have to bind different parts of system together. Most important things here are that you can keep functions there, and that when you grab some data from knowledge - e.g. you are editing blog post you already wrote - you should either copy the data, not re-use the object, or keep the diff, which is even better. Why it is better? Simple example: you have something like JIRA - with tons of fields to edit. You update one, and simultaneously someone else is altering another. If you will send the whole state to the server, you will overwrite another guy's work. If you only send your diff, you will not. Advanced version of that is called CRDT.

So, once again:

You are working with two worlds in your application.

One, the knowledge is a reflection of something remote. You cannot download the whole DB to your browser, so you only get the parts of it. You can use imperative getBlogPost(id) or declarative @gql("blogPosts(id){...}") class extends Component. Both are fine, but when using declarative approach, you are hiding the ability to create complex logic you actually do not need.

You should preserve data immutable. You can use ImmutableJS, Object.freeze, use TypeScript's readonly or just keep an eye on that. If you do that, you can even do the trick and start keeping your knowledge in Shared Worker or Service Worker.

Second, the state is your own kingdom. I personally advice to use XState to represent any complex piece of logic (anything bigger than the counter). But you can use anything you want. Just keep it away from knowledge.

Any interaction between this two worlds should me kept in userland and should be loud and clear.

I'm not limiting you on some specific libraries, it is all on architecture and way of thinking. I suddenly understood few weeks ago that I was using this approach unknowingly and like a hidden pattern, but it is the thing that should be as explicit as possible.

Give this idea a try, and you will see how your mind will slowly become lest restless.