Hello! This is another article about next.js. And finally, about the new version! Each release is a set of new, interesting, and controversial features. This version will be no exception. However, new version is interesting not so much for its new functionality, but for the change in priorities and organization in next.js. And yes, as you may have guessed from the title, a significant part of this release is valuable for reflecting on previous mistakes.

I’ve been working with next.js since around version 8. All this time I’ve been watching its development with interest (sometimes not without disappointment). Recently, I’ve published a series of articles about struggling with the new App Router — “Next.js App Router. A path to the future or a wrong turn”, “Next.js caching. A gift or a curse”, “More libraries for the god of libraries or how I rethought i18n”. All of these were a result of very weak development of ideas and capabilities in previous versions of next.js. And because of this, my interest in the new version has only grown. Along with that, there’s a desire to understand the vector of changes in the framework.

In this article, I won’t dwell on what App Router or server components are — these are described in detail in previous articles. We’ll focus only on the new version and only on the new changes.

Note: The article reflects the most interesting changes from the author’s perspective. They differ from the official list, as the author selected them from commits and PRs in the framework.

Next.js v15 Release

First, a bit about changes in the internal development processes of next.js. For the first time, the framework team has published a release candidate (RC version). Obviously, they did this due to the React.js team’s decision to publish React v19 RC.

Usually, the next.js team in their stable releases calmly uses react from the “Canary” release branch (this branch is considered stable and recommended for use by frameworks). This time, however, they decided to do things differently (spoiler alert — not in vain).

The plan for both teams was simple — publish a pre-release version, let the community check for issues, and in a couple of weeks publish a full release.

It’s been over six months since the release candidate of React.js was released, but the stable version still hasn’t been published. The delay in releasing the stable version of React.js has impacted next.js’s plans as well. Therefore, contrary to tradition, they published a total of 15 additional patch versions while already working on the 15th version (usually 3–5 patches and then a release). What’s noteworthy here is that these patch versions didn’t include all accumulated changes, but only addressed critical issues, which also deviates from next.js’s usual processes.

The basic release process in next.js is that everything merges into the canary branch, and then, at some point, this branch is published as a stable release.

However, as a result, the next.js team decided to decouple from the React.js release and publish a stable version of the framework before the stable version of React.js is released.

Documentation Versioning

Another very useful organizational change. Finally, it’s possible to view different versions of the documentation. Here’s why this is so important:

Firstly, updating next.js can often be quite a challenging task due to major changes. In fact, this is why there are still over 2 million downloads for version 12 and over 4 million for version 13 monthly (to be fair, version 14 has over 20 million downloads).

Consequently, users of previous versions need documentation specific to their version, as the new one might be rewritten for a half.

Another problem is that Next.js essentially uses a single channel. Documentation changes are also made to it. Therefore, descriptions of changes from canary versions immediately appeared in the main documentation. Now they are displayed under the “canary” section.

React usage

At the beginning, I mentioned that Next.js is currently using the RC version of React.js. But in reality, this is not quite true, or rather not entirely true. In fact, Next.js is currently using two React.js configurations: the 19th canary version for App Router and the 18th version for Pages Router.

Interestingly, at one moment they wanted to include the 19th version for Pages Router as well, but then rolled back these changes. Now, full support for React.js version 19 is promised after the release of its stable version.

Along with this, the new version will have several useful improvements for server actions functions (yes, the React team renamed them):

• Optimization of weight and performance;
• Improved error handling;
• Fixed revalidation and redirects from server functions.

I suppose I’ll include Next.js’s new feature in this section as well — the Form component. Overall, it’s the familiar form from react-dom, but with some improvements. This component is primarily needed if successful form submission involves navigating to another page. For the next page, the loading.tsx and layout.tsx abstractions will be pre-loaded.

import Form from 'next/form'
 
export default function Page() {
  return (
    <Form action="/search">;
      {/* On submission, the input value will be appended to 
          the URL, e.g. /search?query=abc */}
      <input name="query" />;
      <button type="submit">Submit</button>;
    </Form>;
  )
}

Developer Experience (DX)

When talking about Next.js, we can’t ignore the developer experience. In addition to the standard “Faster, Higher, Stronger” (which we’ll also discuss, but a bit later), several useful improvements have been released.

Long-awaited support for the latest ESLint. Next.js didn’t support ESLint v9 until now. This is despite the fact that both eslint itself (v8) and some of its subdependencies are already marked as deprecated. This resulted in an unpleasant situation where projects were essentially forced to keep deprecated packages.

The error interface has been slightly improved (which in Next.js is already clear and convenient):

• Added a button to copy the stack trace;
• Added the ability to open the error source in the editor at a specific line.

A “Static Indicator” has been added — an element in the corner of the page showing that the page has been built in static mode. Overall, it’s a minor thing, but it’s amusing that they included it in the key changes as something new. The indicator for a “pre-built” page has been around since roughly version 8 (2019) and here, essentially, they’ve just slightly updated it and adapted it for the App Router.

A directory with debugging information has also been added — .next/diagnostics. It will contain information about the build process and all errors that occur. It's not yet clear if this will be useful in daily use, but it will certainly be used when troubleshooting issues with Vercel devrels (yes, they sometimes help to solve problems).

Changes in the Build Process

After discussing DX, it’s worth talking about the build process. And along with it, Turbopack.

Turbopack

And the biggest news in this area. Turbopack is now fully completed for development mode! “100% of existing tests passed without errors with Turbopack”

Now the Turbo team is working on the production version, gradually going through the tests and refining them (currently about 96% complete)

Turbopack also adds new capabilities:

• Setting a memory limit for builds with Turbopack;
• Tree Shaking (removal of unused code).

const nextConfig = {
  experimental: {
    turbo: {
      treeShaking: true,
      memoryLimit: 1024 * 1024 * 512 // in bytes / 512MB
    },
  },
}

These and other improvements in Turbopack “reduced memory usage by 25–30%” and also “accelerated the build of heavy pages by 30–50%”.

Other

Significant style issues have been fixed. In version 14, situations often arose where the order of styles was broken during navigation, causing style A to become higher than style B, than vice versa. This changed their priority and consequently, elements looked different.

The next long-awaited improvement. Now the configuration file can be written in TypeScript — next.config.ts

import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* config options here */
};
 
export default nextConfig;

Another interesting update is retrying attempts for static page builds. This means if a page fails at build time (for example, due to internet problems) — it will try to build again.

const nextConfig = {
  experimental: {
    staticGenerationRetryCount: 3,
  },
}

And to conclude this section, a functionality highly desired by the community — the ability to specify the path to additional files for building. With this option, you can, for example, specify that files are located not in the app directory, but in directories like modules/main, modules/invoices.

However, at the moment, they have only added it for internal team purposes. And in this version, they definitely won’t present it. Going forward, it will either be used for Vercel needs, or they will test it and present it in the next release.

Changes in the Framework API

The most painful part of Next.js updates — API changes. And in this version, there are also breaking updates.

Several internal framework APIs have become asynchronous — cookies, headers, params and searchParams (so-called Dynamic APIs).

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
  // ...
}

It’s a major change, but the Next.js team promises that all this functionality can be updated automatically by calling their codemod:

npx @next/codemod@canary next-async-request-api .

Another change, but probably not relevant to many. The keys geo and ip have been removed from NextRequest (used in middleware and API routes). Essentially, this functionality only worked in Vercel, while in other places developers made their own methods. For Vercel, this functionality will be moved to the @vercel/functions package

And a few more updates:

• In revalidateTag, you can now pass multiple tags at once;
• Keys images.remotePatterns.search and images.localPatterns have been added to the configuration for next/image. These allow better control over address restrictions for image compression.

const nextConfig = {
  images: {
    localPatterns: [
      {
        pathname: '/assets/images/**',
        search: 'v=1',
      },
    ],
  },
}

Caching

In my personal opinion, this is where the most important changes for Next.js have occurred. And the biggest news is — Caching is now disabled by default! I won’t go into detail about caching problems, this was largely covered in the article “Next.js Caching. Gift or Curse”.

Let’s go through all the main changes in caching:

• Specifically, fetch now uses the no-store value by default instead of force-cache;
• API routes now work in force-dynamic mode by default (previously the default was force-static, meaning they were compiled into a static response during build time [if dynamic APIs were not used on the page]);
• Caching in the client router has also been disabled. Previously, if a client visited a page within a route — it was cached on the client and remained in that state until the page was reloaded. Now, the current page will be loaded each time. This functionality can be reconfigured through next.config.js:

const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30 // defaults to 0
    },
  },
}

• Moreover, even if client-side caching is enabled — it will apparently be updated at the right moment. Specifically, if the cache of an enabled page on the server expires.
• Server components are now cached in development mode. This makes updates in development happen faster. The cache can be cleared simply by reloading the page. You can also completely disable this functionality through next.config.js:

const nextConfig = {
  experimental: {
    serverComponentsHmrCache: false, // defaults to true
  },
}

• You can now manage the “Cache-Control” header. Previously, it was always rigidly overwritten with Next.js’s internal values. This caused artifacts with caching through CDN;
• next/dynamic caches modules and reuses them, rather than loading them again each time;

That’s regarding the “historical misunderstandings”. New APIs will also appear in Next.js. Namely, the so-called Dynamic I/O. It hasn't been written about anywhere yet, so the following will be the author's guesses based on the changes.

Dynamic I/O appears to be an advanced mode of dynamic building. Something like PPR (Partial Prerendering), or more precisely, its complement. In short, Partial Prerendering is a page building mode where most elements are built at build time and cached, while individual elements are built for each request.

So, dynamic I/O [probably] finalizes the architecture for this logic. It expands caching capabilities so that it can be enabled and disabled precisely depending on the mode and place of use (whether in a "dynamic" block or not).

const nextConfig = {
  experimental: {
    dynamicIO: true, // defaults to false
  },
}

Along with this, the "use cache" directive is added. It will be available in nodejs and edge runtimes and, apparently, in all server segments and abstractions. By specifying this directive at the top of a function or a module exporting a function - its result will be cached. The directive will only be available when dynamicIO is enabled.

async function loadAndFormatData(page) {
  "use cache"
  ...
}

Also, specifically for use cache, methods cacheLife and cacheTag are added

export { unstable_cacheLife } from 'next/cache'
export { unstable_cacheTag } from 'next/cache'

async function loadAndFormatData(page) {
  "use cache"
  unstable_cacheLife('frequent');
  // or
  unstable_cacheTag(page, 'pages');
  ...
}

