Forem: Alex Barashkov

Things you might not know about Next Image

Alex Barashkov — Thu, 22 Jun 2023 13:31:19 +0000

If you've worked with Next.js, it's likely that you've come across Next Image component. This hassle-free image optimization solution not only provides support for modern formats such as webp and avif but also generates multiple versions tailored to different screen sizes.

To leverage this magic, simply add the following code to your page:

import Image from 'next/image';

export default function Page() {
  return (
    <Image
      src="/profile.png"
      width={500}
      height={500}
      alt="Picture of the author"
    />
  );
}

However, as is the case with any magic, there's a solid foundation of hard work that enables it to function seamlessly. In this article, we're going to explore how Next Image works and clear up some common misconceptions surrounding it.

I write content about web architecture and frameworks. Follow me on Twitter to stay up to date.

Core Architecture

The underlying architecture of next/image is primarily made up of three components:

React Next Image Component
Image API
Image Optimizer

React Component

The primary function of the component is to generate the correct HTML image output based on the provided properties and to construct multiple URLs to be populated in the srcset and src attributes. Here is an example output from the Next Image component:

<img 
  alt="Example"
  loading="lazy" 
  width="500" 
  height="500" 
  decoding="async" 
  data-nimg="1" 
  style="color:transparent" 
  srcset="/_next/image?url=%2Fimages%2Fexample.jpg&amp;w=640&amp;q=75 1x, 
      /_next/image?url=%2Fimages%2Fexample.jpg&amp;w=1080&amp;q=75 2x" 
  src="/_next/image?url=%2Fimages%2Fexample.jpg&amp;w=1080&amp;q=75"
>

Let's take a closer look at the generated URL:

/_next/image?url=/images/example.jpg&w=640&q=75

This encoded URL accepts two parameters: w (width) and q (quality), which are more visible in the decoded version. You can spot that there is no h (height) attribute, but about that we will talk later in the article.

Image API

The Next Image API serves as an image proxy, similar to IPX. It performs the following tasks:

Accepts an image URL, width, and quality
Validates parameters
Determines cache control policies
Processes the image
Serves the image in a format supported by the user's browser

As things begin to make more sense, let's briefly discuss the final piece of the puzzle before we draw some conclusions from this arrangement.

Image Optimizer

Next Image utilizes different image optimization libraries - Sharp or Squoosh - depending on certain conditions:

Sharp is a fast and efficient image optimization Node.js module that makes use of the native libvips library.

Squoosh is a fully node-based image optimization solution. It's slower, but it doesn't require any additional libraries to be installed on a machine. For this reason, Sharp is recommended for production use, whereas Squoosh is used by default in local environments.

I advise using Sharp in local environments as well. While both Sharp and Squoosh optimize images quite similarly, Sharp's compression algorithms can lead to color degradation compared to Squoosh. This can result in visually different behavior between production and local environments, particularly when trying to match the background color of an image with the page background.

Outcomes

Having understood the primary architecture behind next/image, we can debunk common misconceptions and glean more insights on how to utilize it more effectively.

next/image does not crop

A common misconception among developers is that next/image can crop their images. This confusion arises because you can pass width, height, and fill properties to the component, creating an impression that the image has been cropped. In reality, this isn't the case. The Next Image component primarily requires width and height for assigning to the img tag to prevent layout shifts.

As we've already discussed, the Image API does not accept a height parameter, meaning it currently isn't possible to change the original image's aspect ratio. If you don't use the fill property, the image will merely stretch or shrink in the event of width-height mismatches.

However, if you're using TailwindCSS, it behaves differently due to its default global CSS rule:

img,
video {
  max-width: 100%;
  height: auto;
}

This makes layout shift issues harder to detect.

Displayed image width ≠ loaded image width

Another potential point of confusion is that the width property passed to next/image doesn't represent the actual width to which the image will be resized. As we noted from the example at the start of the article, passing width={500} to a component will result in the image being resized to a width of 640px, as evident in the generated URL:

/_next/image?url=/images/example.jpg&w=640&q=75

If you expect the x2 retina version to utilize an image width of 1000px or 1280px, you're in for a surprise. The actual width used will be 1080px. Naturally, you might wonder where these numbers are coming from.

Next.js resizes images to the closest size from an array ofdeviceSizes and imageSizes that you can define in next.config.js. By default, these are:

module.exports = {
  images: {
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
  },
};

What's crucial to note here is that using the default configuration can negatively impact performance, leading to a reduced score in Lighthouse's Page Speed Insights. This becomes particularly evident when you attempt to display large images on a page. For instance, if you want to render an image with a width of 1250px, the actual loaded image width will be 1920px. The discrepancy between the required size and the actual loaded size becomes even greater for x2 retina versions, as these will be resized to 3840px. However, you can remedy this by adding more sizes to the deviceSizes or imageSizes arrays(docs).

Image optimization can be used without the next/image component

With an understanding of the core architecture, it's easy to see that you can use the Image API without necessarily using next/image. There are several scenarios in which this can be beneficial.

First, you can render optimized images inside a canvas. Regardless of whether you're loading images onto a canvas from external sources or from local storage, you can pass the correct URL to the API and have it work seamlessly.

Additionally, you can use it to optimize OG images or create your own <picture> tag-based component for better art direction.

The Image API is located under the /_next/image route and accepts just three additional parameters: URL, width (w), and quality (q).

/_next/image?url=https://example.com/test.jpg&w=640&q=75

Remember, the width parameter is checked by the API and can only be a number sourced from either the deviceSizes or imageSizes configuration.

Use import for local images

With next/image, there are two methods you can use to load local images:

import Image from 'next/image';
import profileImg from './profile.jpg';

export default function Page() {
  return (
    <>
      {/* Using absolute path */}
      <Image src="/profile.png" width={500} height={500} alt="Picture of the author" />
      {/* Using imported image via relative path */}
      <Image src={profileImg} alt="Picture of the author" />
    </>
  );
}

Using an absolute path is common when dealing with local images in examples, tutorials, or even open-source projects. It's easy to assume that there's no significant difference aside from the automatic width/height assignment. However, there is a difference. When you access images by an absolute path from a public folder, Next.js adheres to the cache policies of the destination server, which by default results in a 30-day cache policy rather than public,max-age=31536000,immutable. Using a 30-day cache policy for image assets can significantly lower your Lighthouse score.

Understanding Sizes and the 100vw Technique

The next/image component accepts a property known as 'sizes', akin to the html img sizes attribute. However, in line with other aspects we've discussed, it performs some unique operations too. The 'sizes' attribute works in concert with 'srcset' and accepts a list of browser conditions and image widths for which they should be activated. If you're unfamiliar with this, I recommend taking a look at these docs, and this codesandbox example. Here's an example of an image using 'sizes':

<img srcset="/img/html/vangogh-sm.jpg 120w,
             /img/html/vangogh.jpg 193w,
             /img/html/vangogh-lg.jpg 278w"
     sizes="(max-width: 710px) 120px,
            (max-width: 991px) 193px,
            278px">

Let's dive into the details for better understanding. When you utilize Next Image without specifying the 'sizes' property, your 'srcset' will include two URLs: one for the standard version (x1) and another for the Retina version (x2). With this setup, the browser will invariably opt for the Retina version when used on a Retina device. This preference arises due to the use of 1x and 2x syntax within the 'srcset'.

<img
  srcset="
    /_next/image?url=%2Fimages%2Fexample.jpg&amp;w=640&amp;q=75  1x,
    /_next/image?url=%2Fimages%2Fexample.jpg&amp;w=1080&amp;q=75 2x
  "
/>

The browser essentially interprets this as: "Load this URL for 2x pixel density, and this other one for 1x pixel density." Thus, if you have a design where the image version on desktop is smaller than on mobile or tablet, the browser will consistently load the larger version with the default Next Image syntax. Unfortunately, this could result in suboptimal performance and a lower Lighthouse score.

There is, however, a method to instruct the browser to load images based on suitable width. Instead of providing 1x, 2x parameters to the 'srcset' URL, you specify the width of the image. For example, check these instructions to the browser:

<img
  srcset="
    /_next/image?url=%2Fimages%2Fexample.jpg&amp;w=640&amp;q=75   640w,
    /_next/image?url=%2Fimages%2Fexample.jpg&amp;w=1080&amp;q=75 1080w
  "
/>

In this case, the browser selects the most appropriate image for the current size used on the page. If a mobile image has a width of 600px (1200px for Retina), it will choose the 1080w version. Meanwhile, if a desktop image only uses 300px (600px for Retina), the browser opts for 640w.

The advantage of this approach lies in loading the most fitting images for the current screen size, thereby enhancing performance due to reduced image size. Now that we understand the benefits, we can apply this strategy with Next Image using the 100vw trick. While you cannot directly instruct Next Image to use the width (w) parameters near the URL instead of pixel-density (1x) options, you can apply a workaround arising from how Next Image is coded:

If your 'sizes' attribute contains vw numbers, it will only keep those sizes larger than the smallest deviceSize (640 by default) multiplied by the percentage(100vw = 1, 50vw = 0.5). Specifying 100vw, you will end up with 8 URLs.
If your 'sizes' property has non-vw numbers, your 'srcset' will contain ALL SIZES (i.e., all possible combinations of deviceSizes and imageSizes), yielding a total of 16 URLs.

To illustrate, let's examine the generated code for 100vw:

<img
  sizes="100vw"
  srcset="
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=640&amp;q=75   640w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=750&amp;q=75   750w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=828&amp;q=75   828w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=1080&amp;q=75 1080w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=1200&amp;q=75 1200w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=1920&amp;q=75 1920w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=2048&amp;q=75 2048w,
    /_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=3840&amp;q=75 3840w
  "
  src="/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fexample.6be618a3.jpg&amp;w=3840&amp;q=75"
/>

If you include a px value within 'sizes'(eg. (max-width: 1024px) 800px, 300px), the list of URLs expands even further, reaching 16 in a default configuration. Ideally, I would prefer to generate 4 URLs for a specific image, similar to other frameworks, rather than bloating the HTML with many unnecessary options, none of which may be perfectly sized for my needs.

