DEV Community: Oles Maiboroda

Stale-while-revalidate and it's usage with Next.js

Oles Maiboroda — Thu, 22 Aug 2024 16:18:36 +0000

Stale while revalidate (SWR) is an established pattern for quick data display while refreshing data in the background. It is popularised by SWR library https://www.npmjs.com/package/swr, but it roots comes from HTTP spec

Example:

Cache-Control: max-age=600, stale-while-revalidate=30, stale-while-error=30

This pattern fits well for content that doesn't update often like blogs, static pages, etc.

SWR in Next.js

Next.js promotes ISR, which is an alternative to SWR. SWR is not supported in Vercel CDN, and this is the reason you might want to pull out from Vercel.

Next.js itself requires some configuration.

SWR delta

To make SWR work in Next.js, you'd need to specify swrDelta in next.config.js, which is available from next@14

experimental: {
 swrDelta: 31536000,
}

This is the value, for how long does server considers the content stale and responds immediately to it. It is a common pattern to have this value high (ie 1 year), so at any point, we can react quickly and prefetch the latest content in the background.

It's essentially our stale-while-revalidate value in seconds.

Max-age

This value specifies how long the server would respond without even checking the origin server.

In next.js, it is set via the revalidate constant, as with ISR.

export const revalidate = 3600;

It's essentially our max-age value in seconds.

As you can't modify cache-control in next.js, this is the only way to set the value.

This value is relatively short 1 hour to 1 day, depending on how active development is - in case of new features or bugfixes you still want to deliver quickly and propagate the changes.

With stale-while-revalidate you can afford not to invalidate the CDN cache on redeploy! After redeploying, your changes will propagate in max-age time (ie 1hr).

Boosting with CDN

As abovementioned, Vercel doesn't support SWR, so there are some popular alternatives:

Fastly: supports SWR ✅ https://www.fastly.com/blog/stale-while-revalidate-stale-if-error-available-today/

Cloudflare doesn't support SWR ❌ https://community.cloudflare.com/t/support-for-stale-while-revalidate/496788

Cloudfront: supports since 2023 ✅ https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-cloudfront-stale-while-revalidate-stale-if-error-cache-control-directives/

Example on Cloudfront

No setup is required, as CDN either recognizes headers from origin or not and just respects the instructions in cache control.

Let's check now the first visit and response from Cloudfront:

x-cache: Miss from cloudfront
ttfb: 0.332219

Subsequent visit:

age: 642
x-cache: Hit from cloudfront
ttfb: 0.066109

Visit when content is considered stale:

age: 4001
x-cache: RefreshHit from cloudfront
ttfb: 0.024514

With RefreshHit Cloudfront responds immediately and makes call to the origin server asynchronously.

Vercel Doesn’t Want You to Pull Out

Oles Maiboroda — Tue, 06 Aug 2024 17:31:14 +0000

I have been working with Vercel for years and love it, although it's started to frustrate me over the last few months. Here are some points that made us decide to pull out, even though Vercel doesn't want you to.

Struggles with Vercel

Weird CDN

The TTFB occasionally hiccups to 250ms+. These requests were responding x-vercel-cache: HIT, and it's the same page. This slow, which is quite weird.

Looks like CDN goes to origin, yet still responds with HIT

Overwhelming of pay-per-request

I know it's the essence of SaaS, but it's overwhelming how many items you can be billed for, including horror stories.

As for the latest changes, Vercel is rolling out Data Cache (which is a great feature), starting to bill it, and changing the default data cache policy from cache-all to no-cache between Next.js 14 and Next.js 15. This doesn't contribute to my confidence.

Overwheling amount of billing parameters at vercel.com

Support has not been great

I have submitted three support requests over the last few months (a bug in log drain exports, elaboration on data/deployment cache), and none of them were satisfactory. After message ping-pong on every ticket, being responded to by multiple support engineers, I just gave up on my hopes of being helped. At some point, I see that further discussion is pointless and close the ticket. I hope this is not a support strategy!

Logs filtering DX

Personally, I find the Logs tab in Vercel confusing, with limited capabilities to filter and occasional very similar records going side-by-side.

What if we self-host?

All these points led us to pull out from Vercel and self-host Next.js. But it's not amazing - Cache-Control header is optimized only for Vercel.

Cache-Control headers are locked-in