cacheTag will be used for revalidation using revalidateTag, and cacheLife will set the cache lifetime. For the cacheLife value, you'll need to use one of the preset values. Several options will be available out of the box ("seconds", "minutes", "hours", "days", "weeks", "max"), additional ones can be specified in next.config.js:

const nextConfig = {
  experimental: {
    cacheLife?: {
      [profile: string]: {
        // How long the client can cache a value without checking with the server.
        stale?: number
        // How frequently you want the cache to refresh on the server.
        // Stale values may be served while revalidating.
        revalidate?: number
        // In the worst case scenario, where you haven't had traffic in a while,
        // how stale can a value be until you prefer deopting to dynamic.
        // Must be longer than revalidate.
        expire?: number
      }
    }
  }
}

Partial Prerendering (PPR)

Probably the main feature of the next release. As mentioned earlier, PPR is a page building mode where most elements are assembled at build time and cached, while individual elements are assembled for each request. At the same time, the pre-built part is immediately sent to the client, while the rest is loaded dynamically.

The functionality itself was introduced six months ago in the release candidate as an experimental API. This API will remain in this state, and we will likely see it as stable only in version 16 (which is good, as major functionality often transitioned to stable within six months to a year).

Regarding the changes. As mentioned earlier, it primarily updated the working principles. However, from the perspective of using PPR, this hardly affected anything. At the same time, it received several improvements:

Previously, there was just a flag in the config, but now to enable PPR, you need to specify ‘incremental’. This is apparently done to make the logic more transparent — content can be cached by developers even in PPR, and to update it, you need to call revalidate methods.

const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
}

Also, previously PPR was launched for the entire project, but now it needs to be enabled for each segment (layout or page):

export const experimental_ppr = true

Another change is Partial Fallback Prerendering (PFPR). It’s precisely due to this improvement that the pre-built part is immediately sent to the client, while the rest is loaded dynamically. In place of dynamic elements, a callback component is shown during this time.

import { Suspense } from "react"
import { StaticComponent, DynamicComponent } from "@/app/ui"
 
export const experimental_ppr = true
 
export default function Page() {
  return {
    <>
      <StaticComponent />
      <Suspense fallback={...}>
        <DynamicComponent />
      </Suspense>
    </>
  };
}

Instrumentation

Instrumentation is marked as a stable API. The instrumentation file allows users to hook into the lifecycle of the Next.js server. It works across the entire application (including all segments of Pages Router and App Router).

Currently, instrumentation supports the following hooks:

register - called once when initializing the Next.js server. It can be used for integration with observability libraries (OpenTelemetry, datadog) or for project-specific tasks.

onRequestError - a new hook that is called for all server errors. It can be used for integrations with error tracking libraries (Sentry).

export async function onRequestError(err, request, context) {
  await fetch('https://...', {
    method: 'POST',
    body: JSON.stringify({ message: err.message, request, context }),
    headers: { 'Content-Type': 'application/json' },
  });
}
 
export async function register() {
  // init your favorite observability provider SDK
}

Interceptor

Interceptor, also known as route-level middleware. It’s something like a full-fledged [already existing] middleware, but unlike the latter:

• It can work in the Node.js runtime;
• It works on the server (which means it has access to the environment and unified cache);
• It can be added multiple times and is inherited in nesting (similar to how middleware worked when it was in beta version);
• It also works for server functions.

Moreover, when creating an interceptor file, all pages below in the tree become dynamic.

import { auth } from '@/auth';
import { redirect } from 'next/navigation';

const signInPathname = '/dashboard/sign-in';

export default async function intercept(request: NextRequest): Promise<void> {
  // This will also seed React's cache, so that the session is already
  // available when the `auth` function is called in server components.
  const session = await auth();
  if (!session && request.nextUrl.pathname !== signInPathname) {
    redirect(signInPathname);
  }
}

// lib/auth.ts
import { cache } from 'react';
export const auth = cache(async () => {
  // read session cookie from `cookies()`
  // use session cookie to read user from database
})

Speaking of Vercel, middleware will now be effective as a primary simple check at the CDN level (thus, for example, immediately returning redirects if the request is not allowed), while interceptors will work on the server, performing full-fledged checks and complex operations.

In self-hosting, however, such a division will apparently be less effective (since both abstractions work on the server). It may be sufficient to use only interceptors.

Conclusions

Overwriting fetch, aggressive caching, numerous bugs, and ignoring community requests. The Next.js team made erroneous decisions, rushed releases, and held onto their views despite community feedback. It took almost a year to recognize the problems. And only now, finally, there’s a sense that the framework is once again addressing community issues.

On the other hand, there are other frameworks. A year ago, at the React.js presentation, it seemed that all frameworks would soon be on par with Next.js. React started mentioning Next.js less frequently as the main tool, frameworks were showcasing upcoming build systems, support for server components and functions, and a series of global changes and integrations. Time has passed, and essentially, none of them have reached that point yet.

Of course, final conclusions can only be drawn after some time, but for now, it feels like the changes in React.js, instead of the expected leveling of frameworks, have led to even greater dominance of Next.js and a wider divergence between frameworks (since the implementation of server components and actions was left to the discretion of the frameworks).

At the same time, OpenAI switched to Remix (“due to its greater stability and convenience”):

And apparently they started before significant changes in Next.js

In general, in the next stateofjs and stackoverflow surveys, we are likely to see significant reshuffling.

Credits

Code examples or their foundations are taken from next.js documentation, as well as from commits, PRs, and the next.js core;

Postscript

If you need a tool for generating documentation based on MD files — take a look at robindoc.com, if you work with next.js — you might find something useful in the solutions at nimpl.tech.

Edge runtime. One of the main functionality of Vercel — the company that developed and maintains next.js. However, its influence on the edge runtime has gone far beyond its frameworks and utilities. The edge runtime works in the recently acquired by Vercel Svelte, in nuxt, and in more than 30 other frontend frameworks. This article will focus on the edge runtime — what it is, how it is used in Vercel, what features it adds to next.js, expected changes and what solutions I made to expand these features.

Vercel Edge Network

Simply put, the edge runtime is a content delivery network (CDN/distributed infrastructure), i.e., multiple points around the world. Thus, the user interacts not with a single server (which may be located in the company’s office on the other side of the world), but with the nearest network point.

At the same time, these are not copies of the application, but separate functionalities that can work between the client and the server. In other words, these are mini-servers with their own features (which will be described later).

This system allows users to access not your far server right away, but a nearby point. Decisions on A/B tests are made at this point, authorization checks are performed, requests are cached, errors are returned, and much more. After this, if necessary, the request will go to the server for the required information. Otherwise, the user receives an error or, for example, a redirect in the shortest time.

Of course, this concept itself is not Vercel’s achievement. CloudFlare, Google Cloud CDN, and many other solutions can do this as well. However, Vercel, with its influence on frameworks, has taken this to a new level, deploying not just an intermediate router at the CDN level but creating mini-applications capable of even rendering pages at the nearest point to the user. And most importantly, this can be done simply by adding familiar JS files to the project.

Edge runtime in next.js

In next.js, perhaps the main functionality of this environment is the middleware file. Any segment (API or page) can also be executed in the edge runtime. But before describing them, a little bit about the next.js server.

Next.js is a full-stack framework. That is, it contains both the client application and the server. When running next.js (next start) - it is the server that starts and is responsible for serving pages, working with the API, caching, rewrites, etc.

It all works in the following order:

1. headers from next.config.js;
2. redirects from next.config.js;
3. Middleware;
4. beforeFiles rewrites from next.config.js;
5. Files and static segments (public/, _next/static/, pages/, app/, etc.);
6. afterFiles rewrites from next.config.js;
7. Dynamic segments (/blog/[slug]);
8. fallback rewrites from next.config.js.

When it is determined that the current request reaches is the segment (not, for example, a redirect), its processing begins (this is either the return of a statically assembled segment, reading from the cache, or its execution and return of the result).

In Vercel, likely, this entire cycle can run in the edge runtime. However, points 3, 5, and 7 are particularly interesting here.

The middleware in its basic implementation looks like this:

import { NextResponse, type NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url));
}

In it, for example, you can:

• Make requests (e.g., to get data from third-party services);
• Perform a rewrite or redirect (e.g., to run an A/B test or check authorization);
• Return some body (e.g., to display a basic stub in certain situations);
• Read and/or modify headers and cookies (e.g., save or read access information).

You can read more about the areas of application in the next.js middleware documentation.

The same can be done in segments (i.e., API and pages). To make a segment work in the edge runtime, you need to export from the segment file:

export const runtime = 'edge';

Thus, the segment will be executed in the edge runtime, not on the server itself.

However, it is important to make an important caveat here. Everything described above is not a full-fledged edge runtime by itself. In Edge Network, this will be distributed only when the service is deployed in Vercel.

Also, in addition to all these capabilities, the edge runtime has several limitations. For example, despite the fact that when running the application outside of Vercel, the edge runtime is part of the server — it will not be possible to interact with this server. And this is done because it was developed specifically for the Vercel Edge Network.

Edge runtime concept in Vercel

As mentioned, the edge runtime can be called mini-applications. They are mini because they run on node.js V8 (which runs, for example, Google Chrome and Electron). This is their key detail, on which not only the features of the previous section depend but also the restrictions.

Namely, in the edge runtime, you cannot:

• Perform actions with the file system;
• Interact with the server environment;
• Call require. Only ES modules can be used. This imposes additional restrictions on third-party solutions.

The full list of supported APIs and restrictions can be found on the next.js documentation page.

Thus, Vercel Edge Network can be responsible for, for example:

• Routing;
• Page rendering;
• Executing API routes;
• Caching.

The edge runtime acts as the first stage of segment processing and is most effective in situations where all processing can take place inside the edge container. For example, for redirects or returning cached data. The entire processing process in Vercel usually works in the following order:

After the build, Vercel sends the new edge runtime code (which now compiles to machine code) to the servers, and they immediately start working with the new code.

Vercel itself uses the edge runtime for all applications and all requests. That is, after connecting the domain, Vercel immediately configures that this domain is also available on these points around the world. The next time a user visits the page, the provider will ask the network where this domain is located, and in response, it will get available locations, choose the nearest point, and go to it.

These Edge points always have caching logic, and if there are rewrites, redirects, middleware, or segments in the edge runtime in the project — after the build, it will send all of this to the edge servers.

Then the edge runtime will process it: check rewrites and redirects -> pass through middleware -> check if it is cached -> if the segment is in the edge runtime — execute it there, if not — send the request to the original server (but Vercel does not document these orders and internals of the Edge runtime anywhere, but this is how I see it).