This discussion underscores a key point: to populate 'srcset' with more versions for better performance across a variety of resolutions, you can simply set 'sizes' to 100vw. This trick forces the creation of URLs for 8 sizes, starting from 640px.

However, because this method can easily inflate your HTML size - especially if you've added extra imageSizes or deviceSizes - it's recommended to apply this approach carefully.

While I can only speculate about the exact reasoning behind this architecture, I assume that for large-scale projects with various image ratios used in many different places, this approach of generating average-sized versions might prove beneficial. These versions could cater to most scenarios and potentially hit the cache more frequently, all the while maintaining ease of use.

Conclusions

Though Next Image simplifies image management and provides significant advantages, it could benefit from additional features like advanced cropping and precise resizing, similar to third-party solutions. Incorporating a specialized component for fine-tuned art direction would also be advantageous. I'd particularly appreciate an automated method for generating four image versions at 0.25x, 0.5x, 1x, and 2x the supplied width.

Nevertheless, for most use cases, the developer experience and efficiency of Next Image will more than enough.

If you enjoyed the article and want to see more web tips, follow me on Twitter.

Use Google Analytics to uncover the truth about dark and light mode user's preferences

Alex Barashkov — Thu, 15 Dec 2022 12:00:50 +0000

Dark mode has become increasingly popular in recent years, as it can help reduce eyestrain and save battery life on devices. If you have a website or an app, you may want to track whether your users are using dark mode so that you can better understand their preferences and tailor your content accordingly.

To track the user's dark mode setting, we will use Google Analytics 4 (GA4) and Google Tag Manager (GTM). This process will include the configuration of GTM, the creation of a custom dimension in GA, and, finally, setting up a report for gained data.

Here are the steps to create a custom variable in GTM to track the user's dark and light theme setting:

In your GTM account, go to the "Variables" section and click on the "New" button.
On the "Create Variable" page, select "Custom JavaScript" as the variable type and name it “User Color Mode”.
In the "Custom JavaScript" field, enter a function that returns either "dark" or "light" depending on the user's dark mode setting.
Click on the "Save" button to save the custom variable.

  function () {
    if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) {
      return 'Dark';
    }
    else if (window.matchMedia && window.matchMedia('(prefers-color-scheme: light)').matches) {
      return 'Light';
    }
    return 'No Preference';
  }

Note: window.matchMedia('(prefers-color-scheme: dark)') shows user preference through an operating system setting (e.g., light or dark mode) or a user agent setting. If you want to track it based on the user’s selected option in your app, you can extend this approach by adding the GA user data programmatically.(GA docs)

Once you have created the custom variable in GTM to track the user's dark mode setting, you can create a custom tag in GTM that sends the data to GA4 as an event. To create a custom tag in GTM, follow these steps:

In your GTM account, go to the "Tags" section and click on the "New" button.
In the "Create Tag" page, select "Google Analytics: GA4 Event" as the tag type.
In the "Google Analytics Settings" section, select the correct GA4 property from the "Configuration Tag" dropdown. Make sure that you’ve selected the property that corresponds to your website or app.
In the "Event Parameters" section, enter the following values:
- Event name: "page_view"
- Event parameters: { "color_mode": {{User Color Mode}} }
Add trigger "Initialization - All pages"
Press "Save"

Now to see the results in Google Analytics(GA4) we need to add custom dimension. You can create a custom dimension named "User Color Mode" with a user property value of "color_mode." Here are the steps to do this:

Sign in to your Google Analytics account and navigate to the Configure section.
Click on Custom Definitions, then click on Custom Dimensions.
Click the "New Custom Dimension" button.
In the "Name" field, enter "User Color Mode" as the name of the custom dimension.
In the "Scope" field, select "User" as the scope for this custom dimension. This will allow the dimension to be associated with individual users of your website.
In the "Event Parameter" field, enter "color_mode" as the event parameter that will set the value of this custom dimension.
In the "Active" field, make sure you’ve checked the box to enable this custom dimension.
Click the "Create" button to save the new custom dimension.

Once you've set up, you can immediately view the statistics on the "Reports" → "Realtime" page. However, on other pages such as "Explore," you'll need to wait 24 hours before you can start using this new user property.

Summary

Now you know how to set up Google Analytics 4 and GTM in order to track the user’s dark or light theme setting. Analysis of this data can help you define whether it’s important to implement dark mode for the website or app for your audience.

If you enjoyed the article and want to see more web tips, follow me on Twitter.

Advanced web font optimization techniques

Alex Barashkov — Mon, 28 Nov 2022 15:21:29 +0000

Website developers have been using custom fonts for ages. Since custom fonts are not present in the OS, they need to load with the site and, therefore, need to load quickly and display consistently across platforms. Common examples include Google Web Fonts — a dedicated library of web-optimized fonts in the Web Open Font Format (WOFF2), which provides excellent compression to minimize size.

In practice, however, a Google Web Font is typically 20–30KB. If you multiply that by several different styles and weights, you can quickly get to 100–150KB for your site. Another catch with custom fonts is they cause a visible layout shift during page loading.

This article shares advanced techniques to make your site faster and create a better UX using web fonts.

Quick basics

Let’s quickly address some basics before we jump to advanced techniques. Here is a checklist of basic best practices you can follow:

Use Google Web Fonts whenever possible.
If you use a custom font try to pass it through Font squirrel for better compression and vertical baseline fixes.
Use WOFF2 if you manually embed a font. WOFF2 has a high adoption rate (over 97%) and provides much better compression than other formats.
Use <link rel="preload" href="/fonts/usual/usual-semi-bold.woff2" as="font" type="font/woff2" crossorigin="anonymous"> to prioritize the font in the HTTP queue. Learn more.
Make sure the font is cached with cache-control: public, max-age=31536000, immutable. If you use Vercel, Netlify, or Gatsby Cloud, you likely already have good cache policies.
Download and serve the font from the same CDN as your website. Again, you get this out of the box with Vercel, Netlify, and Gatsby Cloud.

Now let’s talk about advanced optimization

Here are a few things that will save some KB, make fonts look better, and improve the UX:

Fallback font size adjustments
Custom subsetting
Vertical baseline fixes

Fallback font metric adjustments

Using custom fonts that are not part of the OS has a tradeoff. Browsers do not know the parameters of a font until it has been loaded; until then, the browser uses a fallback font (e.g., Arial, Times New Roman) to calculate the size of elements that use text on the page. But once the font is loaded, the size is recalculated.

The difference can be huge, and layout shifts will become visible, especially on a slow connection.

This example compares two fonts—Times New Roman and a custom font called Usual. Both fonts have a font size of 16px and a line height of 1.2 but notice the difference in length they have for the same text.

Recently some new CSS properties to match fallback and custom font metrics have seen wide adoption.

ascent-override

descent-override

line-gap-override

This sounds great, but do you match them? Katie Hempenius and Kara Erickson on the Google Aurora team have created an algorithm for this, but it needs automated solutions to be its best. The Next.js team recently announced its support for this in the updated @next/font package in v13. Our team took the same approach and wrapped this algorithm in a CLI that generates CSS to adjust fallback font metrics; we call it Fontpie.

github.com/pixel-point/fontpie

This is very simple to use. Here’s an example command:

npx fontpie ./roboto-regular.woff2 --name Roboto

Entering this command will return the following CSS, which you can embed in your project no matter which framework or language it uses:

@font-face {
  font-family: 'Roboto';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('roboto-regular.woff2') format('woff2');
}

@font-face {
  font-family: 'Roboto Fallback';
  font-style: normal;
  font-weight: 400;
  src: local('Times New Roman');
  ascent-override: 84.57%;
  descent-override: 22.25%;
  line-gap-override: 0%;
  size-adjust: 109.71%;
}

html {
  font-family: 'Roboto', 'Roboto Fallback';
}

This CSS solution works like this: (1) we declare a new font face—Roboto, (2) then we declare another font face with the name “Roboto Fallback” that uses the local Times New Roman font but with applied metric adjustments. This will completely mitigate any layout shift.

As you can see in the image, Times New Roman with metric adjustments now takes the same amount of space as the Usual font.

This technique is compatible with all modern browsers except Safari.

Custom subsetting

This technique reduces the number of characters embedded in a font. Fonts typically have many more characters than you need for your project, so using a subset that only includes what you need can significantly reduce the font size.

Google Web Fonts have a nice API to create a font subset. As an example, we will take the font Space Grotesk. The Regular (400) font size is 15KB in WOFF2 format. An embedded link will look like this

<link href="https://fonts.googleapis.com/css2?family=Space+Grotesk&display=swap" rel="stylesheet" />

To define a subset, you just need to add an additional &text parameter to the URL; for example:

<link
  href="https://fonts.googleapis.com/css2?family=Space+Grotesk
&display=swap&text=HelloWorld"
  rel="stylesheet"
/>

This is particularly useful when you have a single “stylish” headline in a different font from the rest of the site. In that case, you can define a subset that only includes the characters for that headline. In the example above, custom subsetting reduced the font size to 1KB.

Screenshot below illustrates how characters will look like when the letter does not present in the subset.

Listed below are popular subsets you can copy/paste and insert into Google Web Font or Font Squirrel to get the exact set you want to use.

Popular subsets; copy/paste and edit them for your needs

Lower case

abcdefghijklmnopqrstuvwxyz

Upper case

ABCDEFGHIJKLMNOPQRSTUVWXYZ

Number

0123456789

Upper Accents

ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞßŒŸ

Lower Accents

àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿıœƒ

Alt punctuation

¡«»¿‚„‹›

Math Symbols

ª¬±µº÷Ωπ‰⁄∂∆∏∑√∞∫≈≠≤≥

Typographics

§©®°¶·†‡•™◊ﬁﬂ

Currency

$¢£¥ƒ€

Punctuation

!"#$%&amp;'()*+,-./:;&lt;=&gt;?@[\]^_`{|}~–—‘’“”…