You simply cannot set Cache-Control header on pages. Next.js locks them in for you, saying they know what's best—optimizing for deployment on Vercel:

Cache-Control headers set in next.config.js will be overwritten in production to ensure that static assets can be cached effectively.

For ISR, default max-age is one year

Next.js casually sets a one-year(!) cache for your HTML if you don't explicitly specify the revalidate value.

stale-while-revalidate was introduced not per spec until Next.js 14

stale-while-revalidate directive was provided without a value. This led to incompatibility with other CDNs—only Vercel could understand it.

Can we?

We have managed to overcome this and moved to self-hosting, SWR, and Cloudfront - a setup which I will share soon.

Guide to Side effects in Hasura

Oles Maiboroda — Tue, 14 Mar 2023 08:04:37 +0000

When dealing with Hasura, it can quickly come to the side-effects of doing something less trivial than using only predefined upserts/inserts.

Most often, this comes to operations with databases, calling external API, or doing hefty validations.

Hasura offers multiple ways of achieving it, though these methods have their own advantages and use cases, here are them:

Postgres triggers

Hasura heavily relies on the database functionality, and in the case of Postgres, there is a possibility to achieve desired functionality with Postgres functions and triggers.

CREATE OR REPLACE FUNCTION insert_initial_album() RETURNS TRIGGER LANGUAGE PLPGSQL AS $function$
    BEGIN
      INSERT into album (artist_id, title) VALUES (new.id, 'first album');
      RETURN new;
    END;
    $function$;


CREATE TRIGGER artist_after_insert AFTER
  INSERT ON artist
  FOR EACH ROW EXECUTE PROCEDURE insert_initial_album();

It is also possible to write validations on a Database-level

Pros: powerful flexibility, database-native functionality.
Cons: calling a 3rd-party API is impossible. Maintainance and visibility of Functions and Triggers can be a hassle.

When to use: you are good with SQL, a believer in "you don't need an ORM".
When to avoid: at large projects where observability of SQL can be an issue. SQL is not your strength.

Multiple Mutations in a Request

Given there's a relationship established in Hasura, there's a possibility to modify nested objects, for example:

mutation {
    insert_album(objects: {title: "First album", artist: {data: {name: "Bono"}}}) {
        returning {
            id
            artist {
              id
            }
        }
    }
}

This way, Hasura would create Album and Artist, and assign artist_id to the newly created Artist

Pros: out-of-the-box functionality, single transaction.
Cons: lacking flexibility, if required to do more business logic on top.

When to use: fits your simple use-case.
When to avoid: rarely, if it does solve the problem - use it!

Event Triggers

Another option is an Event trigger - webhook reaction on a database change

Creating an Event Trigger

Pros: out-of-the-box functionality, ability to subscribe for particular CRUD events.
Cons: it's not a transaction.

When to use: effects, that doesn't require integrity, for instance: analytics update, sending emails, notifications.
When to avoid: no atomicity - operations are executed separately.

Hasura Actions

Actions is a mechanism for customizations, where custom queries or mutations can be implemented in webhook:

Creating new Hasura Action

This action would instruct Hasura to invoke handler:

Example of webhook handler

Pros: programming language runtime, flexibility, ability to do 3rd-party calls, and access to Database.
Cons: cumbersome to set up handlers, types for every action needed.

When to use: you have to do a few manual operations, and you have a server in place (ie next) that can handle the requests.
When to avoid: you need lots of side effects (then add Remote schema) or when it's possible to use the abovementioned solutions.

Remote schema

Remote schema is a variation on Actions, but you bring your own additional Graphql Schema. Adding it to Hasura, will extend existing Schema with Queries/Mutations where you have full control.

Creating new Remote Schema

Pros: easy integration with Hasura.
Cons: you'd need to maintain your own GraphQL Server.

When to use: you already have a GQL server, or the application demands lots of non-trivial code.
When to avoid: your app is small and doesn't require a standalone GQL server.

Summary

These were 5 ways of achieving similar results in Hasura:

Postgres triggers
Multiple Mutations in a Request
Hasura Actions
Event Triggers
Remote schema

Each of them has its strengths and weaknesses, and you can use them successfully in combination.
Hope this was helpful to pick the ones that suit you the best.

Shorten your feedback loop

Oles Maiboroda — Fri, 18 Dec 2020 17:08:44 +0000