In summary, it is beneficial to use the Edge runtime when all processing can be done within the Edge environment (The request will be Client -> Edge). If you need to access the main server (for example, a database connected within the project, or to read files for some reason) — it is not advantageous. The request will still be Client -> Edge -> Server. And since you still need to access the server — it is better to do all the processing there — it has all the cache, the database is nearby, the whole system is nearby, and overall, it has more capabilities.

Expected changes in the edge runtime

Despite the fact that the edge runtime is one of the key features of Vercel as a hosting, the team is actively revising it. Not only its application but also its necessity as a whole. Recently, Vercel VP Lee Robinson in his tweet shared that Vercel [as a company] stopped using the edge runtime in all its services and returned to the nodejs runtime. The team also expects that the experimental partial pre-render (PPR) will be so effective that edge runtime generation will lose its value.

And it was PPR along with advanced caching that pushed the edge runtime into the background. Previously, the entire page was rendered either on the server or in the edge runtime. The edge runtime won precisely because of its closer location. Now, pages are mostly pre-generated. Then, upon request, individual dynamic parts are rendered and cached. The cache, in turn, is unique for each point in the edge runtime, whereas on the server it is the same for all users.

And, of course, the server has access to the environment, database, and file system. Therefore, if the page needs this data, the nodejs runtime wins significantly (gathering everything in one environment is faster than making requests to the server from the edge environment each time).

Vercel is likely to introduce new priorities in its pricing, restructuring them around partial pre-render. Perhaps with these changes, tweets with bills of tens of thousands of dollars will become fewer (but this is not certain).

In addition, the Next.js team recently shared a tweet about middleware revision. It is very likely that, like the segments, it will be given an execution environment choice. Again, considering that outside Vercel middleware works as part of the server, this is a very logical decision. It is also possible that with these changes, a separate middleware for API routes will be added.

Expanding the Edge runtime

I am the author of several packages for next.js nimpl.tech. I have already mentioned getters with information about the current page in the article “Next.js App Router. Experience of use. Path to the future or a wrong turn”, translation library in “More libraries to the god of libraries or how I rethought i18n [next.js v14]”, caching packages in “Caching in next.js. Gift or curse”. But in this family, there are also packages specifically built for the edge runtime — router and middleware-chain.

@nimpl/router

As mentioned, the edge runtime works best if it can handle the entire request in a self-contained mini-application. In all other cases, this is an unnecessary step since the request will still go to the server but via a longer path.

One of these tasks is routing. Routing also includes rewrites, redirects, basePath, and i18n from next.config.js.

Their main problem is that they are set only once — in the configuration file — for the entire application, and also, i18n is full of bugs. Therefore, including in the App Router, there is no information about the i18n option, and the documentation recommends using middleware for this case. But such a separation means that redirects from the config and i18n routing from middleware are processed separately. This can cause double redirects (first a redirect from the config will be performed, then a redirect from the middleware) and various unexpected artifacts can appear.

To avoid this, all this functionality should be gathered in one place. And, as the documentation recommends for i18n, this place should be middleware.

import { createMiddleware } from '@nimpl/router';

export const middleware = createMiddleware({
    redirects: [
        {
            source: '/old',
            destination: '/',
            permanent: false,
        },
    ],
    rewrites: [
        {
            source: '/home',
            destination: '/',
            locale: false,
        },
    ],
    basePath: '/doc',
    i18n: {
        defaultLocale: 'en',
        locales: ['en', 'de'],
    },
});

Familiar Next.js redirects, rewrites, basePath, and i18n settings but at the edge runtime level. Documentation for the @nimpl/router package.

@nimpl/middleware-chain

Working with ready-made solutions or creating my own, time and time again I encountered the problem of combining them in one middleware. That is when you need to connect two or more ready-made middleware to one project.

The problem is that middleware in next.js is not the same as in express or koa — it immediately returns the final result. Therefore, each package just creates the final middleware. For example, in next-intl, it looks like this:

import createMiddleware from 'next-intl/middleware';

export default createMiddleware({
  locales: ['en', 'de'],
  defaultLocale: 'en',
});

I am not the first to encounter this problem, and ready-made solutions can be found on npm. They all work through their own APIs — made in the style of express or in their own vision. They are useful, well-implemented, and convenient. But only in cases where you can update each used middleware.

However, there are many situations where you need to add already existing solutions. Usually, in the issues of these solutions, you can find “add support for adding package chain A”, “work with package chain B”. It is for such situations that @nimpl/middleware-chain is created.

This package allows you to create a chain of native next.js middleware without any modifications (that is, you can add any ready-made middleware to the chain).

import { default as authMiddleware } from "next-auth/middleware";
import createMiddleware from "next-intl/middleware";
import { chain } from "@nimpl/middleware-chain";

const intlMiddleware = createMiddleware({
    locales: ["en", "dk"],
    defaultLocale: "en",
});

export default chain([
    intlMiddleware,
    authMiddleware,
]);

The chain processes each middleware sequentially. During processing, all modifications are collected until the chain is completed or until any element in the chain returns FinalNextResponse.

export default chain([
    intlMiddleware,
    (req) => {
        if (req.summary.type === "redirect") return FinalNextResponse.next();
    },
    authMiddleware,
]);

This is not Koa or Express, this is a package for next.js, in its unique style and format of its API. Documentation for the @nimpl/middleware-chain package.

And to end, let me leave a few links here.

My Medium with other useful articles | nimpl.tech with package documentation | github with star button | X with rare posts | in just to have it

The dot map used as the background for images at the beginning of the article is made by mocrovector from freepik.

A release starts with an idea. When that perfect idea comes in the brainstorming, the idea that will appeal to all users and attract new customers. The idea is presented to a team of managers, marketers and is unconditionally supported by everyone.

The technical task is elaborated and the task is given to the developers. They grumble, asking to make an unnecessary updates, set clearly inflated deadlines, but eventually do the task. The task is testing and going to the end users. At this point, the life cycle of the idea is complete. Now all that remains is to wait for a mass of fresh analytics and celebrate…

Some losses are allowed in the first week — there is little data, users are getting used to the updates, other improvements are being rolled out, a high influence of outliers. However, by the second week, it becomes evident that the idea not only did not attract new clients but also made some users use this product less.

The idea, which has gone through dozens of discussions and received hundreds of enthusiastic comments, has failed.

The Hypothesis Failed

The introduction turned out to be voluminous. But I wanted to start this article with the long journey of the hypothesis. Because it broke at the very beginning — it was supported only by people similar to its author. But these people are not the most suitable target audience, and maybe even their rare exceptions.

That’s why when changing existing functionality, they do not rely on the thoughts of the author and the team. To make the right choice, they conduct research, analyze existing product and market analytics, compare with competitors. But often behind all these methods goes the only reliable way to test the hypothesis on the business audience. This (attention!) — is to test it specifically on the business audience.

But not on all of it. This method is called A/B testing. And all the further narration will be devoted to it.

A/B Testing

As we found out above — A/B test is testing a hypothesis on the very audience of the business. This test is due to the comparison of one functionality (option A) and another (option B).

Sometimes A/B tests are conducted alternately — that is, they first measure option A, and then, the next week they measure option B. This variant will not be described in the article because it does not represent anything interesting in technical terms (and here will be nothing about data collection and analysis).

A/B testing can take place for checking changes — in which case option A remains the current functionality, as well as for checking several implementations of a new idea — in this case, both options contain new functionality and they are compared relative to each other.

Despite the name, there can be any number of options. The main thing is that the audience allows it. That is, it should be possible to collect enough data for each option, excluding outliers and interference.

So, suppose a decision is made to make a critical change to the website or application. At this moment, the seriousness of this change is assessed and a decision is made to implement it through an A/B test. At the same time, depending on the risks, they decide how to distribute the traffic.

Often the test starts with showing the new option only to 10% of users. Then, if the changes did not lead to a sharp deterioration in metrics on these 10% — it is extended to half of the users, so that the comparison would be full-fledged. Based on the results of this test, make a decision — to leave the new option or return the previous one.

At the same time, of course, according to the results of testing, it is possible to return the idea for revision and then launch the updated test. This can be repeated dozens of times until the necessary change leads to business metrics growth.

A/B Test Rules

• Variants should contain only those changes that are being tested. The basic rule, but, for example, along with adding a new block to the page, you may want to change its colors. As a result, all changes will affect the results and it will be impossible to understand how the addition of the block specifically influenced.
• A rule related to the first one — all test options should fall out to the user at the same speed, delay, and, of course, bugs.
• Another derivative rule — avoid overlapping tests. If 2 or more tests are conducted on one page (with same conditions), they all distort the results of each other and it is almost impossible to identify these distortions.
• The user should not understand that he is participating in the test. Knowing this, the user may behave differently, for example, leave the service or reload the page to exit the test.
• In interface tests, the user should spin the roulette wheel only once. In the future, he should see the option that fell out to him. Here is primarily a question of user experience — if he cannot see the same content when re-entering — he will have an unpleasant experience from the service.

A/B Test Scheme

Now, having sorted out what, why, and how is conducted, we can finally move on to the most interesting — the technical part.

And it is worth starting with the basic scheme of the application’s work:

Client — server — client

A very simple communication scheme. The client addressed to the necessary address, the server processed this request and response to the client.

With the advent of A/B tests, this scheme begins to work a little differently. Now, doing identical requests at the same time and under the same conditions, different answers are expected — those very option A or option B.

In practice, this is usually performed by a layer — either at the CDN level, a regular middleware on the server, or other intermediate tools, such as nginx (module for conducting A/B tests in nginx). Further, for the simplicity of the story, just middleware will be used.

In fact, A/B tests can be conducted entirely on the client side. This is how Google Optimizer worked (but in September 2023 it was deactivated). The main problem with this approach was that the user who got option b was redirected to another page. This, in turn, made option B less comfortable for the user and gave out the testing.

This approach can be schematically described like this:

Implementation of A/B tests

Below will be described the solution on next.js, but it can be repeated on any other technology that can change cookies and make rewrites (or return a specific page).

In next.js, this is done by middleware, which runs in the so-called edge-runtime, i.e., at the CDN level. In fact, outside of Vercel (a platform for deploying applications, owning next.js), it’s just a part of the server that works before processing routes.

The first and simplest method of testing is to show one of the options without any conditions:

import { NextResponse, NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
    if (request.nextUrl.pathname === '/home') {
        if (rollVariant() === 1) {
            return NextResponse.rewrite(new URL('/home-animated', request.url));
        } else {
            return NextResponse.rewrite(new URL('/home', request.url));
        }
    }
}

The user has entered the /home page, in the middleware a random option is selected. If the user gets option B — the home-animated page is returned, otherwise the standard home.

It is more convenient to make the options of the interface test separate pages — a new option — a new page.

root
--app
----about
------page.tsx
----home
------page.tsx
----home-animated
------page.tsx

How to choose which option to show to the user? Just roll the dice! If less than half — variant a, otherwise — variant b.

const rollVariant = () => Math.random() < 0.5 ? 1 : 0;

Now, depending on the rolled value, the user will receive from the server either a standard page or home-animated. For the same time and invisibly for the user.

However, with each entry, the user will get a random option. To prevent this from happening, you can write to the database that the client has become a participant in the A/B test. In the case of anonymous tests, test information can be saved in cookies and read from them in the future.

So, if the client already has a cookie recorded — you can skip the steps with the request check and option selection, and immediately issue the necessary page.

import { NextResponse, NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
    if (request.nextUrl.pathname === '/home') {
        const prevVariant = request.cookies.get('ab_variant');
        const variant = prevVariant ?? rollVariant();
        let next: NextResponse;
        if (variant === 1) {
            next = NextResponse.rewrite(new URL('/home-animated', request.url));
        } else {
            next = NextResponse.rewrite(new URL('/home', request.url));
        }
        next.cookies.set('ab_variant', variant.toString());
        return next;
    }
}

Of course, these data need to be analyzed. Here are two options — send data from the server, in parallel with issuing the result to the user, or already on the client, having previously transferred the test results from the server. For the latter, you can use the previously created cookies.

Further, it may be necessary to launch A/B tests only on a specific group. This can be a certain share of users, users of specific browsers, users from specific companies, or anything else.

That is, it is necessary to check the user for a match and depending on the result, either include him in the test or not:

import { NextResponse, NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
    if (request.nextUrl.pathname === '/home' && request.nextUrl.searchParams.has('utm_campaign')) {
        // ...
    }
}

Also, it may be necessary for only new users to participate. But, formally this is the same task as described above. This is a group of users who were not on the site before. In the case of anonymous users, it can be determined, for example, by the absence of cookies of the test, acceptance of policies, or analytics.

Of course, one test will not be enough and it will be necessary to run dozens, if not hundreds, of tests in parallel. The same logic will be used for this, but it will now be checked according to an array of instructions of the launched tests until the first suitable one.

Of course, every company will have different conditions, different requirements, and different orders. The basic example described above is a possible implementation, from which everyone can decide exactly what is needed and how.

Nevertheless, it was decided to try to implement a universal package for conducting A/B tests in next.js — @nimpl/ab-tests.

@nimpl/ab-tests

The first thing to note is that the package meets all of the above, including all the rules. At the same time, it has a number of pleasant possibilities, executed in a familiar API for next.js developers.

The operation of the package can be described as follows:

The main advantage of the package is the principle of finding a suitable test. Each test may include the keys has and missing. Those familiar with next.js know these keys from working with rewrites and redirects. For example, a test can be described as follows:

{
  id: 'some-id',
  source: '/en-(?<country>de|fr|it)',
  has: [
    {
      type: 'query',
      key: 'ref',
      value: 'utm_(?<ref>moogle|daybook)',
    }
  ],
  variants: [
    {
      weight: 0.5,
      destination: '/en-:country/:ref'
    },
    {
      weight: 0.5,
      destination: '/en-:country/:ref/new'
    }
  ],
}

This test will be performed for all users who come to the page with English locales and the label utm_*. Then the user will see either the base page for this company or a new one.

Each test also contains other keys, such as:

id - the identifier of the test, which will be written in the cookie;

source - another familiar key from next.js - the path on which the test is conducted;

variants - a list of options, which can be any number.

Each variant describes a weight — a weight and a destination (again, a familiar key from next.js). The main rule is that the total weight equals one.

Additional part

The development of the package did not end there. During the work on the package, it was decided to test its operation in several projects. However, adding a simple middleware turned out to be a real adventure. The problem is that the projects already had middleware — one with next-intl, one with next-auth.

Surprisingly, none of the projects had previously had the task of supporting two external middleware (only together with the internal ones). As a result of the search, it was not possible to find any solutions. All existing solutions work due to their own APIs — made in the style of express.js or even in their own vision. They are useful, well implemented, and convenient. But only in those cases when you can update every used middleware for them.

The situation here is quite different. It is necessary for each middleware to work as an original middleware from next.js. In general, another new solution was needed. I took it upon myself.

So @nimpl/middleware-chain appeared:

import { default as authMiddleware } from "next-auth/middleware";
import createMiddleware from "next-intl/middleware";
import { chain } from "@nimpl/middleware-chain";

const intlMiddleware = createMiddleware({
    locales: ["en", "dk"],
    defaultLocale: "en",
});
export default chain([
    intlMiddleware,
    authMiddleware,
]);

A small and neat insert.

You can check out these and other packages for next.js at nimpl.tech. Perhaps you’ll find some of the solutions useful (such as the getter getPathname for server components or class minifier). Also, I have made publicly available a utility I use for editing groups of JSON files — @nimpl/inio.

The first day of React.js Conf just concluded. This much-anticipated conference took place almost 3 years after the previous one. The React updates were just as eagerly awaited. The conference began with these updates and this article will be dedicated to them. And yes, as you saw from the preview — version 19 has moved into the release candidate status. The full release is promised within two weeks.

Overall, as a next.js developer, most of it was familiar to me. Dozens of articles on the hub have already talked about almost every part of this update, and I partially touched on the updates introduced in next.js.

It can be said that the main directions of this update were achieving “High UX at high DX”. Maximum performance with maximally simple code. At the same time, there was almost no mention of server components in part of the updates, only indirectly. And so, let’s move on to the conference itself.

As usual in such conferences, everything starts with a description of growth. React downloads reached One Billion per year. The growth of the tool is inevitably linked to the growth of the community. Therefore, Stackoverflow statistics were also shown — 40% of developers use react in web development, 36% are learning it.

Also of interest, React functionality has become possible to a greater extent only within frameworks, so now React.js has started recommending specific ones. The slide showed remix, redwoodjs, next.js, and expo. Interestingly, there is no react router in this list.

Yes! React Router can now be added to this list. The first conference report was about him from Ryan Florence. Now with react router, you can not only do SPA but also SSR and SSG. This is now possible in conjunction with Vite. Hooks are available for working with data and server components.

But for now, let’s return to the changes in React.js. The problem of coordinating elements and expanding the application was described next. JSX solved the problem of coordinating elements in UI development. Then they added Suspense, which solved the problem of coordinating elements when loading elements (what to do during loading and what to show to the user at this time).

In React 19, the following were also added:

• Server components. Among other things, such components can solve the problem of loading data and their further transfer to components (using familiar props);
• Embedding metadata. Metatags can be embedded anywhere. React itself will add them to the right place and leave only one copy.

• Preloading methods. In addition to manually adding tags, methods for preloading links were also added — preinit, preload, prefetchDNS and preconnect. The documentation also describes the preloadModule and preinitModule methods, but for some reason, they were not shown at the conference.

• Embedding styles. Similar to meta tags, work will be done for styles. However, here an option of prioritization is added — depending on it, it will be determined which styles are more important (and accordingly will be lower in the DOM).

The style loading of the component is now tracked by suspense. That is, you can display the loader not only while the component is rendering, but also while its specific styles are being prepared.

With the advent of server components, React took on more responsibility in terms of server rendering, as a result, hydration takes on even more logic and potential problems. The React.js team improved hydration errors.

In addition to significant changes in working with the construction of a real tree, the logic of interaction with forms has been updated in React.js. First of all, the form component was included in react-dom, which means significant changes over the element. And first of all, this change concerns the change of the “action” attribute — as an alternative to submitting a form through onSubmit or a native attribute.

Adding action itself looks just like onSubmit, but instead of an event, it immediately takes FormData.

Also, for form fields and buttons, the formAction prop has been added, which works in an identical manner.

Perhaps the basic advantage of using action instead of onSubmit is that with client actions, if the user calls form submission immediately (even before loading the form logic) — its submission will be postponed and will be performed as soon as the logic is ready. In server actions, the submission will occur immediately because it does not require client js.

But, in addition to the basic difference, there are significant changes in interaction with form submission — these are new hooks. useOptimistic, useFormStatus and useActionState.

Sam Selikoff shared examples of working with them in his presentation “React unpacked: A Roadmap to React 19”. For example, this is what replacing onSubmit with action + useActionState looks like:

Then you can add optimistic render:

And again, let’s return from the report to the key changes. A relatively small change was shown next, but very, very valuable. In React.js 19, you can pass ref to a functional component as props. Right away. Without forwardRef.

Also, when passing ref to components, you can return a callback on unmount.

The final key change was the React Compiler. An advanced loader with memoization out of the box. Together with him, React will automatically set up memoization in the application. Lauren Tan elaborated on this in her presentation “React Compiler Case Studies”.

So, to understand how to set up memoization, React analyzes the relationships from the place that triggers the rerender to the endpoints:

Based on these relationships, the compiler can imagine a full graph of dependencies:

And then, depending on these connections, set up memoization with the necessary dependencies. In this case, since songs do not change — filteredSongs should remain the same (they will be memoized with a dependency on songs), and if the song is changed by setSong, NowPlaying should be rerendered (it will be memoized with a dependency on song).

“Maximum performance with maximally simple code”.

A great solution, however, it will be interesting to see how memoizations will be set up in practice — where developers should write them, and where it is worth not complicating and leaving this logic to the compiler.

You can install the compiler right now on all major frameworks and build systems that support babel. It is already being used in Instagram, Facebook, and Bluesky (the company where Dan Abramov now works).

Also, to increase reliability and quality of compilation, you can install an eslint plugin, which will indicate all problems with code optimization. In general, the plugin can be used independently of the compiler.

npm install eslint-plugin-react-compiler

You can also use a command-line utility that will check the application for possible optimization by the compiler

npx react-compiler-healthcheck

Another innovation was shared by Lydia Hallie — the use function. Yes, it’s not a mistake — it’s not a hook.

The key difference between use and hooks is that use can be used within conditions

Use itself can take either a promise or a context. It’s hard to imagine a situation where you can’t be sure what argument will be passed to use — a promise or context and why not just make two independent functions.