Diacriticals

¨¯´¸ˆˇ˘˙˚˛˜˝

For example, the Space Grotesk subset defined below includes Upper case, Lower case, Numbers, Punctuation, and Currency, and the resulting font custom subset is only 6KB.

https://fonts.googleapis.com/css2?family=Space+Grotesk&display=swap&text=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!%22#$%&'()*+,-./:;%3C=%3E?@[\]^_%60{|}~%E2%80%93%E2%80%94%E2%80%98%E2%80%99%E2%80%9C%E2%80%9D%E2%80%A6$

Custom fonts subsetting

Things get worse if you use custom fonts, like those available in Adobe Fonts. Many of these fonts are not optimized for web use and contain many unnecessary characters. These fonts can easily reach 30KB. Font squirrel allows you to easily create custom font subsets; just drop your font there in TTF or OTF format, enable Expert mode and custom subsetting.

Creating subsets is easy; simply check the subsets you want to keep or write an exact character in the Single Characters field. For example, the copyright symbol is presented in the “Typographics” subset type, but if you only need ©, add it to the Single Characters field.

Vertical baseline fixes

Fixing fonts with Font Squirrel

Another potential issue when using custom fonts, or those not well-optimized, is that the vertical baseline may not be correct. For example:

Using these fonts can result in spacing inconsistencies like above, where the padding at the top is smaller than that at the bottom, while in CSS, the padding is the same.
Sometimes, passing the font over Font Squirrel may automatically fix this problem.

If that doesn’t work, you can address it with Custom Adjustments. Though it takes time to find the right combination of metrics, it can solve the issue.

Using Capsize

Capsize is a library that uses font metadata, so text can be sized according to the height of its capital letters while trimming the space above capital letters and below the baseline. It applies CSS rules with :before and :after pseudo-elements, adjusting the margin-top and margin-bottom so the text can be perfectly sized inside the box, taking the whole space.

Example result:

// For 48px
.css-dpa7xb::before {
  content: '';
  margin-bottom: -0.1432em;
  display: table;
}

.css-dpa7xb::after {
  content: '';
  margin-top: -0.2142em;
  display: table;
}

// For 24px

.css-1m2jnlz::before {
  content: '';
  margin-bottom: -0.322em;
  display: table;
}

.css-1m2jnlz::after {
  content: '';
  margin-top: -0.393em;
  display: table;
}

This is an amazingly easy-to-use solution that works 100% of the time. It just requires additional CSS code for each font size used on a page. I would still recommend trying Font Squirrel auto-fixes first and going for Capsize if necessary.

Summary

Let’s recap what we’ve learned in this article:

Adjusting fallback font metrics is a simple, quick fix that you can use in every project with the help of Fontpie or next/font.
Remove font subsets irrelevant to your use case, especially if a custom stylish font is used in the Hero section for design purposes only.
Keep an eye on the font's vertical baseline and try to fix it if you realize you have to keep padding within a button different from the top and bottom to make the text look centered.

Using those techniques can fix visual issues of your font while saving additional KB. If you enjoyed this article and want more web tips, follow me on Twitter.

Optimization techniques for Rive animations in React apps

Alex Barashkov — Thu, 27 Oct 2022 13:01:22 +0000

What is Rive?

Rive is a modern tool for creating well-performing interactive animations that you can run anywhere. It is simple to use, works great with vector graphics, has a nice developer toolkit and many powerful features like state machine and mesh deformation. At Pixel Point, we often use it for building stunning marketing websites, including our own one.

See a lot of fascinating examples in Rive community library.

What can we optimize?

Rive tells us that all animations are already performing great, and it’s true. Just see this test from Rive team comparing Lottie and Rive.

// Detect dark theme var iframe = document.getElementById('tweet-1580267624050532352-386'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1580267624050532352&theme=dark" }

So I won’t be telling you how to draw and animate in Rive. I will tell you how can you optimize the loading of Rive animations to achieve a better user experience.

Room for improvement

It’s very simple to use Rive in React project. Following the official guide, you can do it this way.

import Rive from '@rive-app/react-canvas';

export const Simple = () => <Rive src="https://cdn.rive.app/animations/vehicles.riv" />;

Once the component is mounted, Rive loads a separate WASM runtime library during initial initialization. Rive uses this library to control animations and interact with them. I suppose it is also the reason Rive performance is so much better compared to the alternative solutions like Lottie. This WASM module is not small and has a size of 78KB.

However, in that case WASM module and .riv animation file will start loading only after React is executed, and if you have Rive animation in the Hero section of your page, it may appear only after 4-5 seconds if the page size is rather big.

Considering that you use modern frameworks that give you SSG/SSR, initial HTML will come to you quite fast, but then you will wait for React hydration to initialize Rive animation.

After measuring the time needed for the initial page loading, component mounting and animation playing, I’ve got the following numbers on a sample project:

React component mounted: ~2.5s
Rive animation playing: ~3.5s

Those are average numbers. They can be different depending on your location and connection. However, it’s obvious that there is room for improvement. My goal was to make the diff between component mounting and animation playing as short as possible, so that’s what can you do.

Host WASM yourself

If you look at the network tab closer, you can see that Rive does not bundle the WASM module into your project and always loads it from

https://unpkg.com/@rive-app/canvas@1.0.64/rive.wasm

It creates an additional connection that I would like to avoid and serve all files from the same CDN. In order to fix it, we can use the following API:

import riveWasmUrl from '@rive-app/canvas/rive.wasm';
import { RuntimeLoader } from 'rive-react';

RuntimeLoader.setWasmUrl(riveWasmUrl);

You can add this code to a page component file where Rive is used. It won’t work unless you add an additional webpack URL loader for wasm files into the webpack configuration.

So, if you use Gatsby, do this:

exports.onCreateWebpackConfig = ({ loaders, actions }) => {
  actions.setWebpackConfig({
    module: {
      rules: [
        {
          test: /\.wasm$/,
          use: [loaders.url()],
        },
      ],
    },
  });
};

And this, if you use Next.js:

module.exports = {
  webpack: (config, options) => {
    config.module.rules.push({
      test: /\.wasm$/,
      use: ['url-loader'],
    });

    return config;
  },
};

Now it’s better, but it was not the biggest issue here.

Preload WASM

The next thing we can do is preload WASM module with link rel="preload"

Since we already patched webpack to load WASM, now it’s very simple to preload it. Add it to the main layout if you use Rive everywhere or set it in the React Helmet on pages where you need it.

import riveWasmUrl from '@rive-app/canvas/rive.wasm';

<link rel="preload" href={riveWasmUrl} as="fetch" crossOrigin="anonymous" />

Preload .riv animation

The same thing you can do for .riv file on a page where it is played.

<link rel="preload" href="/path-to-rive-file/hero.riv" as="fetch" crossOrigin="anonymous" />

Results

I could achieve almost 0 difference between React component mounting and Rive animation playing with this solution. The remaining difference was about 30ms.

I also have some other tricks that can help you with certain conditions.

Rive lazy loading

If you use small animations across the page, it is easy to load all of them in advance. However, if you have some complex graphics and animations in Rive, it could take easily 20KB+. For that reason, I recommend using Intersection Observer API to load them only when they are visible.

In order to achieve it, we need to understand how the Rive react component works. Based on Rive source code, it loads .riv file on component mount, meaning that in order to prevent additional files from loading, we need to prevent rendering of the <RiveComponent>.

Then, using react-intersection-observer, we can subscribe to the visibility of the section with animation.

And the last bit is to wrap RiveComponent with <ImagePlaceholder> to prevent layout shifts on the page.

ImagePlaceholder is a simple solution that uses a svg placeholder to maintain the needed aspect ratio of the image. As an alternative, you can use a modern aspect-ratio CSS property (that still does not work in Safari, unfortunately) or an old school padding-bottom solution. You can find the source code in the demo or in our website repo.

Below is an example app that illustrates how it works (See demo)

import './styles.css';
import { useRive } from '@rive-app/react-canvas';
import { useInView } from 'react-intersection-observer';
import riveBotAnimationUrl from './bot.riv';
import ImagePlaceholder from './ImagePlaceholder';

const ART_BOARD = 'HeroBot';
const STATE_MACHINE_NAME = 'State Machine 1';

export default function App() {
  const { RiveComponent, rive } = useRive({
    src: riveBotAnimationUrl,
    autoplay: true,
    stateMachines: STATE_MACHINE_NAME,
    artboard: ART_BOARD,
  });

  const [ref, isInView] = useInView({
    triggerOnce: true,
    // rootMargin: "200px"
    threshold: 0.2,
  });

  return (
    <div className="App">
      <section className="hero">
        <div>
          <h1>Rive Lazy Loading Example</h1>
          <p>Scroll down the page and look at network tab</p>
        </div>
      </section>
      <section ref={ref} className="animation-container">
        <ImagePlaceholder height={400} width={400}>
          {isInView && <RiveComponent />}
        </ImagePlaceholder>
      </section>
    </div>
  );
}

Note: Rive WASM module also loads automatically on a first RiveComponent initialisation, so when postponing the rendering, you also postpone the loading of quite a large runtime.

Rive, React.lazy and Suspense

Last bit of optimisation that is very useful in case you don’t want to show Rive animations at all on certain devices is using React 18 Suspense and lazy component loading. The architecture behind that solution is:

Move the component that loads, controls and plays Rive animation into a separate React component.
Import it, using React.lazy. This will cause a creation of a separate JS bundle.
Wrap lazy loaded component with Suspense.

const RiveAnimation = lazy(() => import('components/rive-animation'))

const Section = () => {
return (
    {isMobile ? (
      <img src="my-example.png"/>
    ) : (
      <Suspense fallback={<Loading />}>
        <RiveAnimation />
      </Suspense>
    )}
  )
}
export default Section

You can find a full example of this solution in a great demo by Paul Scanlon.

Rive animation component

Section component

Demo site

That’s it!

Let’s sum up everything on the optimal usage of Rive with React:

Host WASM runtime library yourself. It will prevent an additional http connection with an external unpkg server where this library hosted by default.
Preload .riv and WASM files in case you have Rive animation in the Hero section of the page. It will drastically decrease loading and execution times.
Create a separate bundle for Rive using React lazy and Suspense to avoid loading the library when the network is slow or on mobile devices.

If you enjoyed the article and want to see more tips on web performance, follow me on Twitter.

Gatsby Graphql schema customization for beginners

Alex Barashkov — Mon, 16 May 2022 15:57:11 +0000

Gatsby has one big difference from other frameworks: it has a built-in Graphql data layer. Such a layer opens a lot of possibilities and is a key part of the big ecosystem of plugins. You can fetch data from CMS using Graphql, query images, query markdown based content with a help of a variety of plugins.

It’s all possible because those plugins fetch data from sources and transform it into Graphql Nodes during build time. In most cases, it’s more than enough, and you even don’t need to be a master of Graphql to use Gatsby and build cool things.

But today I want to talk about Gatsby’s Schema Customization API, since it could drastically improve the quality of projects in certain cases.

What is Gatsby’s Schema Customization API?

This API allows to interact with a Graphql data layer and customize it the way you want. It could help extend the current Graphql types or create completely new ones.

Use cases

As a beginner, you would probably benefit from using the following common scenarios:

Replacing data in the existing Graphql field
Adding a new field to existing Graphql type and filling it with some data
Defining relationships between Graphql types

Replacing data in the existing Graphql field

This technique is really helpful when you want to define a default value for an existing field. For example, you have a blog that has articles coming from markdown, and some of them have a flag draft: true but others do not. For better filtering, you want to make sure that every blog post has a draft field with either false or true value in Graphql.

There are two ways to achieve that. First one is using onCreateNode API (docs) that is provided by Gatsby. Just go to gatsby-node.js and add these lines.

exports.onCreateNode = ({ node, actions }) => {
  const { createNodeField } = actions;

  if (node.frontmatter) {
    createNodeField({
      node,
      name: 'isDraft',
      value: node.frontmatter.isDraft || false,
    });
  }
};

This code will be invoked on each Node creation, so it’s good to filter nodes there by certain parameters to add a field only to the relevant nodes. It’s a quick solution, but it is a bit raw. As you can see, the original isDraft field from markdown frontmatter data remains untouched, and we create a new one in that node under fields directory.