One of the key satisfiers in the development experience is knowing the results of your actions immediately.
That's why apart from the constant aim of simplifying everything as a software developer, there can be an aim of a constant shortening the feedback loop.

A short feedback loop is a fundamental idea in some core programming practices, such as TDD.

In the perspective of frontend development, here's what you can consider:

1. Shorten UI feedback during development.

Pay attention to the time it takes between the UI change in development mode and its reflection in the browser.
Ensure you're leveraging react-refresh and use proper webpack devtool config if you're on this ecosystem.

2. Know how to simulate the state of the app, i.e. to stay on the same page on refresh during development.

With the growing complexity of the application, the number of states, in which this application can is growing as well.
It is worth to consider a mechanism for state simulation, like make your own dev tools
so you can quickly jump to a certain app state, and/or stay in it during development.

3. Know how to Deploy the application on the test environment from your local machine.

Depending on your setup, this can save you from running build or test steps on CI just to quickly check some ideas.
Even better: know how to simulate the test environment locally.

4. Know how to run and scope tests locally.

Rather than waiting on CI to check if the tests are green, know how to run your unit/integration tests and scope them to certain files/suits for faster outcomes.

5. Know how to test things without redeploying the app.

Sometimes, to validate ideas, there's no need to deploy the app on a test environment - leverage browsers' devtools features like blocking API requests or local overrides. This way you got some answers to your questions immediately.

6. Ensure IDE assists you.

Seeing fast lint-check or type-check errors right in IDE gives you great (probably the fastest) feedback about potential problems. Make sure your lint & type-check solutions are integrated tightly with the IDE.

For a delightful developer experience, speed of ideas validation is a key player for your mental health and sometimes sets the mood for the whole day. Make "shorten your feedback loop" a motto for your setups, don't be lazy to think about how can you validate ideas faster and enjoy your work even more.

Try to update your dependencies with Renovate or Dependabot

Oles Maiboroda — Tue, 08 Dec 2020 17:06:32 +0000

Keeping dependencies up-to-date is an important part of healthy projects, but often overlooked in Frontend (due to a lower security risk?) compared to backend or infrastructure.

Having the latest versions of libraries gives you and your teammates

Security confidence
Performance optimizations
Bugfixes
Access to latest features & new APIs

Often though, its importance is overlooked, which may lead up to critical level problems, when the project cannot work in the required environment (new browsers, or new requirements from app stores in case of mobile application).

Dependency update strategy though may vary according to the size of your team, kind of the product you're working on, etc. In some larger companies, there can be also special departments and private repositories for dependencies.

Working in a middle-sized team of developers (and non-health/wealth risk projects) we have tried 2 approaches for the updates.

Per library, live updates

First what comes to mind is Dependabot, now a "native" solution from Github. Dependabot will open PRs once a new version of the library is in.

How to enable: visit app.dependabot.com and select repositories you want to add.

Pricing: free of charge.

Once enabled, Dependabot will start to open PRs for new versions.

dependabot in Pull requests tab

Dependabot will open PRs with the following contents

dependabot's Pull request description

Batch update, once a month

Soon we've realized live updates per library are too verbose.
In the case of Dependabot there was no chance to set up PRs to be open only for major updates, therefore another attempt with Renovate:

How to enable: visit renovatebot.com and select repositories you want to add.
Pricing: free of charge.

It is possible to ask Renovatebot to open batch PR once a month

renovate in Pull requests tab

With the following configuration, Renovate will open monthly PR with the following contents

renovate's Pull request description

Here's renovate.json configuration we settled:

{
  "extends": [
    "config:base",
    "group:all",
    // Regular updates
    "schedule:monthly"
  ],
  // Random assignee of PR
  "assigneesFromCodeOwners": true,
  "assigneesSampleSize": 1,
  "separateMinorPatch": true,
  "packageRules": [
    {
      // Only major and minor updates
      "updateTypes": ["patch"],
      "enabled": false
    }
  ],
  // Encrypted NPM token for private packages
  "encrypted": {
    "npmToken": "w/0FYXCXO1aYkUeivEFbB7yG/CPM4xC2ksGVLLua0rNMYyEF8bxlrYqMtJqriuG53oecATlrSzgh06/U3sYkA2ZNgHabyoinZWc+fI0rchCCgSH0EXIeRifZH+nRNY69e5EleMOT0wNrkYlSuWN0U0uOU53ZZB+bojKPEpWhULZTOC6nXsN5WOrYdP0T1Tw=="
  }
}