In conclusion, I will note the amazing reports, presentations, examples, and performances in general. The React.js team was really able to show the possibilities of all improvements (next.js team forgive me but they didn’t even come close). Also, from a pleasant difference, I note that the React.js team refused to include in the core the rewrite of the fetch API and rolled back already finished changes.

The general list of changes looks like this:

UPD: Seems like I can leave some advertising here.

If you’re using next.js — you might want to check out the solutions from nimpl.tech, you might find some of them useful (like for example the getter getPathname for server components or the package for configuration config set up for all next.js environments)

UPD2: There are still entries here, so I’ll leave another update.

I just submitted a PR for the addition of getPageContext functionality in next.js (for non-next.js readers — the huge pain of working with contexts in server components [because there simply isn’t one and there are no alternatives]). Leave a reaction if you’re familiar with this pain.

In version 13, the next.js team introduced a new approach to application design — the so-called App Router. In version 14, it was made stable and primary for new applications.

The App Router significantly expands the functionality of next.js — partial pre-rendering, templates, parallel and interceptable routes, server components, and much more. However, despite all these improvements, not everyone has decided to switch to the App Router. And there are reasons for that.

I briefly discussed the advantages and problems of the new router in the article “Next.js App Router. Experience of use. The path to the future or the wrong turn”. Further, the conversation will not be about new abstractions or their features. In fact, the key and most controversial change is caching. This article will explain what, why, and how the most popular frontend framework, Next.js, caches.

What does next.js cache?

On the next.js website, you can find excellent documentation on the caching process. First, a brief overview of the main points from the article.

Any request in next.js triggered through fetch will be memoized and cached. The same will happen with pages and the cache function. How this works under the hood will be discussed in the following sections. The general page building process works as follows:

That is: the user goes to the page, a request for a route is sent to the server, the server starts rendering the route, sending the necessary requests along the way. Then all this is executed and cached.

In addition to the cache in the scheme, there is also memoization. It is needed for recurring requests — so that they are not sent several times, but are subscribed to the first one.

Caching on the server is done using the so-called Data Cache. You can remove data from it by calling the revalidatePath and revalidateTag functions. The first one will update the cache for the page, the second one for the tag specified in the requests.

Data is also cached on the client side — inside the client router.

Not mentioned in the article — next.js also caches rewrites and redirects. That is, if the user was once redirected from the / page to the /login on the server - now he will continue to be redirected there. This will be cached in the client router until the client cache is cleared.

You can clear the cache on the client using router.refresh or by calling revalidatePath and revalidateTag in server actions.

'use server'

import { revalidateTag } from 'next/cache'

export default async function submit() {
  await addPost()
  revalidateTag('posts')
}

Why is caching needed in next.js?

The fetch from next.js is a wrapper over the native node.js fetch. The wrapper is configured to connect with the so-called Data Cache. This is done so that each request can be processed as described in the schemes above. The next.js team is most often criticized by the community for this replacement of the native API.

Later in next.js, the ability to disable caching of a request was added with the cache: "no-store" option. But even with this option, it will continue to be memoized. As a result, one of the key APIs for development has ceased to be controlled by the developer.

Nevertheless, there were reasons for this step. And it is unlikely that the initial reason was optimization. For optimization, it would been enough to create a new function for requests — a separate API, of which there are hundreds in next.js.

I followed a similar path when developing the next-translation package (as I wrote in a previous article). Then an interesting problem arose — too many requests were going to the server (not triggered through fetch). Looking into the reasons and reading the next.js source code, it became clear that the application is now being built in several independent threads. Strange, why they didn’t talk about this in the latest releases. Each thread lives as an independent process, as a result, it was not possible to make normal caching for the entire application inside the package.

The same problem arose before the next.js team — each integration, each package, each user now began to send several times more requests, and the previously configured caching systems stopped working correctly. And as a solution — the remodeling of fetch and hiding this feature under the hood.

How does Data Cache work?

The saving of loaded or generated data occurs in the so-called cacheHandler. Out of the box, next.js has 2 options for cacheHandlers — FileSystem and Fetch. This cacheHandler will be used both for caching requests and for caching pages.

FileSystem is used by default, saves data to the file system, additionally memoizing in-memory. FileSystem copes well with its task, but it has one drawback — it works as part of the application. From this it follows that if the application is created in several replicas — each of them will have an independent cacheHandler.

This problem is especially felt when the application works in ISR mode. You need to get into each replica and revalidate the cache in each of them. At the same time, check that they will load the same data. Also, if 2 replicas work with one folder — conflicts can arise in the file system during recording.

Probably for this reason, you can find Fetch variant in the framework code. It saves the cache to a remote server. However, this cacheHandler is only used when publishing the application in Vercel, as it saves data on Vercel servers.

As a result, the out-of-the-box solution does not cover all needs — FileSystem is not suitable if there are several replicas, and Fetch if the application is not deployed in Vercel. An important feature is that next.js allows you to write your own cacheHandler. To do this, you need to pass to the application configuration the path to the file with the class (CacheHandler), in which the get, set and revalidateTag methods will be described:

// cache-handler.js
module.exports = class CacheHandler {
  constructor(options) {
    this.options = options
  }

  async get(key) {
    // ...
  }

  async set(key, data, ctx) {
    // ...
  }

  async revalidateTag(tag) {
    // ...
  }
}

And connect it in the application configuration:

module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // disable default in-memory caching
}

One of these cacheHandlers is cache-handler-redis, which the next.js team referred to in the last release.

Key points

Next.js caches a large part of the processes.

Caching occurs in several stages — caching transitions and pages in the client router, memoization of the request, caching on the server of requests and pages.

Quite often, applications are launched in several replicas. Replicas need a common cache, especially this is acute when the application works in ISR mode.

The application itself is assembled in several threads that do not have access to each other.

The cacheHandler is responsible for caching. Next.js has two out-of-the-box options — working with the file system and working with a remote server, but the latter is only available within Vercel.

You can write your own cacheHandler.

Caching refinement

Let’s go back to the next-translation package. To solve the problem of unnecessary requests, I came up with an interesting way out — to raise an additional server and process requests going through it — as a result, all requests go from one place, which means caching can be configured in it. This is a principle similar to FetchCacheHandler and the approach in Vercel in general — when during the build the data is cached on the vercel server, and since the server is nearby, this works quickly.

However, caching is too much responsibility for a translation library. The next task was to overhaul the caching logic to combine the next.js API, libraries, and solve common problems. As a result, another library was created — next-impl-cache-adapter.

Cache management

As already mentioned, for a common cache between instances (replicas, copies) — the cache must be separate from each instance of the application. next-impl-cache-adapter solves this by creating a separate service.

This service is a server in which the desired cacheHandler works. Each application instance will process requests through this server. At the same time, the server does not need to be restarted with each build. Outdated data will be automatically deleted during the launch of a new version of the application.

Server code:

// @ts-check
const createServer = require('next-impl-cache-adapter/src/create-server');
const CacheHandler = require('next-impl-cache-in-memory');

const server = createServer(new CacheHandler({}));
server.listen('4000', () => {
    console.log('Server is running at <http://localhost:4000>');
});

In this example, the server is passed next-impl-cache-in-memory — this is a basic cacheHandler that saves data in-memory.

A special adapter for working with the cache is configured in the application itself:

// cache-handler.js
// @ts-check
const AppAdapter = require('next-impl-cache-adapter');
const CacheHandler = require('next-impl-cache-in-memory');

class CustomCacheHandler extends AppAdapter {
    /** @param {any} options */
    constructor(options) {
        super({
            CacheHandler,
            buildId: process.env.BUILD_ID || 'base_id',
            cacheUrl: 'http://localhost:4000',
            cacheMode: 'remote',
            options,
        })
    }
}

module.exports = CustomCacheHandler;

The created adapter is connected in the next.js configuration:

// next.config.js

module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0, // disable default in-memory caching
}

The package supports three caching options: local, remote and isomorphic.

local

Standard solution. The cache is processed next to the application. It is convenient to use in development mode and on stages where the application is launched in one instance.

remote

The entire cache will be written and read on the created remote server. Convenient to use for applications launched in several replicas.

isomorphic

The cache operates next to the application, but also saves data to a remote server. Convenient to use during assembly, preparing the cache for the moment of launching application instances, but without spending resources on loading the cache from a remote server.

As a cacheHandler, it can be any cacheHandler supported by next.js. And vice versa, cacheHandlers from the package can be directly connected in next.js.

Conclusions

The App Router introduced a lot of very useful updates, but lost in convenience, predictability, and versatility. First of all, due to caching. After all, this is a task in which there is no and cannot be a universal solution. The ability to disable caching for a request and write your own cacheHandler solves most of the problems. However, memoization and caching in the client router remain out of control.

The next.js team itself is in no hurry to develop solutions for specific tasks. For this reason, since the release of the stable App Router, I continue to work on the implementation of packages that solve next.js problems. Along the way, telling about them in articles.

Let’s make the web not only faster, but also clearer.

Links

next-impl-cache — solutions for setting up caching in next.js.

next-impl-getters — implementation of server getters and contexts in React Server Components without switching to SSR.

next-impl-config — adding support for configuration for each possible next.js environment (build, server, client, and edge).

next-classnames-minifier — compression of classes to characters (.a, .b, …, .a1).

next-translation — i18n library, developed with consideration of server components and maximum optimization.

Nonetheless, this decision had objective reasons. Zeit could be labeled a failure in terms of investments — essentially, it was not perceived as a startup and that was the main problem. Some of the investors in the future company Vercel — CRV — said they were “delighted to resume business with Guillermo, after he returned to the path of entrepreneurship and founded Vercel”.

The decision, so critically perceived by the community, turned out to be extremely effective for attracting investors. Immediately after the rebranding, now the company Vercel, announced the collection of $21 million. Soon the company received another $40 million, then $102 million — then Vercel was valued at $1.1 billion, becoming Guillermo’s first unicorn.

In this, the final part of the series, we will talk about the extreme, the most important, and successful project of Guillermo — the company Vercel.

History of Vercel

1. History of Vercel. Annotation;
2. History of Vercel (1/7). 1990–2009. Guillermo Rauch. Childhood and first steps in programming;
3. History of Vercel (2/7). LearnBoost. A leading tech company;
4. History of Vercel (3/7). 2009–2013. LearnBoost. Team that has become a leader in open source;
5. History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream;
6. History of Vercel 2013–2015 (5/7). Automattic;
7. History of Vercel 2015–2020 (6/7). Zeit and Next.js;
8. History of Vercel 2020-Present (7/7). Zeit is now Vercel.