For better performance, we can use a more granular approach by overriding the original field with a custom resolver. This method requires some more knowledge. We will need to know the exact Graphql type we want to modify. To know the exact name of the type, we can run Gatsby with a special flag GATSBY_GRAPHQL_IDE=playground npm start. This way we will see GraphQL Playground instead of GraphqiQL IDE on [http://localhost/__graphql](http://localhost/__graphql), and we can get the required information there.

Open the Schema panel, find a type using Ctrl+F. Once we have found it, we can see that the type we’re looking for is MdxFrontmatter and the field isDraft has a Boolean type. So with a help of createResolvers API (docs) declared in gatsby-node.js we can define a default value for the field.

exports.createResolvers = ({ createResolvers }) => {
  createResolvers({
    MdxFrontmatter: {
      isDraft: {
        type: 'Boolean',
        resolve: ({ isDraft }) => isDraft || false,
      },
    },
  });
};

As you can see, there are no more null values in isDraft field and it has either false or true values.

Add a new field to the existing Graphql type and fill it with some data

We just figured out how to modify the existing data, but let’s go further and add a completely new field. Let’s look at this example from our website. We have case studies for open source projects stored in markdown, and we want to have the number of stars from GitHub to be fetched during build time for each one of them. It’s a perfect task for Gatsby Graphql schema customization.

So for each case study I want to declare a field githubStars and tell Gatsby to fetch data from the GitHub API. We already used createResolvers function for field modification, but it also could add a new field.

From Graphql Playground we can grab a type that used for markdown files, which will be Mdx, and then add a new field this way.

exports.createResolvers = ({ createResolvers }) => {
  createResolvers({
    Mdx: {
      githubStars: {
        type: 'String',
        resolve: async ({ frontmatter, fileAbsolutePath }) => {
          const { name, githubUsername, githubRepoName, isOpenSource } = frontmatter;

          if (
            fileAbsolutePath.includes('/case-studies/') &&
            isOpenSource &&
            githubUsername &&
            githubRepoName
          ) {
            try {
              const response = await fetch(
                `https://api.github.com/repos/${githubUsername}/${githubRepoName}`
              );
              const { stargazers_count } = await response.json();

              return new Intl.NumberFormat('en-US').format(stargazers_count);
            } catch (e) {
              throw new Error(`Failed to fetch GitHub stars for case study "${name}"`);
            }
          }
          return null;
        },
      },
    },
  });
};

Resolve function receives all node data, so it’s easy to filter mdx files based on certain rules e.g., file location folder. Resolver can be an async function so it’s ok to do external calls from there too.

Define relationships between Graphql types

Another common use case. You have a blog in markdown, and you have a list of authors in JSON. You want to fetch all data from a Graphql layer, so the author is nested to a blog post data. This could be achieved with createSchemaCustomization hook from gatsby-node.js using createTypes API (docs).

The structure of the JSON author object could be like this:

/// content/posts/post-authors.json
[
  {
    "name": "Alex Barashkov",
    "photo": "../../src/images/post-authors/alex-barashkov.jpg",
    "description": "CEO at Pixel Point and software engineer with 10+ years of web development experience. Currently focused on React, Next.js, Gatsby.",
    "twitterUrl": "https://twitter.com/alex_barashkov"
  },
  ... more authors
]

The blog post content, however, could be like this:

// content/posts/example.md
---
title: 'Taking automated web page screenshots with Puppeteer and Sharp'
summary: A step-by-step tutorial on how to create perfect high-resolution web page screenshots automatically. No fuss, it just works.
author: Alex Barashkov
cover: cover.jpg
category: Development
---
... Blog post content

As you can see, we have a name of the author in a frontmatter post data and the same name in authors.json. Now the goal is to make the author accessible via Graphql as a nested object when we fetch post data.

Note: For blog posts we use gatsby-plugin-mdx, for sourcing JSON data to Graphql - gatsby-transformer-json. See the full example of the project here.

Here is a config from the gatsby-config.js that makes this sourcing happen:

{
      resolve: 'gatsby-source-filesystem',
      options: {
        name: 'posts',
        path: `${__dirname}/content/posts`,
      },
    },
    {
      resolve: 'gatsby-source-filesystem',
      options: {
        name: 'post-authors',
        path: `${__dirname}/content/posts/post-authors.json`,
      },
    },

We use the same strategy as before: let’s open Graphql Playground. We already know the Graphql type of markdown files, but we need to find a type of JSON based nodes. In our case, it will be PostAuthorsJson .

Having that information, we can add createSchemaCustomization to gatsby-node.js and use a function called createTypes. That technique allows to modify the Graphql schema.

Note: If you want to override the existing Graphql type completely, use @dontInfer directive near the type definition (docs).

There are some options to define nested relationships manually. However, the simplest option is to use a built-in @link directive. Think about it as a helper that does a mapping between two Graphql types based on provided foreign key relationships.

Let’s check it out. Add this code to the gatsby-node.js and see the result.

exports.createSchemaCustomization = ({ actions }) => {
  const { createTypes } = actions;
  createTypes(`
    type Mdx implements Node { 
      author: PostAuthorsJson @link(by: "name", from: "frontmatter.author")
    }
  `);
};

Now authors are linked to markdown nodes. This way you can fetch nested data and even filter results by author’s information.

Summary

Now you know how to modify the Gatsby Graphql schema, and I hope you find it useful for your project. All three examples are available here in our GitHub website repository.

Want to learn more about Gatsby, Next.js, React and Headless CMS follow me on Twitter.

Comparing Gatsby and Next.js for website development

Alex Barashkov — Tue, 22 Feb 2022 15:03:30 +0000

Gatsby and Next.js, from a first glance, could look pretty much the same. Both are React-based frameworks, do SSR, SSG, have big communities. We actively use both technologies in our agency, but we think that they fit better for different use cases. I often get asked why we use Gatsby instead of Next.js for websites development? This article will explain it in detail.

Choosing the technology for website development, we need to keep in mind a few factors

Speed of development
Editorial experience
Maintainability
Scalability
Customization

Here is how a feature comparison table between two frameworks might look like. They are pretty much the same, aren’t they?

However, those minor differences could cause a huge impact on website development.

Now, let’s go over what needs to be on a website and check how the frameworks handle the same tasks.

Everything begins or ends with Favicon

A simple, tiny thing that every website has. But, in order to be compliant with different use cases, OS, Browsers, you need to have usually more than one - 16x16, 32x32, 180x180, 512x512, etc. It’s nice when you don’t need to care about it

...and with Gatsby, you don’t

Change a single line in gatsby-config.js and upload png/jpg/svg based favicon...That’s it. Gatsby will generate a set of relevant icons following best practices optimizing the image without any additional work.

...but what about Next.js?

There is no opinionated way that Next.js recommends for this. Try to Google it and see how different the answers are, e.g., this Stackoverflow Thread. Everything has to be done manually - image optimization, image resizing, embedding the proper tags using <Head> tag. As an option, you can use favicons generators services like this.

Future is here with image optimization

Both do a lot of magic, tuning images with the sharp library, bringing the support for modern image file formats such as webp and avif, which results in smaller files’ sizes and a faster website loading speed.

Both have their own image components, next-image, and gatsby-image, with a similar API. But there are a few differences.

Is next-image good?

next-image is just a component when the actual image optimization happens via API route that accepts query string parameters and returns a processed image, e.g., /_next/image?url=http://example.com/avatar.png&w=32&h=32

I like this architecture for it also brings additional flexibility in terms of using optimized images without using a react component.

Another thing worth mentioning: next-image requires you to specify the width/height of the image, which is not the case when you fetch data from a CMS unless you use layout="fill", but having done that, you are required to manually handle the logic of the image wrapper. So to avoid layout shifts, you fetch the image from a CMS, get their width and height, then, for example, use a CSS aspect-ratio property or go with the SVG hack as gatsby-image does automatically to maintain the original proportions

or gatsby-image is better?

gatsby-image does not have that API endpoint and does the magic behind the scene using the power of their graphql data layer and different transformer plugins. Everything works out of the box without additional configuration. But there is one more thing that Gatsby can do better - image art direction. Art direction aims to define multiple image srcsets for different screen sizes that could be cropped and positioned differently. The typical use case for this is when you have a big diagram, let’s say on the home page, but on mobile, it will be too small if we just scale it down. As a solution, you might pass a secondary image with increased diagram labels to the srcset optimized for mobile devices.

Importance of CMS Integrations

For the best customer experience, it’s precious to provide the greatest flexibility for editors and solid CMS integration in place. On the websites, we build every word and page can be edited via CMS and any additional metadata - page URL, meta tags, og tags, etc. We use Headless WP most of the time, but sometimes do the job with Contentful, Strapi or Prismic, so having a flexible and straightforward way for data fetching from different platforms is crucial.

Gatsby and the power of plugins

With Gatsby, the integration is a matter of plugin installation and providing API keys. No need to deal with SDKs and nerding through API docs. Everything will be fetched and added to a unified Gatsby Graphql Layer. There are so many plugins that you can find a source plugin literally for anything. The client uses some recruiting platform and wants to display a jobs list on his own website as well? Not a problem. Does he plan to display a list of Github repositories with stars counter - just go and grab the plugin for this. Data will be added to Graphql, and you wouldn’t need to worry about the learning curve for understanding various APIs.

Example of fetching data with Gatsby Graphql using gatsby-source-wordpress plugin

Next.js tailored approach

Next.js does not have a plugins ecosystem, so for fetching data from a CMS, we have to find SDK, learn an API, think about the reusability of that integration within the website on different pages, probably make some SDK wrappers for common use cases, or HOC. Maybe it’s ok for small sites, but for large ones it will require spending some time thinking about the overall data fetching architecture and scalability of the solution.

To preview or not to preview?

Okay, let’s step back here because I’m sure that many people don’t even bother themselves giving that functionality to the editors. Previews functionality means rendering a specific page on demand from a CMS without publishing it in the production.

If you use Gatsby, it supports the most popular CMSs, and it works seamlessly. You can either use Gatsby Cloud, and the preview server will be created automatically, and all you will have to do is just point CMS to a correct URL, or you can deploy a self-hosted version running gatsby with GATSBY_ENABLE_REFRESH_ENDPOINT=true. Below is an example of how it works with Gatsby + Headless WP.

With Next.js, things yet again get more complicated; see the official doc. Again, there is a need to write it manually for every entity you plan to preview, defining rules of how the data from a preview trigger will be parsed, what will be fetched later, and what will be rendered. Instead of a five-minute setup with Gatsby, you will have to spend hours to get something usable.

Flexibility for editors with programmatic page generation

Next.js options

To achieve the best-in-class editor experience, editors have to be in charge of defining URLs and pages displayed on it. Let’s break a rule and start from Next.js first. There are few options to achieve or partially achieve it.

1) Hardcode dynamic subpages URLs eg. pages/post/[slug].js. For example, there is a slug field for a post on the CMS side, and you agree it will always be under the/post`, then define getStaticPaths in the component.

2) Write a wildcard component in the root pages/[...path].js. Then write an additional wrapper component with the logic of mapping a specific URL to a specific component. It raises plenty of issues and increases the architecture complexity a lot.

3) Use Faust - a framework built based on Next.js tuned specifically for WP integration. Look at the source code, and you will find that they exactly do option 2) and see how complex it is. And it’s only available for WP.

Gatsby way

Gatsby originally has been created as a SSG framework, so it has a few powerful architecture concepts

1) Single point of programmatic page generation in gatsby-node.js. Imagine that it’s like telling the framework in a natural language - “Please fetch all pages from a CMS, then create for each CMS page a relevant Gatsby page based on a template and make it accessible on a URL defined in a CMS.” So here, we can use different templates for pages based on the data from a CMS.

2) Templates concepts. Separating Pages concept and Templates makes it easier to define hardcoded URLs and programmatically created pages based on templates.

As a result, you can achieve entirely CMS-driven routes and pages creation without overwhelming yourself with complicated logic in the code.

We demand Incremental Static Regeneration!

Incremental Static Regeneration (ISR) allows you to update only specific pages incrementally instead of rebuilding all pages based on the incoming changes. Incremental builds are technically different from ISR, but both are trying to solve the same problem: speeding up content updates on a production by incrementally updating pages. Gatsby has been having incremental builds since v3 and actively uses it with the help of different CMS integrations and Gatsby Cloud by rebuilding only new updates, which usually takes mere seconds.

Next.js had been following a bit different approach that did not require an additional build to run in case of CMS changes. Instead, it allowed you to specify the time in seconds for which the page will be fetched from a cache instead, so it will go and fetch new data when the first unlucky user comes in.

Initially, I was considering putting it as a disadvantage for Next.js. It was a high-demand feature, but while I’ve been working on the article, they introduced on-demand ISR, which is supposed to solve the issue bringing the ability to revalidate cache from external sources calls. As of the 17th of February, it is considered a Beta feature.

Data queries everywhere

Another highly demanding feature of Next.js is query data similar to getServerSideProps, getStaticProps on a component level instead of just a parent page level. Currently, you have to use props drilling or stores/context to pass data from a top-level to an underneath component. React 18 and Server Side Component should potentially solve this issue in the future.

Meanwhile, in a Gatsby project, you can fetch data from a global graphql layer from anywhere using a useStaticQuery. It simplifies the architecture and allows you to have reusable components.

Very external imports

This has been brought by NextJS recently and bear all signs of being a massive advantage in perspective, for combining Low-Code / No-Code solutions with hand-written applications. To understand this feature, it is best to read this great example of usage between Framer and Next.js. You can build a custom component in a visual editor, maybe also wrap it with some nice animations and then just import it to the project with a single line:

This is mind-blowing and opens a lot of further possibilities. Gatsby does not allow you to do this at this moment. So if it’s something you want to use in your project, Next.js is probably a better option.

Sitemaps are good everywhere

Both frameworks can handle it by using additional libraries. Gatsby handles it with a plugin and minimal configuration. For Next.js, a library does the same but requires additional post-build script execution.

Smartless i18n

Interesting thing about this point that despite the fact that the implementation will look almost the same for both frameworks, another Next.js feature called Global Middlewares makes it much more powerful. It allows you to define a top-level middleware and perform, let’s say, a country detection on an edge network and than either replacing or redirecting user to a statically generated page.

Summary

We can still recommend both frameworks for website development as very reliable solutions. However, Gatsby definitely works better in terms of static generation and integrations made possible by the plugin ecosystem. For us those features are critical and we see how Gatsby allows us to build websites faster, make them flexible and maintainable. Next.js is a more dynamic-oriented framework, and I would go for it only if I need an additional auth layer on the website or maybe in case when I need that Global Middleware functionality that could help deal with i18n, A/B testing, or Feature Flags. These are definitely nice to have, but usually, they are only required for a huge enterprise-grade tech where you can afford such experiments.

Want to hear more about Gatsby, Next.js, and tips for building high-performing and visually stunning websites? Follow me on Twitter.

Measuring Gatsby projects build time using paid plans of popular static website hosting platforms

Alex Barashkov — Tue, 01 Feb 2022 11:22:03 +0000

Jamstack is showing rapid growth these days. We get more and more tools and frameworks for it almost every month, bringing a new life for the concept of static sites generation.

Our go-to framework for building websites at Pixel Point was always Gatsby. Three years ago, when we’ve just started to use it, there were not too many options where you could deploy the site - Netlify or Vercel. Now things have changed, you also have Gatsby Cloud, Cloudflare pages, AWS Amplify, and you can even make similar build tools within your infrastructure using projects like Waypoint.

Having a statically generated site comes with one significant drawback - build time. If you have a small blog or single-page website, all hosting or frameworks will give pretty much the same results, and the difference won’t be noticeable, but things get worse when it comes to 100+ pages. On that scale, the platform could make a massive difference in terms of build performance for developers, designers, and marketers, since no one wants to wait hours to see the changes live.

So I decided to run tests across the most popular platforms using paid plans.

Platforms
Test cases
Markdown-based website
Headless WordPress website
Winners

Platforms

Netlify

Pro plan - $20/month per member.

Vercel

Pro plan - $20/month per member.

Gatsby Cloud

Pro plan - $50/month, 2 seats included, $20 per additional member.

Cloudflare Pages

Pro plan - $20/month, unlimited seats.

AWS Amplify

First 1000 minutes free, then 0.01$ per build minute.

Self-hosted

$50/month, a self-hosted server running Drone CI with the following specs: AMD Ryzen 5 3600 Hexa-Core "Matisse" (Zen2), 64 RAM, 512GB Raid NVME SSD. Unlimited seats. Deployment to Netlify using netlify-cli.

Test cases

I started by testing clean cache build-time performance. Although you usually have a cache that works well and reduces the build time, there are still some cases when you have to clean it up manually, or Gatsby will clean it for you on changes in gatsby-node.js, gatsby-config.js, or package.json files.

I made five runs for each test and then wrote down the average. I also used a stopwatch to ensure that there is no significant difference between the actual notification about completion and the number in UI. The goal of the stopwatch was not to measure it accurately but to figure out whether platforms show us the truth and don’t deduct from a build time some stages such as environment initialization or publication.

Markdown-based website

Clean cache build time

First in the test was a markdown-based website. The results were quite surprising. Gatsby Cloud did the job within two min., which is eight times faster than Netlify - 16. The results for Gatsby Cloud are quite similar to what I see running builds locally on Apple M1 chips, which is insane. I’m sure they do some nice magic behind the scenes, at least parallel image optimization.

Vercel was a little faster than Cloudflare pages finishing with 10:30 vs. 11:23. I definitely underestimated AWS Amplify and thought they would run builds on free tier EC2 instances, but they are running builds on a host with 4 vCPU, 7GB memory (appreciate that transparency in UI), so it finished as 9:47.

The self-hosted solution was relatively fast and very close in terms of the build time to Gatsby Cloud, but uploading results to Netlify takes around half of that time, so it finished second place.

The funny thing here is that Gatsby Cloud could complete the whole build in the amount of time it took Cloudflare to initialise the environment.

Deploy Preview build time

Here I’ve started to feel that it will be a death race since competitors began to reveal their problems and how differently they handle different scenarios. In the Deploy Preview test, I created a separate branch from the master and made two changes in a jsx file and another in md file.

Netlify(16:16), Cloudflare(11:16) and AWS Amplify(9:14) showed the slowest results, and here is why. Netlify has a nice plugin that persists cache between builds, BUT it does not work if your build lasts for more than 15 minutes.

Cloudflare Pages does not have an option to persist cache between builds, so it shows slow results every time.

AWS Amplify has an option to persist the cache, but all their official docs don’t have information about how to make it work. Simply adding necessary folders to their build yaml file does not work. After spending a reasonable amount of time researching it, I passed on it since I’m pretty sure their users won’t dive into that research either. Without that configuration, the only thing that persists between builds is node_modules.

Vercel did a great job and finished within 3:32. I was impressed with this result because all cache magic is done behind the scene, and there is no need to install additional plugins for gatsby to the platform and inside the code to make it work properly.

Gatsby Cloud was again a winner with 0:49, and the self-hosted version was just 25 seconds behind.

Warm cache build time

By the warm cache build time, I mean a subsequent build, that runs from the same branch where the build happened before. It’s a case you have every time you redeploy a website on content change or make additional commits to your Pull Request.

Vercel(1:08) and Selfhosted(1:06) finished very close, but Gatsby Cloud was faster with 0:27.

Cloudflare Pages and Netlify, AWS Netlify however, have room for improvement for sure.

Headless WordPress website

Then I jumped testing Gatsby v4 connected with the WordPress website. The site has two languages, a batch of common WP plugins, and around 1000 pages in total. This is where things get challenging.

Clean cache build time

Netlify even has not finished the build and stopped after 22 minutes. Vercel and Cloudflare pages completed within 24 minutes. Gatsby Cloud was fast, but it was tough even for it - 17:47. AWS Amplify surprised the most, showing consistent time around 15 min. The self-hosted CI achieved the quickest result - 11:30. The server we host is probably closer to the WP hosting, and it took less time for initial assets to download.

Deploy Preview build time

I guess we can consider that Cloudflare, Netlify, AWS Amplify failed this round, so let’s go straight to Vercel. It took 2:39 for Deploy Preview, which is a very nice result. Gatsby Cloud did the same job within 1:45, and the Self-hosted version handled it within 1:23.

Warm cache build time

Vercel did not show any difference from Deploy Preview. For Gatsby Cloud, however, it took 20 seconds less. The self-hosted version had the same excellent results. But I have to mention there was a moment that uploading files over Netlify CLI with a self-hosted version took more than 6 minutes. I decided not to include it because it happened only once.

Bonus

It won’t be complete without showing you one more thing. All tests above were made, making changes in one jsx file and one blog post. But here is what Gatsby Cloud can do if you make a content change(from CMS like WP/Contentful/Prismic etc), which happens the most.

From an architecture perspective, based on build logs, it feels like Gatsby Cloud keeps the latest instance of your production version in a sleep mode, then they can wake it up quickly and skip some build steps, and knowing a content diff produce a new build very quickly.

It took just 20 seconds from making a change in a CMS to seeing it live in production! That’s very impressive. A few years ago, when Kyle Mathews (Gatsby creator) said that they were going to make it possible to rebuild the site in a matter of seconds, I was really skeptical about this, but now it seems it could be true. Great job!

Note: This result only could be achieved if you change a post or page. If you change shared data such as Menus, it will have to rebuild each page so that it will take around 50 seconds in the end.

Winners

Gatsby Cloud won the race showing the best in class performance build time. I’m sure it uses the most powerful cars compared to other platforms and does some background magic. Vercel showed up still as a strong competitor. It did not show great results in cold runs, but cache changes everything. Talking with our clients, we mentioned that nobody cares when builds take less than 10 minutes, but after passing that threshold, you start to receive questions about how to make it faster. So considering this, I definitely could recommend both Gatsby and Vercel solutions.

Despite all the love that I have and share about Cloudflare products, Pages feels like the weakest one in their lineup. Development has been very slow, and I did not mention significant changes since the first beta and the current state. In my perspective, Cloudflare has the most affordable and reasonable pricing plan with no seat limits and bandwidth limitations. So let’s keep watching.

AWS Amplify... What can I say? It’s AWS. If you love their services and don’t find their UX the worst, it could still be an option. Build configuration as YAML files, separate settings to enable Deploy previews and builds for other branches. Missing Cache-Control policies out of the box. All of these don’t play well in their favor.

Netlify, I suppose, is still the most popular and very affordable solution on the market. Great UI and amazing features set, but build time could become a severe bottleneck if your site scales faster.

A self-hosted alternative is fast, does not have any limits, and costs just $50/m for a very powerful machine; however, you need to keep in mind that you will probably need to spend hours setting it up at least once in a while.

Want to hear more about Gatsby, Next.js, and tips for building high-performing and visually stunning websites? Follow me on Twitter.

Headless WordPress website source code
Markdown based website source code

How to hide Feature A and show Feature B for different users in React

Alex Barashkov — Tue, 20 Jul 2021 15:16:18 +0000

Overview

Have you ever wondered how do companies like Slack, Netlify, Zoom, Facebook (and rest of FAANG for sure) gradually roll out new features just for some users? 🤔

Wonder no more! It is done via Feature Flags (or FF for short) and we're just about to dive into this concept.

Feature Flags services work the following way. You define a list of features(eg. dark mode, horizontal login layout, design 2.0) and assign it to a group of users specifying conditions whether it should be enabled or disabled.

Chances are that you've already used FF in your projects but wasn't aware of this. Did you store in a database some booleans that indicate whether particular user should have an access to a certain feature? If yes, then congratulations - you indeed have experience working with feature flags.

Booleans in DB were good up to a certain point, but progress never stops and now we have much more flexible and dev friendly way to control feature presence. Let's take a look at feature flags services. FF services have the following bonuses:

UI where you can define and manage features
Users segmentation
A/B testing
Flags analytics
Staged feature rollouts
SDKs for different languages/frameworks

In this article, we are going to use Flagsmith - open source feature flag and remote config service, but you can check commercial alternatives such as LaunchDarkly. Our goal is to learn how to start using feature flags in React and make the process of launching new functionality for users smoother.

FF manipulation with Flagsmith can be done pretty much anywhere (frontend/backend/mobile platform). Let's take a look at the following schema:

Let's break down what is happening here.

1) User requests the page
2) A certain side of your app (FE/BE) makes a call to Flagsmith service with user uuid
3) Flagsmith matches received uuid with the configuration of available features for this particular user and returns the info on that
4) App generates a page based on received feature info

Definitely not a rocket science. Now to practice!

Flagsmith / flagsmith

Open Source Feature Flagging and Remote Config Service. Host on-prem or use our hosted version at https://flagsmith.com/

Our goal

We want to build pretty much standard dashboard app (sorry, no todos today) with authorization set up. We want to show certain feature components only to those users who opted-in for beta.

React, Next.js, Next-Auth and beautiful dashboard components from Tailwind UI are going to help us building it.

Pre-requirements

Create a new app with Next.js, React and Next-Auth or clone this sample repository

Additional links

Getting started with Next.js

Getting started with nextauth

Then create an account in the cloud version of Flagsmith.

Configure Flagsmith environment

The configuration process is simple. Once you've signed up, create a new project. In Flagsmith you can define multiple environments per project, each environment keeps its own features/users/segments and API key.

Let's create our first feature, we will name it - "pinned_projects". Beta users will be able to pin projects and see them.

Next step we need to install flagsmith-react package

npm i flagsmith-react

As an initial step, we will wrap our _app.js with FlagsmithProvider and pass Flagsmith API key, which we can get from the Settings page in Flagsmith UI. FlagsmithProvider will allow to use useFlagsmith hook and pass the state to underlying components.

import Auth from 'components/auth';
import { Provider as SessionProvider } from 'next-auth/client';
import { FlagsmithProvider } from 'flagsmith-react';

import '../styles/globals.css';

export default function MyApp({ Component, pageProps }) {
  return (
    <FlagsmithProvider environmentId={process.env.NEXT_PUBLIC_FLAGSMITH_API_KEY}>
      <SessionProvider session={pageProps.session}>
        {Component.auth ? (
          <Auth>
            <Component {...pageProps} />
          </Auth>
        ) : (
          <Component {...pageProps} />
        )}
      </SessionProvider>
    </FlagsmithProvider>
  );
}

FlagsmithProvider will initialise Flagsmith javascript client under the hood and you will be able to start getting flags declared in the UI. But it does not make too much sense unless we get user-specific flags. To let Flagsmith know which user requests flags, we need to identify him. The perfect place for this Auth component, that responsible for checking user session and redirecting users to the sign-in page in case it's expired.

import { useSession, signIn } from 'next-auth/client';
import { useEffect } from 'react';
import { useFlagsmith } from 'flagsmith-react';

export default function Auth({ children }) {
  const { identify, isIdentified, getTrait, setTrait } = useFlagsmith();
  const [session, loading] = useSession();
  const isUser = !!session?.user;

  // Identify user and set email trait if does not exist
  const identifyUser = async (id, email) => {
    await identify(id);
    const hasEmail = !!getTrait('email');
    if (!hasEmail) {
      setTrait('email', email);
    }
  };

  useEffect(() => {
    if (loading) return; // Do nothing while loading
    if (!isUser) signIn(); // If not authenticated, force log in
  }, [isUser, loading]);

  useEffect(() => {
    if (isUser && !isIdentified) {
      // In the example we don't save users in the database so we don't have id that should be used for identification
      // Instead we're going to use email as a trait and id
      identifyUser(session.user.email, session.user.email);
    }
  }, [isIdentified, identify, session, isUser]);

  if (isUser) {
    return children;
  }

  // Session is being fetched, or no user.
  // If no user, useEffect() will redirect.
  return <div />;
}

Here you can see that we use getTrait and setTrait. Traits are simply key/value pairs that are associated with individual Identities. You can pass any additional information to the user, that later could be used for segmentation eg. current plan, opt-in for beta features or newsletters, etc.

Let's create first segment and call it beta_opt_in . Go to Segments → Create Segment. Here you also could define an expression based on the trait which will add users that match that condition to the segment. We can start from a simple one, such as if email has [pixelpoint.io](http://pixelpoint.io) consider them as opted-in for beta features.

The final step is to add a check to our React component using hasFeature("pinned_projects").

const Home = () => {
  const { hasFeature } = useFlagsmith();

  return (
    <>
      <main className="flex-1 relative z-0 overflow-y-auto focus:outline-none">
        <div className="border-b border-gray-200 px-4 py-4 sm:flex sm:items-center sm:justify-between sm:px-6 lg:px-8">
          <HomeHeader />
        </div>
        {hasFeature('pinned_projects') && (
          <div className="px-4 mt-6 sm:px-6 lg:px-8">
            <PinnedProjects items={pinnedProjects} />
          </div>
        )}
        <ProjectsTable items={projects} />
      </main>
    </>
  );
};

Here you go!

If you've been following along, by this time you should have a nice little pet project demonstrating a modern approach to feature flags. Congratulations🎉

Don't hesitate to extend it or leverage the idea in your existing project.

P.S. Further reading

In this article we just took a quick glance at Feature Flags and built a simple example app, but FF system is capable of much more. Check out:

Top 10 open-source SaaS that could help you build the next big thing

Alex Barashkov — Thu, 15 Jul 2021 08:48:03 +0000

I'm super happy that investors and big companies are finally happy to support Open Source projects. It was hard to imagine 10 years ago that there will be plenty of SaaS built based on open-source model.

Here is the list of my favourites that could help you build amazing modern architecture covering different aspects of product development and architecture.

Hasura

hasura / graphql-engine

Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.

Hasura simplifies the development a lot. How do you usually build your apps? Probably you choose some framework, set up ORM, set up DB, write manually migrations, then you build batch of CRUD endpoints either with REST or Graphql, add authorization layer.

With Hasura you can:

easily create most of your tables for PostgreSQL, TimescaleDB, MySQL, MongoDB, MSSQL using nice UI
every DB structure modification will be recorded as a migration(so you can easily run it within your CI by using Hasura CLI)
each table will automatically get relevant graphql/rest endpoints
protect each endpoint by a powerful set of rules for each user role
and if you need more business logic you can merge generated endpoints with custom graphql server

TimescaleDB

timescale / timescaledb

An open-source time-series SQL database optimized for fast ingest and complex queries. Packaged as a PostgreSQL extension.

An extension for PostgreSQL that boost the performance of time-series operations. Super simple to use, amazing documentation and nice cloud service. You can always use it as a replacement of PostgreSQL because it does not have any downsides, but in case you start saving some metrics, stats to your database you will be covered. It has 10x-100x faster queries than PostgreSQL for time-series.

Supertokens

supertokens / supertokens-core

Open source alternative to Auth0 / Firebase Auth / AWS Cognito

Every project needs authorization. If you used Auth0, it's pretty much the same but it's Open Source, so you can easily host it within your own infrastructure or either use cloud version. It works based on JWT, so simply integrates with Hasura.

n8n

n8n-io / n8n

Free and source-available fair-code licensed workflow automation tool. Easily automate tasks across different services.

Don't want to bother yourself with programming automation between different services and spending hours on that? Try n8n. Powerful UI to design different integrations and automations that rely on data changes/triggers.

Rancher

rancher / rancher

Complete container management platform

Modern applications deserve modern infrastructure and managing it could be a painful process. Rancher simplifies management of Kubernetes clusters whether you run it in the cloud or on bare-metal servers.

Drone CI

harness / harness

Harness Open Source is an end-to-end developer platform with Source Control Management, CI/CD Pipelines, Hosted Developer Environments, and Artifact Registries.

Despite Github actions and Gitlab are very popular solutions, Drone CI has fantastic architecture and a very simple set-up. After it's been acquired by Harness, it's got a major 2.0.0 update that brought a lot of cool features such as activity charts, user management, new UI. Drone CI is a very powerful and flexible tool.

Grafana

grafana / grafana

The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.

You can't build the next big thing without having a proper monitoring analytics solution. Grafana was an essential tool in that space for a very long time, and now they also have a cloud version.

K6

grafana / k6

A modern load testing tool, using Go and JavaScript - https://k6.io

The best performance testing tool and it's open source. Recently K6 has been acquired by Grafana Labs, so I'm sure it will become even better. If you had experience writing scripts for jMeter, K6 experience will be 100x times better.

Sentry

getsentry / sentry

Developer-first error tracking and performance monitoring

Error reporting is crucial when you want to handle customer issues before it will have a negative impact on your business. Sentry allows you to simply integrate their SDK in your framework/language and start to receive alerts when errors happen either on the client or server-side.

Flagsmith

Flagsmith / flagsmith

Open Source Feature Flagging and Remote Config Service. Host on-prem or use our hosted version at https://flagsmith.com/

In 2021 you should stop pushing major updates to all users at the same time. Control their expectations and react to issues predictively by using feature flags. Simply integrate it with your framework by using SDK, then manage who should be allowed to have access to certain features.

Summary

Building projects with open source technologies is amazing, since you don't need to spend a fortune to test things, but as projects grow you always could try paid cloud versions.

What open source SaaS do you use in your project?

Speed up your development with this new VS Code extension

Alex Barashkov — Fri, 19 Jun 2020 15:03:16 +0000

My friend and I recently developed VS Code extension – Snipsnap that aims to solve the existing problem with code snippets collections.

Snipsnap is the ultimate snippets collection and VS Code extension that automatically exposes all available snippets for every library you are using in your project.

We already have snippets for React, Redux, Gatsby, Next.js, Vue. The full list of snippets you can find there.

🔥 What problem Snipsnap is trying to solve?

Problem #1

Almost every popular language has a lot of different libraries that people used to use. Some of them big, some are small. For each library, you should keep in mind a lot of different syntax constructions in order to use them. Code snippets help to fix it, but you don't want to create and you will not install extensions for each small library. Instead of it we want to have a single Snipsnap extension that will fetch relevant code snippets based on languages, packages you use in your current project.

Problem #2

Different snippets extensions follow different rules and use unpredictable shortcuts such as "rccp", "ecrp", 'impp' etc. Having those unreadable shortcuts don't allow you to actually search across all snippets you have for a specific case. We want to change it by standardizing snippets format and providing clean, predictable search syntax such as library-name keyword, so you can always type the name of your library and get a full list of snippets available for it.

Problem #3

Each IDE has individual snippets format that does not compatible with other IDEs. So having independent snippets format could allow us to create Snipsnap extensions for each popular IDEs and using converters transform snippets from one format to another.

🛠️ How it works

Snipsnap VS Code extension scans your package.json(or yarn.lock) and searches on the server available snippets for packages you have in the project. It means that you don't need anymore install different extensions with snippets for frameworks, libraries you use.

Snipsnap extension creates snipsnap.code-snippets inside .vscode folder with all snippets, so snippets will be available even for other developers who did not install extension.

Snipsnap scans for newly available snippets:

on folder opening
on pressing command "Snipsnap: Feth the snippets" via the command palette All snippets currently present in this repository and follow the guidelines described below.

🗓️ Our plans and vision

The current version could be called MVP and it's there just for the one purpose – test the idea and get first feedbacks. If you like extension - star the repository, tell us about your experience or help us to improve the project.

We don't want to stop just on having snippets for Javascript. We want to make it standard for all popular languages and their package managers. So cover Ruby, Go, Python, PHP libraries also in our plans.

We believe that snippets could become a perfect solution for providing simple documentation and examples. Code snippets should become the part of packages repositories like README files. You build your library, you put snippets together with it in .snipsnap.json file and then we fetch it.

Having standardized collection could allow us to write extensions and converters for all popular IDE's, that will finally make code snippets independent from IDE. Let's say in a couple of years the new awesome IDE will be released, instead of writing a whole batch of snippets for new IDE you will be able to just continue using Snipsnap and the collection you already created.

💡 Your feedback matters

We are very curious to know what do you think about Snipsnap. Let us know by leaving a comment or submitting an issue on Github.

A simple guide for port forwarding Kubernetes resources

Alex Barashkov — Mon, 12 Aug 2019 10:25:55 +0000

Kubernetes changes the way how people deploy, orchestrate, and build their infrastructures. In this article, we will learn the simplest way of accessing your internal Kubernetes resources from your local machine.

💼 Use case

You deployed PostgreSQL to your cluster, and you don't want to expose it publicly, but want to make some queries and access DB.

🎉 Solution

Use Kubernetes native port-forwarding functionality. Specific Kubernetes API allows creating a tunnel from your cluster resource to your localhost over a single HTTP connection. As a result, you can access at your localhost 5432 port PostgreSQL from your Kubernetes cluster.

You could do it with kubectl,

kubectl port-forward -n default deployment/postgres 8432:5432

or you could use very simple open-source GUI – Kube Forwarder. Having CLI tool is excellent, but it does not have a few essential features

Auto-reconnect(if your connection is not so stable, you will have manually rerun the command)
Auto-complete(you always need to keep in mind names of your services, namespaces, I had some hints in notes)
Multiple cluster support (switch context each time you want to forward something is not a great experience as well)

So keeping that in mind we developed Kube Forwarder – easy to use Kubernetes port-forwarding manager.

Other important features we have:

Auto-import of kube config clusters
Import/Export all bookmarked clusters and resources(works well for sharing it with the team)
Forward multiple services at the same time
Zero native dependencies (works without kubectl CLI)

How to forward resources with Kube Forwarder❓

It's very simple three steps process if you do it first time –

Add a cluster configuration
Find resource you want to forward
Start forwarding

Add a cluster configuration

If you already have kubeconfig file, Kube Forwarder will suggest you to import clusters you have:

We also have other options:

Add clusters by choosing one or multiple files
Paste your config as a plain text. It could be useful if you created a new cluster and want to get access to some deployments
Restore the configuration from Kube Forwarder JSON. Useful when you as a devops want to prepare easy to use forwarding for your dev team who are not well familiar with Kubernetes.

Find the resource you want to forward

Kube Forwarder has autocomplete by namespaces, pods, deployments, so it makes the process of adding a new resource for forwarding very simple.

Set as a local port - port from your local machine and resource port – the port where your app launched. Other fields I think don't need extra clarification.
Once you added the resource - press "Play" button and access your service from your local machine.

🙏 We're looking for your feedback

We believe that apps like this could make you more productive and attract more people to start using Kubernetes. Let us know what do you think about the app and your ideas how could we make it better.

We built the app with Electron, so it works well on macOS, Windows and Linux.

Github - ⭐ https://github.com/pixel-point/kube-forwarder

Automate NPM packages security fixes with recurring tasks on CI

Alex Barashkov — Thu, 09 May 2019 09:42:59 +0000

When developing on Node.js, our team uses a lot open source NPM packages. Each of them has their own benefits and drawbacks that they bring to your project. In this article, we will discuss:

Cost-free options for vulnerability testing NPM dependencies
Drone CI configuration for running recurring checks
Auto Pull Request creation with fixed packages

NPM audit and more

The first thing that comes to mind when we talk about vulnerability audits is the NPM audit tool. This tool uses a publicly available vulnerability catalog to check your project and propose library version updates to fix any issues discovered. You can read more in the official NPM blog here.

Another good, free report that still uses out-of-the-box available options is npm outdated. This report uses a command check registry to see if any installed packages are currently outdated. That information is not necessarily useful for day-to-day work, but good to know for the long term, so you’re less tempted to simply abandon a project.



$ npm outdated
Package      Current   Wanted   Latest  Location
glob          5.0.15   5.0.15    6.0.1  test-outdated-output
nothingness    0.0.3      git      git  test-outdated-output
npm            3.5.1    3.5.2    3.5.1  test-outdated-output
local-dev      0.0.3   linked   linked  test-outdated-output
once           1.3.2    1.3.3    1.3.3  test-outdated-output

Automated npm outdated reports

These tools are very useful, but, of course, automated reports are even better. For this purpose, we use Drone CI(free and open source) and the new feature, Cron Jobs, to set recurring tasks. You’re free to use any other CI you like, however, which will probably support the same functionality. For those not familiar with Drone CI, read my Getting Started article here.

Since Drone CI supports multiple pipelines, each report has its own pipeline and does not affect the main one. For a wider look, check out the example here. In the meantime, let’s begin with npm outdated.



kind: pipeline
name: npm outdated

steps:
- name: outdated
  image: node:10-alpine
  commands:
    - npm outdated

- name: slack_notification
  image: plugins/slack
  settings:
    webhook: https://hooks.slack.com/services/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
    template: >
      NPN detected outdated packages at *{{repo.name}}* for *{{build.branch}}* branch. 
      Report available by the link {{build.link}}
  when:
    status:
    - failure

trigger:
  cron: [ weekly ]

We think the yaml syntax speaks well by itself. In the first step, we use node:10-alpine as a base image and run npm outdated. In the second step, a Slack notification is executed only if there is something to update(npm outdated exited with error exit code). To get the Slack webhook URL, visit this page

In the latest lines, the whole pipeline is triggered by the Cron Job labeled “outdated.” For our projects, we set that job for weekly execution, since we don’t plan to update packages everytime a new release comes.

To define the task in Drone, go to Project -> Settings.

Through this interface, you can choose the name of the job (which is used for pipeline filtering), the branch and the interval, which can be hourly, daily, weekly, monthly or yearly.

Automated npm audit and fix PR creation

The npm audit command will check your app for vulnerabilities and update packages to any version current version where needed. The pipeline is very similar to the previous one, but with an extra step involving PR creation.



kind: pipeline
name: npm audit

steps:
- name: audit
  image: node:10-alpine
  commands:
    - set -o pipefail && npm audit --force 2>&1 | tee audit.log

- name: audit fix
  image: node:10-alpine
  commands:
    - npm audit fix
  when:
    status:
    - failure

- name: create_fix_pr
  image: lnikell/github-hub:2.11.2
  environment:
    GITHUB_TOKEN:
      from_secret: github_token
  commands:
    - git config --global user.email "email@example.com"
    - git config --global user.name "example"
    - git checkout -b drone/npm-audit-fix-${DRONE_BUILD_NUMBER}
    - git add package.json package-lock.json
    - git commit -m 'npm audit fix'
    - git push origin drone/npm-audit-fix-${DRONE_BUILD_NUMBER}
    - hub pull-request -m "[Security] NPM Audit Fix" -m "$(cat audit.log | tail -2)" -m "${DRONE_BUILD_LINK}"
  when:
    status:
    - failure

- name: slack_notification
  image: plugins/slack
  settings:
    webhook: https://hooks.slack.com/services/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
    template: >
      NPN detected vulnerable packages at *{{repo.name}}* for *{{build.branch}}* branch. 
      Report available by the link {{build.link}}
  when:
    status:
    - failure

In the first step, we use the same node:10-alpine image and run NPM audit. We also save an audit.log file containing the results in order to output to PR later. If vulnerable packages were found during the npm audit, the next step will fail, trigger the nmp audit fix process and pull request creation.



-name: audit fix
 image: node:10-alpine
 commands:
   - npm audit fix
 when:
   status:
   - failure

In order to create a pull request, we use hub – the command line tool for dealing with Github API. We need to generate a Github Personal Token to use it for an API call. Go to this page and create a new one: https://github.com/settings/tokens

Select “repo” permissions scope, then add your generated token to secrets in Drone with the name “github_token”.

This is used as environment variable in the step below.



- name: create_fix_pr
 image: lnikell/github-hub:2.11.2
 environment:
   GITHUB_TOKEN:
     from_secret: github_token
 commands:
   - git config --global user.email "lnikell@gmail.com"
   - git config --global user.name "drone"
   - git checkout -b drone/npm-audit-fix-${DRONE_BUILD_NUMBER}
   - git add package.json package-lock.json
   - git commit -m 'npm audit fix'
   - git push origin drone/npm-audit-fix-${DRONE_BUILD_NUMBER}
   - hub pull-request -m "[Security] NPM Audit Fix" -m "$(cat audit.log | tail -2)" -m "${DRONE_BUILD_LINK}"
 when:
   status:
   - failure

In this step, we declare the pattern for branch creation and create a pull request with the last two lines from the audit.log. This gives us a nice PR:

Finally, we need to look at the trigger part of the pipeline. Since you only want to execute those checks as a part of Cron job, you need to add the following:



trigger:
 cron: [ name_of_the_job ]

However, remember that you still need think about your main pipeline. To prevent it from running during the Cron tasks, you have to use the exclude option like this:



trigger:
 cron:
   exclude: [ name_of_the_job ]

See an example giving you a useful overview of all pipelines here.

Conclusion

That was just one example of how recurring tasks on CI can be useful to you for the purposes of building, testing and fixing. You only have to set up it once and you’ll be informed of the security of your project on a daily/weekly basis. The approach we use in our examples should be easily adaptable for Travis CI or Gitlab; if you do it this way, please share your pipeline here.

If you like this article, subscribe to my Twitter or DEV.TO pages.

Forem: Alex Barashkov

Things you might not know about Next Image

Core Architecture

React Component

Image API

Image Optimizer

Outcomes

next/image does not crop

Displayed image width ≠ loaded image width

Image optimization can be used without the next/image component

Use import for local images

Understanding Sizes and the 100vw Technique

Conclusions

Use Google Analytics to uncover the truth about dark and light mode user's preferences

Summary

Advanced web font optimization techniques

Quick basics

Now let’s talk about advanced optimization

Fallback font metric adjustments

Custom subsetting

Custom fonts subsetting

Vertical baseline fixes

Fixing fonts with Font Squirrel

Using Capsize

Summary

Optimization techniques for Rive animations in React apps

What is Rive?

What can we optimize?

Room for improvement

Host WASM yourself

Preload WASM

Preload .riv animation

Results

Rive lazy loading

Rive, React.lazy and Suspense

That’s it!

Gatsby Graphql schema customization for beginners

What is Gatsby’s Schema Customization API?

Use cases

Replacing data in the existing Graphql field

Add a new field to the existing Graphql type and fill it with some data

Define relationships between Graphql types

Summary

Comparing Gatsby and Next.js for website development

Everything begins or ends with Favicon

Future is here with image optimization

Importance of CMS Integrations

To preview or not to preview?

Flexibility for editors with programmatic page generation

We demand Incremental Static Regeneration!

Data queries everywhere

Very external imports

Sitemaps are good everywhere

Smartless i18n

Summary

Measuring Gatsby projects build time using paid plans of popular static website hosting platforms

Table Of Contents

Platforms

Test cases

Markdown-based website

Clean cache build time

Deploy Preview build time

Warm cache build time

Headless WordPress website

Clean cache build time

Deploy Preview build time

Warm cache build time

Bonus

Winners

How to hide Feature A and show Feature B for different users in React

Overview

Flagsmith / flagsmith

Open Source Feature Flagging and Remote Config Service. Host on-prem or use our hosted version at https://flagsmith.com/

Our goal

Pre-requirements

Configure Flagsmith environment

Here you go!

Top 10 open-source SaaS that could help you build the next big thing

Hasura

hasura / graphql-engine