Some other recommendations for the deps updates duties:

Find a balance so updates are regular, but not too verbose.
Random assign update PR to one of the contributors.
Check libraries that got a major update for new APIs and features.
Write update log, if some libraries were impossible to update.

Frontend 360

Oles Maiboroda — Sun, 28 Jul 2019 13:42:59 +0000

Originally posted at https://oles.dev/posts/frontend-360

I needed to organize my thoughts on Frontend so I've ended up with a mindmap that I've ambitiously named as Frontend 360.
The system can help you to evaluate the state of the projects and point to the strengths and weaknesses.

Mindmap can be categorized into 3 subcategories - Peers, Self and Users

Peers

Areas of Frontend Peers

Frontend cannot live in the vacuum itself. As a touchpoint with the customers, it has interdependencies with other domains.
The Peers category relates to the domains relative to the Frontend - Testing, DevOps, Backend, Design, Content, Marketing

How fast the project builds and how easy are deploys?
Does the application has enough test coverage to prevent bugs?
Is the bad API decisions leak into Frontend?
Is the UI/UX you have in the application is consistent?
Are the translation/content mechanisms pleasure to work with?
Are the user tracking reports error-free?

Self

Areas of Frontend itself

The second section relates to ourselves, Frontend code maintainers with covering following domains - Code, Documentation, Monitoring

Does codebase has decent documentation?
Are there any JS errors on production?
How do you react on performance regressions?
How big is the technical debt?
Are all our dependencies up-to-date?

Users

The last, but not least - Frontend from user's perspective - Accessibility, Performance, Security

Is the service you provide is inclusive?
Is the speed in your app is a UX bottleneck?
Is our users' data and your application secure?

Areas of users

All together

These questions and sections can build a good picture of the state of Frontend

All these aspects are important to keep a healthy project that will bring the joy to work with for you, your peers and your users.

During PR review - do you check in into the branch?

Oles Maiboroda — Sat, 27 Jul 2019 16:02:16 +0000

Have found a very fundamental post on Code review https://charcoalbin.com/posts/code-review.html where Authour states that it is needed to check the functionality of PR.

Usability Test
Confirm if the PR achieves its goal, visually and functionally.

I have thought about this idea, but actually never tried, mostly because of time.
Do some of you follow it, what's your perspective?

Why I love Frontend: two triangles

Oles Maiboroda — Tue, 19 Feb 2019 21:41:20 +0000

The beauty of Frontend

Not much to add: the chance to work Product ⇆ Frontend ⇆ Design and Backend ⇆ Frontend ⇆ DevOps - that's what make our position unique.

Control the colors in your project

Oles Maiboroda — Fri, 08 Feb 2019 12:56:55 +0000

Sometimes you may face this kinds of projects:

Hard case, huh?

which bring you a little discomfort in the stomach. Today we'll talk about colors in particular and how they can be organized.

Audit

One of the great options is to use online tools, like cssstats.com

dev.to on cssstats.com

The issue with it that it shows only the colors that appear on the single page, so if you have code-splitting, some colors might be missing.
I had a need something that would just show the colors used in the source files, but there wasn't anything, so I had to write a small utility colors-in. It traverses the folder end extracts used colors:

Colors in src folder

Fix

Having this you can look at your the designs UI Kit or talk to your design to define the colors you're gonna use across the project.

At that point, we'd a need to "merge" similar colors and there's one approach you can do it. Since all colors are living in 3-dimensional Red, Green, Blue space, we can calculate the distance between them:

Euclidean distance

From my empirical feeling, those colors that are having less than 10% color difference can be deprecated in favor of more often used in a pair.

Difference between two shades of gray with npmjs.com/package/color-difference

Other things you can do:

Unify color format to hex;
Agree on 6 digits hex format;
Remove unnecessary opacity layer;

In our case we were able to reduce the number of unique color definitions from 29 to 14:
Before:

29 color definitions

After:

14 color definitions

So if you have that "zoo" - make an Audit. Or if you keep your colors in an organized way - check if you forgot to use it somewhere else with >colors-in src;

Editing web translations right in your browser

Oles Maiboroda — Wed, 09 Jan 2019 20:28:12 +0000

Sometimes GIF replaces 1000 words:

looks interesting, right?

DEMO

Having this, you give your translator 100% understanding of the translation context.

The feature is usually called In-Context Editor (for instance in Locize or Phraseapp).

It's worth to say you need PhraseApp Pro subscription for it. In pair to that, we also use lingui-js as a translation library.

How to enable

All you need to is

Add PhraseApp In-Context Editor snippet to your page
Format messages into the proper format.

If you're in the Javascript world, I have wrote a lingui-phraseapp, which helps you to do these two steps, so your integration may look alike

import { initializePhraseAppEditor, initializePhraseAppEditor } from "lingui-phraseapp";
import catalog from './locales/de/messages.js';

const configInContextEditor = {
  projectId: REACT_APP_PHRASEAPP_PROJECT_ID,
  autoLowercase: false,
  prefix: "--__",
  suffix: "__--",
  phraseEnabled: !!localStorage.getItem("inContextEditor");
};

...
<!-- Add snippet -->
initializePhraseAppEditor(configInContextEditor);

<!-- Format messages -->
const catalogFormatted = configInContextEditor.phraseEnabled
  ? transformCatalog(catalog, configInContextEditor)
  : catalog;

const i18n = setupI18n({ catalogs: { de: catalogFormatted });
...

As you can see from above to enable Editor set inContextEditor: true in the LocalStorage. After that, the modal for username and password will appear.

There are also implementations for other popular translation libraries react-intl-phraseapp, react-i18next-phraseapp, although integration itself is pretty straightforward and simple.

The most important question

Now to the things that really matter:

Does this brings value at all?

The translator we're working says she wanted it for 2 years, although we haven't started active translation phase yet. And you can't say for sure until you'll work with it on daily basis.

I will give an update on this feature, stay tuned!

Three ways to name i18n translation keys

Oles Maiboroda — Fri, 04 Jan 2019 16:44:55 +0000

Teams do internationalization of applications either from the very beginning or after delivering a primary language. Usually, the translation flow looks similar to the following:

Translation flow

And from a developer perspective, it contains 3 steps:

Receive content from designs, create keys and populate initial "en" translation;
Announce keys to translators;
Occasionally fetch latest translations.

It is pretty easy to create translation keys, but hard to do it in a way that it

Makes clear for translators what do they mean;
Makes clear for developers what do they mean;
Is looking good in source files;
Avoids often context switching between translation files and sources;
Helps developers to map code blocks with "physical" representations on the page.

There are already good i18n guidelines written by Phraseapp and MDN, but they do not answer how should we name the translation keys themselves.

To abstract from implementation, we'll agree on translation function t, which takes a translation key and returns message:

t('things') // => "How things work"

Option 1 - Interesting

You might have only custom defined keys, without defaults. For instance:

t('landing_page.how_things_work') // => "How things work"

As for the initial translation, there will be a need to add initial messages to a translation file.

Pros

Doesn't take much space in source files
Gives enough context to a translator
Ready to change over time

Cons

In case if the key is too generic hard to track the relationship between the source and actual place of display on the page
To set the initial message, you would need to switch from sources to the translation file

Option 2 - Bulletproof

You can specify both - translation key and default message:

t({
  key: 'landing_page.how_things_work', 
  defaultMessage: "Things explained"
}) // => "How things work"

Pros

Flexible - you can change your default message without being afraid it will cause issues;
You have a connection between sources and actual visual representation.

Cons

May face duplication in short keys, for example t({ key: 'general.errors.empty', defaultMessage: 'empty'});
Bloats sources size with the id and message.

Option 3 - Straightforward.

You can use the same text as your message in English:

t('How things work') // => "How things work"

This way we're eliminating the necessity to maintain default messages and create keys for them.

Pros

Developers maintain single entity;
Gives translator instant clarity what should be translated;
You can use them as default messages.

Cons

It worth to add more context for a translator. This can be hints to the source code's filename (as in .po format) or in-context-editor;
Sometimes you have to translate entire paragraphs, which make key too long;
Requires extra solution for those English words, which have multiple meanings i.e. to cry.

As you might already understand, there's no 100% correct to define the translation keys and the decision should be made based on your project size, how often you change translations and team preference.

At the current project, we've decided to give a shot for "#3 Straightforward" approach for sake of simplicity, ease of maintenance and less context switching.

But how do you cook i18n keys?