Rebranding

First, it’s worth dwelling on what the company zeit represented. And to describe this is quite difficult — speaking Zeit implied directly the company itself, and often spoke about Zeit Now — for example, in one interview Guillermo was asked a question, starting with “Your products zeit and zeit now”.

The new company was supposed to unify these products. And today, saying “Vercel”, implies both the concept of Zeit and Zeit Now. “Our product consists of two parts: NextJS and a platform distributed around the world, and the business is based on the scalability of this platform” — Guillermo Rauch.

The decision to rebrand caused a surge of emotions in the community — a lot of negative comments, requests to return everything back and/or not to sell the company (it is difficult to understand why many considered this rebranding a sale).

In addition to this, there are more interesting reasons for the rebranding. So, Guillermo noted that the old name sounded differently in different languages and not everywhere it was easy to write what was heard — “The new name was analyzed in five languages by five linguists from different languages of the world”.

The new name — Vercel — was devised by the company Lexicon. According to them: “Zeit needed a name that would reflect the efficiency, superiority, and power of their platform. They also needed the name to be short, spread worldwide, and easy for developers to type command”.

The business model as a whole remained unchanged. “Although anyone can access the library for free, the company’s business model is based on selling software as a service (SaaS) to companies” — Guillermo Rauch.

Investments

As mentioned earlier, the rebranding quickly paid off. Immediately after it, Vercel announced a successful round A — $21 million. Investors were: Accel, mentioned CRV, Naval Ravikant, Nat Friedman, Jordan Walke and others. Accel fund member — Daniel Levine — is a member of the Vercel board of directors.

The company went for the next round only after 8 months, in December 2020, and was able to raise $40 million. The biggest investor in this round was Google Ventures. Also, new investors were Greenoaks Capital, Bedrock Capital and Geodesic Capital. Bedrock founder Geoff Lewis is also a member of the Vercel board of directors.

The next round took place in June 2021. The company raised $102 million, received a valuation of $1.1 billion, thus becoming a unicorn company. The main investor was the company Bedrock Capital. All previous investors were retained and several new ones were added (8VC, Flex Capital, GGV, Latacora, Salesforce Ventures, and Tiger Global).

The last round took place in November 2021, during which Vercel raised $150 million. The main investor was GGV Capital, also all the previous investors supported the company (including Accel, Bedrock, and Google Ventures).

Private investments are also interesting. Guillermo, after leaving Automattic, became an investor himself and began investing mainly in emerging tech companies. Some of his seed investments were companies auth0 and scale, which soon became unicorns (Auth0 became the fifth with Argentine roots, that is, shortly before Vercel).

Soon after, their co-founders (Auth0 — Matias Woloski, scale — Alexandr Wang) — invested in Vercel.

The complete list of Vercel investors can be found on the company’s website.

Total investments in Vercel amounted to $313 million. This allowed the company not only to actively develop and attract people but also to make some acquisitions.

Purchases and Important Actions

One of the most important and valuable actions of the company was the attraction of Rich Harris, the creator of svelte. This happened in November 2021, 2 weeks before the completion of the last round of investments (and possibly played a significant role in the success of the round).

So far, the company has made 2 major acquisitions: the company Splitbee and the utility turborepo. The cost of both purchases is not named.

First, Vercel bought turborepo, in December 2021 — a utility created by Jared Palmer (he is also the creator of Formik and TSDX). “Turborepo is a high-performance build system for JavaScript and TypeScript codebases”. The main features of the utility are parallel assembly of applications in a monorepo and caching processes (including remote ones).

Jared himself joined the Vercel team after purchasing the utility, his main task was to speed up the assembly in Vercel.

The next purchase took place almost a year later, in October 2022. The company Splitbee was purchased — a platform for collecting real-time analytics, created only in 2020.

The co-founders of the company joined the Vercel team, their main task was to develop analytics tools within Vercel (in the service you can buy analytics collection, the price starts from $10 per project).

Open-Source Development

“Supporting open-source projects is an integral part of our mission “Make the Internet Faster””.

Despite several purchases — the main improvements come through integrating third-party services. For example, there is integration with Check.ly, which takes a URL and runs automatic end-to-end tests, simulating web browsers for this interface. Another interesting integration is made with Sanity CMS, together with them Vercel adds the possibility of editing the site on the site itself (next-preview.now.sh).

In total, Vercel has about 100 integrations (Mongo DB, Contenful, Wix, Shopify, AWS, Sentry, Slack, Auth0, etc.).

Vercel owns such frameworks and libraries as Next.js, Hyper, SWR, pkg, turbo, satori, serve, styled-jsx, ai, and other less popular utilities. Also, team members are authors of many libraries.

Next itself after the rebranding became 10 times more popular (from half a million to 5 million downloads weekly).

Vercel is also a sponsor of Nuxt, Astro, webpack, Babel, NextAuth, Parcel, and Unified and other open-source projects.

Team

Today the company has more than 200 employees, only an office in San Francisco, but most of the team works remotely from all over the world. This situation has been in the company from the very beginning, as its parent, Zeit, was founded by an Argentine, a Finn, and a Japanese, who often worked from different places. “From the very beginning, we were a remote company. We worked together from San Francisco, Argentina, Brazil, Finland, Japan, and Germany. We were fortunate to use remote work before covid forced us” — Guillermo Rauch.

In hiring, the company adheres to the policy of Guillermo’s first projects — they attract active participants in open-source. Vercel is also worked on by the creator of Webpack and Turbopack Tobias Koppers, creator of Svelte Rich Harris, React developers — Sebastian Markbåge, Andrew Clark, and Josh Story.

Most of them are hired by the company with the expectation of continuing work on their projects. So, Sebastian still heads the main React team, but also helps support the development of React in Vercel.

Guillermo himself, in addition to Vercel, is involved in investing. In April 2022, he received a second citizenship — American.

History of Vercel 2020-Present (7/7). Zeit is now Vercel was originally published in History of Vercel on Medium, where people are continuing the conversation by highlighting and responding to this story.

The main task of the company was to provide developers and teams with the ability to easily develop, preview, and deploy their applications.

“One of my dreams is that the next Facebook or Snapchat will be created by someone who didn’t have to go through all this training, develop these connections, and hire these bright people. It could be a girl from Africa or a boy from Bangladesh” — Guillermo Rauch.

This part will discuss the most uncertain period in the history of Vercel — the time when the company was becoming known to the community and fading from investors’ view.

Zeit first became known thanks to its product Now — a tool for deploying applications with a single command from the terminal, allowing developers to easily assemble their projects and instantly share them.

History of Vercel

1. History of Vercel. Annotation;
2. History of Vercel (1/7). 1990–2009. Guillermo Rauch. Childhood and first steps in programming;
3. History of Vercel (2/7). LearnBoost. A leading tech company;
4. History of Vercel (3/7). 2009–2013. LearnBoost. Team that has become a leader in open source;
5. History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream;
6. History of Vercel 2013–2015 (5/7). Automattic;
7. History of Vercel 2015–2020 (6/7). Zeit and Next.js;
8. History of Vercel 2020-Present (7/7). Zeit is now Vercel.

Now

The utility’s purpose was simple: You type “now” in the command line and get a new server. This concept is basically inherited by Vercel and even described in its main slogan “Develop. Preview. Ship”.

After entering the command, within a second, a new instance of the application is created and published on the Internet. You can share the link to the published application immediately, even before the build is completed — initially, the build process will be displayed on it, and then the application itself.

Guillermo described the procedure as follows:

1. We take package.json, Dockerfile, or static files, publish them in the cloud, and serve them securely over HTTP/2.
2. Each deployment is immutable and has its unique URL. They look like this: https://rauchg-blog-hhafwnefgw.now.sh/.
3. To go into production, you just assign them domains. Simply, with one command: now alias rauchg-blog-hhafwnefgw.now.sh rauchg.com.

An application for PC — “Now Desktop” was also created for the utility. The utility itself supported the publication of static sites, next.js applications, as well as applications on go, php, node.js, python, rust, and other options.

Next, a global DNS solution — “Zeit World” was created.

HyperTerm

The Now utility had its page on the company’s website. At the very beginning of this page, there was a demo of its work in the terminal. And what is interesting here is not so much an example of work, but the fact that the terminal was added not as a gif, but written in pure html, css, and js.

Guillermo liked the demo result, as it looked like the simplest terminal. Then he thought about a new project — Hyper.app. The development of the first version took about two weeks. The terminal, like most other company projects, was published in open access and immediately after a quick presentation attracted the attention of developers — they began to actively participate in the development of the utility and soon more than 100 plugins were written for the terminal.

HyperTerm itself was created on Electron. This allowed you to open the developer console at any time and make various changes. You can also install ready-made plugins, many of which are collected in a special list.

The terminal is still highly popular (gihub, website).

Next.js

In 2016, Zeit released Next.js — a framework for creating Jamstack-style websites. The framework page lists the authors: Tim Neutkens, Naoyuki Kanezawa, Guillermo Rauch, Arunoda Susiripala, Tony Kovanen, Dan Zajdband. All but Dan worked at Zeit. Dan is familiar with Guillermo from JSConf Argentina, and probably as a developer of The Lift company (which used cloudUp, Guillermo’s second startup).

Next.js was initially released as an open source project on GitHub on October 25, 2016. The framework offers out-of-the-box server-side rendering, static site generation, API routes, and more. The goal was to provide critical features that React lacks — primarily in terms of speed and SEO optimization.

“We work for those who do front-end design to make e-commerce sites, media and everything else better… Everything should look good, sites should load quickly” — Guillermo Rauch

Today, Next.js is used by Uber, Amazon, Open AI, and thousands of other companies. Being a framework for React, Next.js has become an important part of the ecosystem — “NextJS takes it to a new level. And now many ideas from NextJS inspire React itself”.

Zeit Platform

Despite the fact that applications were published through the Now utility — it was just a part of the Zeit platform.

After entering the platform, you could publish up to 3 applications for free through Now.

However, you could not link domains in the free tariff. This was a paid feature, the price started from $15, and, for example, support cost from $750 to $2000. Also, you could buy domains directly in the platform.

The pricing policy was changed in December 2018 and, most importantly, limits on the number of applications and linked domains were removed, and for many categories, the price was calculated based on the resources spent over the limits. It lasted until the end of 2019, when it was changed again and fixed tariffs from $20 appeared.

Co-founders

Guillermo Rauch

In addition to the utilities mentioned in the article, Guillermo participated a lot in conferences and presented Now and Next.js. Also during this period, he was a mentor for the “Open Source Engineering” course organized by Stanford.

Tony Kovanen

Tony worked with Guillermo at Automattic and mainly worked on the Jetpack plugin. He left Automattic with Guillermo and became a co-founder of Zeit. In it, he will hold the position of CTO.

At Zeit, Tony participated in the development of next.js and Now. He worked until 2017, after which he will move to Gatsby. Now Tony is working on the Based.io platform.

Naoyuki Kanezawa

Naoyuki was one of the main developers of Socket.IO and Engine.IO (created by Guillermo).

Now Naoyuki remains part of the Vercel team in the position of Infrastructure/Backend Developer.

Team

From the team it is worth noting:

Tim Neutkens, creator of Micro and MDX;

Arunoda Susiripala, creator of React Storybook;

Igor Klopov, creator of Pkg;

Nathan Rajlich, creator of node-gyp;

Javi Velasco, creator of React Toolbox.

Nicolas Garro / Evil Rabbit, Founding Designer and Brand Architect.

Zeit Day

Also, the Zeit company organized one-day conferences — “Zeit day”, the first of which took place in 2017.

Investments

Zeit can be called a failure in terms of investments — in essence, the company was not perceived as a startup and this was its main problem. So, one of the investors in the future Vercel company — CRV — said when investing in the latter that they are “glad to resume business with Guillermo, after he returned to the path of entrepreneurship and founded Vercel”.

Actually, this was one of the main reasons for the rebranding that happened. And soon Vercel will become Guillermo’s first unicorn (and the sixth unicorn with Argentine roots).

History of Vercel 2015–2020 (6/7). Zeit and Next.js was originally published in History of Vercel on Medium, where people are continuing the conversation by highlighting and responding to this story.

In May 2003, Matt Mullenweg, together with Michael Little, founded a new platform for publishing blogs. It was not the first such platform; the most popular at the time was b2/cafelog. Indeed, Matt and Michael were the developers of that platform, but they decided to create their own product. The new platform developed rapidly and quickly gained a large audience.

This part will discuss what Guillermo Rauch and the Learnboost team did after Automattic acquired them.

History of Vercel

1. History of Vercel. Annotation;
2. History of Vercel (1/7). 1990–2009. Guillermo Rauch. Childhood and first steps in programming;
3. History of Vercel (2/7). LearnBoost. A leading tech company;
4. History of Vercel (3/7). 2009–2013. LearnBoost. Team that has become a leader in open source;
5. History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream;
6. History of Vercel 2013–2015 (5/7). Automattic;
7. History of Vercel 2015–2020 (6/7). Zeit and Next.js;
8. History of Vercel 2020-Present (7/7). Zeit is now Vercel.

Automattic

On May 27, 2003, Matt announced the availability of the first version of the new platform and named it “WordPress”.

The main task of Automattic itself (besides developing WordPress) became hosting and supporting websites written in WordPress. The main principle of monetization was that any user could create a site on WordPress, publish it for free, and then, if necessary, pay for additional features.

Automattic raised 6 million in Series A and B funding rounds from investors including True Ventures, Polaris Venture Partners, The New York Times, and others. In May 2013, Tiger Global invested 50 million dollars in purchasing shares from Automattic’s early investors. By that time, about 20% of websites were running on WordPress.

Automattic actively purchased interesting products, primarily due to the people working on them. In 2013, they met with Guillermo and Tian Lu.

Sale of CloudUp

On September 25, 2013, after the meeting, Automattic announced the purchase of CloudUp, along with the company LearnBoost and all related libraries (including socket and mongoose).

This was Automattic’s 12th acquisition (after Lean Domain Search, Poster, Simperium, CodeGarage, After the Deadline, Blo.gs, PollDaddy, IntenseDebate, BuddyPress, Gravatar and Plinky).

The CloudUp team set about updating the editor and tools related to media in WordPress. Matt himself (the founder of WordPress) admitted that CloudUp was significantly better than the WordPress media library. The editor was planned to implement real-time editing for simultaneous work on texts by several people.

Life at Automattic

The LearnBoost and Automattic teams had a similar view on open development — they participated in conferences, created and supported open-source projects. “Automattic and us share a history and vision: we have a distributed workforce, we passionately care about creating a better web and we support our open-source roots” — Tian Lu (co-founder of CloudUp).

The team took on the tasks set for them, but they did not plan to stop working on CloudUp — they created new projects, packages, and talked about the imminent expansion of the service.

They also continued to work on open-source projects. Thus, in 2014, the first stable version of socket.io was introduced.

Nevertheless, the story of the CloudUp service itself ended there. The site remains unchanged and continues to lie on the internet with a field for applying to join the testing.

The Team’s Future

Tian Lu

After the company’s acquisition, Tian remained the general manager of Cloudup, overseeing the creation of a new technology stack and a completely new editor.

Also, in 2013, Tian will create his company Tsukemen. As a co-founder of two startups, Tian raised nearly 5 million dollars from CRV, Bessemer, RRE, and other investors before a successful exit.

Now, Tian is a Vice President of Product at Blockchain.com, responsible for product strategy and design. He joined the Blockchain.com team through the acquisition of his company Tsukemen.

Nathan Rajlich

Since 2013, Nathan has been working at the WordPress company on editors.

In 2014, he spoke at a conference in Buenos Aires on the topic of “Writing a webmodule” — about writing npm modules intended for use in browsers [speech].

Until 2016, he worked at Cloudup and Automattic. He currently works at Vercel.

Tj Holowaychuk

In 2014, while already working at segment.com as a backend developer, he will participate in the development of YAL. In 2014, TJ will write the article “Farewell Node.js” (goodbye node.js) with an official farewell to node.js and a transition to the Go language. However, he continues to support his projects on js (primarily koa). In 2014, TJ will sell express to StrongLoop (but that’s a whole other story).

This was not just a departure from Node.js, but also a partial departure from programming and open-source. The following are TJ’s words:

“No, I have no intentions, my new goal is to live better. After all, open-source doesn’t pay the bills, so it’s better to focus on other things or if you just like a project, that’s cool.

Now I spend most of my time enjoying other things, I code for 2–3 hours a day if I don’t like something. Time is your real currency! Money is good, but don’t waste time. If you really like the project you’re working on, then do it, but don’t neglect other areas of your life (or people).”

In 2016, TJ will create the Apex company, and Guillermo — the Now utility and the Zeit company.

Guillermo Rauch

Guillermo also worked on the development of WordPress, for example, he redesigned the video platform — VideoPress. For this, he “used the Virtual DOM approach and wrote a very simple version of React,” making it interactive and convenient. He added features such as searching for a moment by frames and embedding video functionality.Guillermo left WordPress on October 13, 2015, and founded a new company — Zeit.

History of Vercel 2013–2015 (5/7). Automattic was originally published in History of Vercel on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are dozens of amazing libraries made for internationalization, such as i18n, react-intl, next-intl. They all do an excellent job of adding translations to an application or website. Most of them are tested, debugged, and consistently supported.

But they are all outdated.

After all, during this time, the react ecosystem has been developing. The latest version of next.js has major updates from react.js — cache, taint, new hooks, and, of course, server components. The React.js team will likely introduce these changes in May.

In this article, I will talk about key changes, personal experience, problems with existing solutions, necessary updates, solutions I came up with, and, of course, answer the questions of “why” and most importantly — “why”?

Changes

The first thing to start with is how the changes in React.js made translation libraries obsolete.

Despite the fact that the latest stable version of React.js was released almost two years ago, it has 2 other channels — canary and experimental, where canary is also considered a stable channel and is recommended for use by libraries.

This is the channel that Next.js uses. Next.js launched server components without additional flags inside the so-called App Router — a new directory as an alternative to pages, which uses its conventions and different sugar (about changes and problems which I wrote in a recent article).

Server components definitely solve a number of problems and are a new milestone for optimizations. Including for translations. Without server components, translations were stored both in the compiled HTML and as a large object in the client script. Now you can get ready-made HTML, which doesn’t need anything on the client.

Next.js paid special attention to this feature.

Personal experience

You can add translations (according to the Next.js documentation) as follows:

// app/[lang]/dictionaries.js
import 'server-only'

const dictionaries = {
  en: () => import('./dictionaries/en.json').then((module) => module.default),
  nl: () => import('./dictionaries/nl.json').then((module) => module.default),
}
export const getDictionary = async (locale) => dictionaries[locale]()

// app/[lang]/page.js
import { getDictionary } from './dictionaries'

export default async function Page({ params: { lang } }) {
  const dict = await getDictionary(lang) // en
  return <button>{dict.products.cart}</button> // Add to Cart
}

This solution is described as ready and fully optimized. It works entirely on the server, and the client already receives ready-made HTML. However, the Next.js team missed one important detail — how to pass the language deep into server components.

A big problem with server components is that contexts are not available in them. The Next.js team explains the absence of these functions by the fact that Layout is not re-rendered, and everything that depends on props should be client-side.

Perhaps translation libraries were most affected by this. As a temporary solution, they suggest determining the language in the middleware and adding it to cookies. Then when building the page, read it in the necessary places. But reading cookies means enabling server rendering, which is not suitable for everyone.

In general, the main problem with existing solutions is that most of them are not made for server components. Components and functions were developed for runtime, using hooks and synchronicity.

Another inconvenience was caching in Next.js. Namely — it works fully only for GET requests, and if the weight of translations is more than the limit of 2MB — they will not be cached.

Implementation

Goals and tasks:

• The library must have full functionality in both client and server components;
• Usage should be simple (without extra props);
• All complex logic should be moved to the server;
• Translations should be loaded only as necessary and without additional requests;
• Support for updating translations without rebuilding (ISR/SSR);
• Everything should work on a static site (not with switching to SSR);
• Html entities should be supported.

To my surprise, there is not a single library that would satisfy all these requirements.

The first thing you need is functionality. In the standard version, this is a hook that returns the function t and the Trans component for more complex translations. However, such functionality is needed in server components, and they have many of their own features.

Functionality

The main functionality is divided into two versions — for client components and for server ones and includes:

useTranslation, getTranslation - which return the function t inside the DOM and the language;

import getTranslation from 'next-translation/getTranslation'

export default function ServerComponent() {
  const { t } = getTranslation()

  return (
    <p>{t('intro.title')}</p>
  )
}

'use client';

import useTranslation from 'next-translation/useTranslation'

export default function ClientComponent() {
  const { t } = useTranslation()

  return (
    <p>{t('intro.title')}</p>
  )
}

The interface turned out to be quite familiar, the functions support namespace and query. It is recommended to use it by default, as it is simple to use and in logic. Returns a ready-made string.

For more complex translations, you should use the ClientTranslation and ServerTranslation components. They can replace pseudo-components with real ones.

import ServerTranslation from 'next-tranlation/ServerTranslation';

export default function ServerComponent() {
  return(
    <ServerTranslation
      term='intro.description'
      components={{
        link: <a href='#' />
      }}
    />
  )
}

"use client";

import ClientTranslation from 'next-tranlation/ClientTranslation';

export default function ClientTranslation() {
  return(
    <ClientTranslation
      term='intro.description'
      components={{
        link: <a href='#' />
      }}
    />
  )
}

There are also cases when translations need to be added outside the react tree. For this, you can use createTranslation anywhere.

import createTranslation from 'next-translation/createTranslation'
// ...
export async function generateMetadata({ params }: { params: { lang: string } }) {
  const { t } = await createTranslation(params.lang);

  return {
    title: t('homePage.meta.title'),
  }
}

Page setup

Now about setting up the page. To work with translations, you need to know the language. However, in server components, you cannot use context. For this, an alternative to createContext was made for server components in the next-impl-getters package - createServerContext and getServerContext.

In the package for this, you need to create a NextTranslationProvider. It is recommended to do this at the page level to avoid problems with Layout re-rendering.

import NextTranlationProvider from 'next-translation/NextTranlationProvider'

export default function HomePage({ params }: { params: { lang: string } }) {
  return (
    <NextTranlationProvider lang={params.lang} clientTerms={['shared', 'banking.about']}>
      {/* ... */}
    </NextTranlationProvider>
  )
}

It is also necessary to indicate which translations are needed specifically on the client and to pass only them there. To do this, you can pass an array of client keys or groups to NextTranslationProvider using the clientTerms prop.

Also, sometimes situations arise when a component needs different translations or different blocks are rendered depending on conditions. In such cases, different translations need to be passed to the client. Condition options can be wrapped in NextTranslationTransmitter and client terms are passed to it.

import NextTranslationTransmitter from 'next-tranlation/NextTranslationTransmitter';
import ClientComponent from './ClientComponent';

const ServerComponent: React.FC = () => (
  <NextTranslationTransmitter terms={['header.nav']}>
    <ClientComponent />
  </NextTranslationTransmitter>
)

As a result, only those terms that were specified above in NextTranslationProvider or NextTranslationTransmitter will be passed to client components.

Package setup

Before working with translations, they need to be loaded. For this, you need to create a configuration file in the root of the project. Its minimum configuration is the load function, which will return current translations and an array of languages with permissible languages. The load function is called in server components, and the necessary keys will be passed to the client.

A very important point was the absence of unnecessary requests, that is, full caching is needed.

Here it is worth digressing a little. Starting from the latest version, Next.js builds the application in parallel in several processes. If each process lived with its own cache — requests would be sent from each. Probably, to avoid this, the Next.js team redesigned fetch — now it works with a common cache.

The package solves the problem in the same way — it creates a common cache and works from each process already with it. For this to work, you need to use withNextTranslation in next.config.js.

Conclusion

The solution turned out to be truly tailored to next.js — taking into account all its capabilities and problems. It also includes all the optimization capabilities provided by server components. The package is fully optimized for next.js, their concepts and views, which I fully share.

I faced the problem of translations and I had to make my own solution, which would work exactly as expected.

Despite the significant advantage in optimizations, the package is still inferior to large libraries in terms of translation capabilities. There is a lot of work ahead.

P.S. I will be grateful if you describe what you lacked in existing solutions or what functionality you consider most important.

Drag.

Drop.

Stream.

“We created Cloudup because we were disappointed with sharing services that took too much time for conversion, storage, management, and uploading — we just wanted to share anything, anytime.” — CloudUp team.

In this part, I want to talk about the history and reasons for creating the service and what came out of it.

History of Vercel

1. History of Vercel. Annotation;
2. History of Vercel (1/7). 1990–2009. Guillermo Rauch. Childhood and first steps in programming;
3. History of Vercel (2/7). LearnBoost. A leading tech company;
4. History of Vercel (3/7). 2009–2013. LearnBoost. Team that has become a leader in open source;
5. History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream;
6. History of Vercel 2013–2015 (5/7). Automattic;
7. History of Vercel 2015–2020 (6/7). Zeit and Next.js;
8. History of Vercel 2020-Present (7/7). Zeit is now Vercel.

Reasons

The LearnBoost educational platform, Guillermo Rauch’s first startup, had already become popular and secured its place in the market by this time. It was a simple, convenient and fast service that solved all problems related to education. However, the interests and needs of teachers did not end there — they wanted to share their work, publish lesson plans, share photos from lessons in blogs, and talk about their work on social networks.

The LearnBoost development team also shared a large amount of information — images, videos, documents, presentations — for personal or work purposes. Different tools were used for each task.

LearnBoost users needed a tool that would allow them to share files with all network users. In existing solutions, you had to log in to view the file. Another disadvantage was the lack of cross-browser compatibility.

Competition

CloudUp was not the first to enter the market in this area. By that time, there were already startups in the data storage sphere (WeTransfers and YouSendIts), big players (Google Drive and Dropbox), and even social networks (Facebook, Twitter) were quite good at this task. Nevertheless, the goal of CloudUp was slightly different — not just to store files, but also to share them. But there were competitors at that time also — DropLr, CloudApp, Ge.tt.

The most advanced service at that time was Dropbox, but its main task was (and remains to this day) data storage, not file sharing and distribution.

On June 20, 2013, Guillermo and Tian Lu announced the creation of a new file-sharing service — CloudUp. From the LearnBoost team, TJ, Meredith, and Nathan also participated in the development of cloudup.

Tasks

The main goal was to make the sharing of images, links, videos, code, documents, and everything else — simple and beautiful, both for service users and for those with whom these users share.

To do this, the following tasks needed to be solved:

• Cross-browser compatibility The service should be accessible from any device, with any OS and from any browser. The problem of video format support added complexity.
• Grouping It was necessary to save files not in one endless list, but to make it possible to group them into categories.
• Viewing without registration To simply view photos, it was not necessary to register on the service. As viewing is possible without registration, functionality for secure file sharing was needed.
• Editing It was necessary to edit, change, delete or hide already uploaded files.
• Speed For viewing files and videos, it was not necessary to wait for their full upload.

Functionality

Drag. Drop. Stream. Three simple steps for files to take a huge path from the user’s device to viewers.

The service absorbed all the experience accumulated by the team, was built on modern technologies (many of which were created and developed by the LearnBoost team itself), a minimalist design was created for it. But this was not enough to stand out among the existing giants and become a market leader. The service needed to stand out, improve all existing solutions, and create new ones.

Cross-platform and cross-browser compatibility

Google Chrome only surpassed IE in popularity in 2012. By the time of the CloudUp launch (June 2013), cross-browser compatibility was a big and important task. In addition to directly supporting all browsers, the service also solved the problem of file format support. The service converted documents into PDF, performed video transcoding, and compressed images for devices with weak internet connections.

Grouping and preview

Existing alternatives displayed folders in a “list” format, CloudUp did so in a “tile” format and called this not folders, but streams. Streams differed from folders not only in their display style but also in their content.

In the “folders” of competitors, files were stored as a list, with basic icons. Streams, on the other hand, contained tiles with files that allowed you to see all the content in preview mode, be it a document, photo, file, or video. Thus, in these streams, you could easily and quickly find the necessary files. This worked with a really long list of files, whether they were simple documents, raw photos, or even psd, eps, and AI files, preview was available for everything.

Also, directly from the service, you could view the meta-information about the file, such as weight, extension, creation date, resolution, and much more.

Editing and security

Each stream was assigned a unique identifier that could not be forged or predicted, so the only way to view a specific stream was to get a link. For additional stream protection, it could be password-protected.

At any time, the file could be edited, replaced, password added or removed, or deleted.

Speed

One of the main features of LearnBoost was real-time operation. The company that created the first library for these purposes — socket.io was a leader in this area. The next startup was no exception, all files were uploaded and available in real time. As soon as the user started uploading files, a link would be immediately available to him, which he could share with his friends. The upload did not occur as a whole file, but as a stream, which was a significant advantage, primarily for video.

Also, the product followed the ideas of web 2.0, that is, it was a single-page application. https://cloudup.com/blog/the-need-for-speed

Application

Along with the presentation of the service, an application for it was immediately presented. Initially only for OSX, but in the near future, apps for other platforms were planned.

In addition to the main functionality, the application could also:

• Automatically upload all screenshots taken to the service;
• Upload by transferring the necessary files to the CloudUp icon in the status bar. The link to the created stream was immediately copied to the clipboard and it could be immediately shared with friends or colleagues.

And these promises were kept. Almost immediately after the launch, a Windows application was presented.

The application could also track screenshots and automatically upload them.

Result

On June 20, 2013, the service launched pre-registration. The service offered users 1000 files up to 200MB each for free. In early September, the service launched in beta testing and sent out 10,000 invitations. In just a few weeks, users uploaded over 300,000 files, the total volume of which was almost 1,500 GB.

CloudUp quickly and confidently entered the market for cloud solutions, but to secure a strong position in it, the team had to do a lot of work. The service had a huge and unique functionality, which favorably distinguished it from competitors, but this was not enough for establishment. The next step was to consider monetization.

The free tariff provided for the upload of up to 1000 files, which was enough for an ordinary user. For business, special tariffs, applications for all platforms, and collaborative work on files in real time were needed. The company continuously improved its applications, the performance of the service, supported file formats, thereby gradually closing all market needs.

The first company to fully switch to CloudUp for internal purposes was The Lift, on August 12, 2013 (one and a half months later). theLift was engaged in product development from concept to product, from software development to the creation of marketing materials. The company’s headquarters were located in Southern California, and there was also an office in Buenos Aires.

The second company was Sawhorse. Sawhorse is a full-service production company helping startups and large companies share their stories through video and post-production campaigns. This, perhaps, was the first company well familiar with the product and the team, as they made the introductory video for CloudUp.

Also, CloudUp launched a “scaling program” — a referral program, so that users could invite their friends to the service.

History of Vercel (4/7). 2013. Cloudup. Drag. Drop. Stream. was originally published in History of Vercel on Medium, where people are continuing the conversation by highlighting and responding to this story.