DEV Community: Yuta Kusuno

[Rails] How We Reduced API Response Rendering Time by 30%

Yuta Kusuno — Sun, 02 Feb 2025 03:17:21 +0000

I work on the backend team supporting an SNS with 170K users, built using Ruby on Rails.

We use Jbuilder to create API response payloads. However, we noticed that a significant portion of our response time was taken up by rendering partials. So, we decided to tackle this performance issue. In the end, we managed to reduce rendering time by 30%, and I'd like to share how we did it.

What is Jbuilder?

Jbuilder is a domain-specific language (DSL) integrated into Ruby on Rails for generating JSON responses. It allows you to intuitively build JSON responses as if you’re writing a view. However, performance issues can arise when handling large amounts of data.

Background of the Issue

In our application, building a single response payload often involves calling over 20 to 30 partial files. Some partial files that process large data sets took as much as 500ms to render.

By using New Relic to analyze the time spent on each segment, we found that partial rendering occupied the largest part of our API response time, followed by SQL execution.

The distribution of response times over a timeline is shown below. ( To clearly illustrate the situation, I tried to hand-draw the diagrams. )

During peak times, SQL execution times increase, but the cost of rendering remains relatively stable, regardless of the time of day.

Our team has been discussing query index optimization for several years. Due to the complexity of our data structure, we see it as a long-term challenge. This time, we chose to focus on rendering, which we could address in the short to medium term.

Identifying the Bottleneck

When investigating the partial! method used for rendering partial files, I found many questions about its performance on GitHub issues and discussions.

Looking at the implementation in Jbuilder repository, I discovered that within the partial! method, the render method of the ActionView context is called, aside from the separate template file lookup process.

# https://github.com/rails/jbuilder/blob/main/lib/jbuilder/jbuilder_template.rb

def _render_partial(options)
  options[:locals].merge! json: self
  @context.render options
end

It seems that the overhead of the render method and the cost of file lookup are key factors causing the slowdown in rendering performance.

As an experiment, I measured rendering times by moving the operations from partial files directly into the caller, without using the partial! method.

I used the rack-mini-profiler gem to measure performance in our development environment. I prepared hundreds of thousands of data entries in the development environment and gathered samples from 10 requests.

First, the existing implementation:

Next, the implementation with operations moved to the caller:

Remarkably, the average rendering time was reduced from 289.02ms to 166.22ms, a 42.5% decrease. I also confirmed that rendering nearly empty partial files 100 times only resulted in a delay of a few milliseconds.

At this point, it became clear that the partial! method could be a bottleneck with large data volumes due to the render method. However, given that our application manages hundreds of APIs, reducing partial! method calls would make the code harder to maintain and is not a practical solution.

I was responsible for the entire task, from investigation to implementation, testing, and validation, as our backend team consisted of only three people, including myself. Since there wasn’t much internal knowledge about rendering, coordinating from scratch with the iOS and Android teams for response payload caching or redesign would take time and make it difficult to balance impact with effort.

Next, I investigated template engines. The first one I explored was a gem called jb, maintained by Ruby/Rails committer Matsuda-san. I replaced Jbuilder with it but didn’t see significant improvements.

Other candidates included the following gems such as alba, active_model_serializers, and jsonapi-serializer. Considering team-wide adoption and maintenance, we preferred gems with syntax similar to Jbuilder if possible.

By chance, while browsing a site called daily.dev, I searched for Jbuilder alternatives and found an article about a gem called props_template. This gem will be the focus today.

About props_template

props_template is a library that allows lightweight and fast JSON generation, with syntax similar to Jbuilder. It's developed by thoughtbot, which is familiar with factory_bot.

You can easily convert existing Jbuilder code, making migration straightforward with search and replace on your editor. Switching from it involves minimal review work, offering a low barrier to adoption. Since it can coexist with Jbuilder, you can use props_template for just part of your project.

Partial rendering in props_template can be done in two main ways: with a key and without a key. The array! method differs from Jbuilder's partial! method, featuring optimized logic in props_template that could reduce rendering times.

Partial rendering with a key

json.posts do
  json.array! @posts, partial: ["posts/post"] do
  end
end

Partial rendering without a key

json.partial! partial: "posts", locals: {posts: @posts} do
end

In props_template, the partial! method also calls the render method on the context, similar to Jbuilder. Considering the potential cost, we chose not to use it.

# https://github.com/thoughtbot/props_template/blob/main/lib/props_template/base.rb

def partial!(**options)
  @context.render options
end

Now, let's replace the Jbuilder implementation with props_template and check the benchmarks in the development environment. The entire process, including refactoring, took about only two days.

The existing implementation with Jbuilder:
(The same one we saw on the Identifying the Bottleneck section)

After replacing it with props_template:

The sample size was the same as before. The average rendering time was reduced from 289.02ms to 151.34ms, a 47.6% decrease.

Because the syntax is similar to Jbuilder, reaching an agreement within the backend team was very smooth. Our PM also said, "Let's prioritize and try it out," so we began with replacing one of the APIs.

Implementation Process

Schema Testing

Before replacing Jbuilder, we introduced schema testing using the committee-rails gem to ensure that the JSON schema generated by props_template matched exactly with Jbuilder.

Our API specifications were managed with Open API, so we integrated it into committee-rails to conduct schema tests in our request specs. Since the Open API documentation formed the basis of our tests, we took time to review the payload schemas thoroughly.

Converting Templates

I began converting the Jbuilder to props_template. We decided to manage prop files within a new directory named props_template.

app/
└── views/
    ├── api/
    │   └── v1/
    │       ├── users/
    │       │   ├── index.json.jbuilder
    │       │   ├── show.json.jbuilder
    │       └── props_template/ # New directory
    │           └── users/
    │               ├── index.json.props
    │               └── show.json.props
    ├── layouts/
         └── props_template/ # New directory
             └── api.json.props
         └── api.json.jbuilder

In the controller, we specified templates using the render method.

The use_props_template? method is mainly for the testing environment. For example, if you specify 'Jbuilder' in params[:template_engine], you can test Jbuilder templates in the test environment.

Testing both templates allows for seamless switching to Jbuilder during validation. You simply change the default from true to false.

class Api::V3::UsersController < Api::ApplicationController
  def index
    # do something

    if use_props_template?(default: true)
      render 'api/v1/props_template/users/index', layout: 'layouts/props_template/api.json'
      return
    end
  end

  private

  def use_props_template?(default: true)
    return default unless Rails.env.test?
    params[:template_engine] == 'props_template'
  end
end

Observations in the Production Environment

We used New Relic to gather data in the production environment. From the graph, you can see that starting from the release date, overall volatility decreased and response times improved. The vertical axis shows response time, and the horizontal axis shows dates.

Examining performance a week before and after, rendering time improved by about 30%.

Rendering time	Average
Before	775.0466 ms
After	544.2676 ms

For response time, which the backend team primarily references as the 95th percentile response time, there was a reduction from 2.11s to 1.57s, marking an improvement of about 26%.

Response time	Average	Median	95th percentile	99th percentile
Before	1.41s	1.32s	2.11s	2.67s
After	1.15s	1.1s	1.57s	1.99s

Conclusion

The API we tested was one of the heavier ones, so there were many areas for improvement, but seeing such significant progress in less than a month was encouraging.

While examples of improving partial rendering with props_template are still limited, we’ve gathered positive internal insights over the past month and plan to apply similar improvements to other APIs.

Additionally, there are still numerous layers for improvement, such as data structure, SQL indexing, caching, and removing unnecessary fields, which we did not address this time. We aim to continue enhancing these areas in the future.

That is about it. Happy coding!

[Rails] count vs length vs size with Samples and a Diagram

Yuta Kusuno — Sat, 29 Jun 2024 04:53:47 +0000

When working with Active Record in Ruby on Rails, we often need to count the number of records. There are three main methods for this: .count, .length, and .size. Each of these methods behaves differently, and understanding these differences can help you write more efficient code.

Rails version

7.1.3.4

The .count Method

The .count method always performs a COUNT query to the database. This is true regardless of whether the records are loaded into memory or not. Here’s an example:

posts = Post.all
posts.count
# Post Count (1.8ms) SELECT COUNT(*) FROM "posts"
# => 1000

posts = Post.all; posts.count; posts.count
# Post Count (3.9ms) SELECT COUNT(*) FROM "posts"
# Post Count (0.7ms) SELECT COUNT(*) FROM "posts"
# => 1000

Even if the records are already loaded into memory, .count will still perform a COUNT query:

posts = Post.all.load
# Post Load (2.6ms) SELECT "posts".* FROM "posts"
# => [#<Post id: 1...
posts.count
# Post Count (1.2ms) SELECT COUNT(*) FROM "posts"
# => 1000

The .length Method

On the other hand, the .length method loads the records into memory if needed. So, if the records are already loaded, .length will return the number of records without performing a new query:

posts = Post.all
# Post Load (1.0ms) SELECT "posts".* FROM "posts" /* loading for pp */ LIMIT $1  [["LIMIT", 11]]
posts.length
# Post Load (3.3ms) SELECT "posts".* FROM "posts"
# => 1000

posts = Post.all; posts.length; posts.length
# Post Load (4.2ms) SELECT "posts".* FROM "posts"
# => 1000

The .size Method

Lastly, the .size method performs a COUNT query if the records are not loaded. However, if the records are already loaded, .size will return the number of records without performing a new query:

posts = Post.all
# Post Load (0.5ms) SELECT "posts".* FROM "posts" /* loading for pp */ LIMIT $1  [["LIMIT", 11]]
posts.size
# Post Count (0.9ms) SELECT COUNT(*) FROM "posts"
# => 1000

posts = Post.all; posts.size; posts.size
# Post Count (1.2ms) SELECT COUNT(*) FROM "posts"
# Post Count (1.0ms) SELECT COUNT(*) FROM "posts"
# => 1000

posts = Post.all.load; posts.size; posts.size
# Post Load (6.3ms) SELECT "posts".* FROM "posts"
# => 1000

Review count vs length vs size with a Diagram

Each of these methods is similar, but I think you'll find that they work differently than you might imagine. If we can understand them, we can choose the appropriate method and optimize the performance of our application.

That is about it. Happy coding!

[Hono] Simple Messaging App Using Bun and WebSocket

Yuta Kusuno — Mon, 10 Jun 2024 01:11:38 +0000

We often see implementations of WebSocket using the Express framework and Socket.io. However, there seem to be fewer examples of WebSocket implementations using Hono, a framework that is similar to Express but faster and lighter. In this article, I will introduce the implementation of a simple messaging app using Hono and Bun, a JavaScript runtime.

This project has a simple structure, and it is possible to extend various features such as database utilization and multiple room management functions. Initially, I aimed to write an article focused on WebSocket that could be read in less than 3 minutes, but I was drawn in by the charm of Hono, and the volume of the article increased more than expected. Now, let’s move on to the details.

Tech Stack

Frontend:

React
TypeScript
WebSocket API

Backend:

Hono
TypeScript

JavaScript Runtime(Both Frontend and Backend):

Bun v1.1.8

Project Structure

├── frontend
│   ├── src
│   │   ├── App.css
│   │   ├── App.tsx
│   │   ├── index.css
│   │   ├── main.tsx
│   │   └── vite-env.d.ts
│   ├── bun.lockb
│   ├── index.html
│   ├── package.json
│   ├── tsconfig.json
│   ├── tsconfig.node.json
│   └── vite.config.ts
├── server
│   └── index.ts
├── shared
│   ├── constants.ts
│   └── types.ts
├── bun.lockb
├── package.json
└── tsconfig.json

Root directory and server directory: Hono app
Frontend directory: React app
Shared directory: Constants and types used in common between frontend and backend

I have omitted settings files for TailwindCSS, etc. The structure is such that the Hono app wraps the React app. This was an easy-to-manage configuration when implementing RPC (Remote Procedure Call), where the frontend and backend share dependencies and type definitions of Hono.

Repository:
https://github.com/yutakusuno/bun-hono-react-websocket

UI

What is Hono?

Hono is a web application framework that is extremely fast and lightweight. It operates on any JavaScript runtime and includes built-in middleware and helpers. Its implementation is similar to Express, making it intuitive to use. It also features a clean API and first-class support for TypeScript.

For more details, visit: https://hono.dev/

What is Bun?

Bun is a JavaScript runtime and an all-in-one toolkit for JavaScript and TypeScript applications. It is written in Zig and internally uses JavaScriptCore, a performance-oriented JS engine created for Safari. It also implements Node.js and Web API natively and provides all the tools necessary to build JavaScript applications, including a package manager, test runner, and bundler.

For more details, visit: https://bun.sh/

What is WebSocket?

WebSocket is a protocol that creates a persistent bidirectional communication channel between a web browser and a server. With this technology, web applications can exchange data with the server in real-time without the client initiating a new HTTP request or reloading the page.

The operation of WebSocket goes through the following process:

Starting the handshake: The client sends the following HTTP request to the server, requesting an upgrade from HTTP to WebSocket.

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Server response: If the server supports WebSocket and agrees to the upgrade, the server responds with its own handshake, confirming the switch to the WebSocket protocol.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

Data transmission: While maintaining an open connection, the client and server can exchange data.

This diagram shows the basic flow of WebSocket communication between the client and server. First, the client requests an upgrade to WebSocket from the server via an HTTP request. Then, the server returns an HTTP response, confirming the protocol switch. This opens the connection, and the client and server can exchange data.

I would like to delve deeper into this area to understand it better, but that’s it for now.

The request and response examples for the handshake are quoted from the RFC.
https://datatracker.ietf.org/doc/html/rfc6455#section-1.2

Implementation

I will focus on key implementations by extracting parts from this repository. I want to explain as much as possible, including the import of dependencies and the definition of variables, so there are parts where the actual implementation has been rewritten as needed. If you want to understand in detail, please read the source code of the repository in parallel, treating this article as supplementary.

You can check out the completed application here: https://github.com/yutakusuno/bun-hono-react-websocket

Backend: WebSocket Configuration

server/index.ts

import { Hono } from 'hono';
import { createBunWebSocket } from 'hono/bun';

const app = new Hono();
const { upgradeWebSocket, websocket } = createBunWebSocket();
const server = Bun.serve({
  fetch: app.fetch,
  port: 3000,
  websocket,
});

export default app;

When launching an HTTP server with Bun, it is recommended to use Bun.serve. Pass an instance of the Hono class to this fetch handler and specify the port of the backend server. The websocket imported from createBunWebSocket is a Hono middleware, WebSocket handler, implemented for Bun.

Backend: WebSocket Connection and Disconnection

server/index.ts

import type { ServerWebSocket } from 'bun';

const topic = 'anonymous-chat-room';

app.get(
  '/ws',
  upgradeWebSocket((_) => ({
    onOpen(_, ws) {
      const rawWs = ws.raw as ServerWebSocket;
      rawWs.subscribe(topic);
      console.log(`WebSocket server opened and subscribed to topic '${topic}'`);
    },
    onClose(_, ws) {
      const rawWs = ws.raw as ServerWebSocket;
      rawWs.unsubscribe(topic);
      console.log(
        `WebSocket server closed and unsubscribed from topic '${topic}'`
      );
    },
  }))
);

The behavior when a WebSocket connection is opened and closed is defined. When a connection is opened, it starts subscribing to a specific topic synonymous-chat-room, and when a connection is closed, it ends that subscription. In this app, when an anonymous user opens a page, it establishes a WebSocket communication and starts subscribing to the topic. This time, there is no limit to the number of people who can subscribe to the same topic.

Subscription to topics is not directly supported in Hono’s implementation, so we need to use Bun’s ServerWebSocket. Specifically, this is achieved by extending the ws in onOpen. Looking at the source code of Hono, ws.raw is the WebSocket of the Bun server, and by using this, we can handle Bun native WebSocket and implement topic subscription. Pass any topic name as a string to subscribe and unsubscribe.

Hono’s implementation of Bun WebSocket:
https://github.com/honojs/hono/blob/main/src/adapter/bun/websocket.ts

Official documentation for Bun WebSocket:
https://bun.sh/docs/api/websockets

Backend: /messages Endpoint

server/index.ts

import { zValidator } from '@hono/zod-validator';
const messages: Message[] = [];

const messagesRoute = app
  .get('/messages', (c) => {
    return c.json(messages);
  })
  .post(
    '/messages',
    zValidator('form', MessageFormSchema, (result, c) => {
      if (!result.success) {
        return c.json({ ok: false }, 400);
      }
    }),
    async (c) => {
      const param = c.req.valid('form');
      const currentDateTime = new Date();
      const message: Message = {
        id: Number(currentDateTime),
        date: currentDateTime.toLocaleString(),
        ...param,
      };
      const data: DataToSend = {
        action: publishActions.UPDATE_CHAT,
        message: message,
      };

      messages.push(message);
      server.publish(topic, JSON.stringify(data));

      return c.json({ ok: true });
    }
  )
  .delete('/messages/:id', (c) => {
    // Logic of message deletion
  });

export type AppType = typeof messagesRoute;

This messages resource supports GET, POST, DELETE methods. The GET method retrieves the message history of users subscribing to the same topic, the POST method creates a new message, and the DELETE method deletes a specific message. Here, I will focus on explaining POST /messages.

The server instance was created when creating the Bun server for use in this endpoint. By calling publish() on the server instance, we can broadcast to all clients subscribing to the same topic. According to the official document, it is also possible to broadcast to all subscribers of the topic, excluding the socket that is called publish(), but it is not used this time.

Also, like Express, we can implement middleware on the endpoint by passing a handler before processing the logic of the resource. This is part of zValidator. This allows us to handle param in a type-safe manner.

In type AppType, the type of API defined in messagesRoute is exported. This is utilized in the RPC implementation on the frontend described later. By sharing the API specification with the client, we can achieve a type-safe API implementation.

shared/types.ts

import { z } from 'zod';

export const MessageFormSchema = z.object({
  userId: z.string().min(1),
  text: z.string().trim().min(1),
});

I used zod for the MessageFormSchema. By combining TypeScript and zod, we can implement more strict validation.

Frontend: Setting up WebSocket

frontend/src/App.tsx

const [messages, setMessages] = useState<Message[]>([]);

useEffect(() => {
  const socket = new WebSocket('ws://localhost:3000/ws');

  socket.onopen = (event) => {
    console.log('WebSocket client opened', event);
  };

  socket.onmessage = (event) => {
    try {
      const data: DataToSend = JSON.parse(event.data.toString());
      switch (data.action) {
        case publishActions.UPDATE_CHAT:
          setMessages((prev) => [...prev, data.message]);
          break;
        case publishActions.DELETE_CHAT:
          setMessages((prev) =>
            prev.filter((message) => message.id !== data.message.id)
          );
          break;
        default:
          console.error('Unknown data:', data);
      }
    } catch (_) {
      console.log('Message from server:', event.data);
    }
  };
  socket.onclose = (event) => {
    console.log('WebSocket client closed', event);
  };

  return () => {
    socket.close();
  };
}, []);

I create a WebSocket client and connect it to the server. I define the behavior for when the WebSocket connection is opened, when a message is received, and when the connection is closed. In socket.onmessage, I use a switch statement to branch based on the action type received from the backend. This allows us to handle various use cases.

// shared/constants.ts
export const publishActions = {
  UPDATE_CHAT: 'UPDATE_CHAT',
  DELETE_CHAT: 'DELETE_CHAT',
} as const;

// shared/types.ts
type PublishAction = (typeof publishActions)[keyof typeof publishActions];

export type Message = { id: number; date: string } & MessageFormValues;

export type DataToSend = {
  action: PublishAction;
  message: Message;
};

Here are the constants and type definitions used for WebSocket and message management. The PublishAction type infers the sum of the values of the publishActions object and extracts the enumeration type.

Frontend: Sending Messages

frontend/src/App.tsx

import { hc } from 'hono/client';
import type { AppType } from '@server/index';

const honoClient = hc<AppType>("http://localhost:3000");

const handleSubmit = async (e: FormEvent<HTMLFormElement>) => {
  e.preventDefault();
  try {
    const validatedValues = MessageFormSchema.parse(formValues);
    const response = await honoClient.messages.$post({
      form: validatedValues,
    });
    if (!response.ok) {
      throw new Error('Failed to send message');
    }

  } catch (error) {
    // Error Handling Logic
  }
};

In handleSubmit, I define the logic for sending a new message. When text is sent, it validates the input value and sends the new message as a POST request to the server.

What’s noteworthy is that I use the Hono client instead of the fetch API. I specify the AppType exported in the backend and the backend URL to hc, and define a type-safe honoClient. This enables the implementation of RPC. The gif below is a demo of TypeScript throwing a compile error when an incorrect data type value is passed to $post.

This allows us to implement a type-safe API by combining zod and RPC.

<form
  method="post"
  onSubmit={handleSubmit}
  className="flex items-center space-x-2"
>
  <input name="userId" defaultValue={formValues.userId} hidden />
  <input
    name="text"
    value={formValues.text}
    onChange={handleInputChange}
    className="flex-grow p-2 border border-gray-800 rounded-md bg-gray-800 text-white"
  />
  <button
    type="submit"
    className="px-4 py-2 bg-blue-500 text-white rounded-md"
  >
    Send
  </button>
</form>

The UI implementation is excerpted only for the message-sending form part. This configuration is simple, placing a message input tag and a message send button inside the form tag. When the send button is pressed, handleSubmit is triggered, and a request is sent to the backend.

That’s the introduction to the main implementation. Personally, I found that setting up WebSocket with Hono and Bun was not difficult, and I felt the difficulty level was equivalent to implementing WebSocket with Socket.io in Express. I was planning to write a post on WebSocket, but the implementation of a type-safe API using RPC with Hono also provided a very good development experience, so the post became long. I’m looking forward to future updates of Hono.

That is about it. Happy coding!

[TS] Consider Type-Safe localStorage

Yuta Kusuno — Sun, 05 May 2024 04:57:55 +0000

This post was featured in Codeminer42 Dev Weekly #10 on Codeminer42 's engineering blog.

In a recent project, I had the chance to explore the use of local storage on the frontend, specifically focusing on type-safety. I would like to share my experiences and insights from this endeavor.

Data type

Initially, I was faced with a variety of data objects that needed to be handled. You might be curious as to why I chose to work with such objects in local storage. The reasons are specific to the project, so I will leave them out of our discussion for now.

src/types.ts

export type Item = {
  id: number;
  name: string;
};

There were a number of different types of objects similar to this one that presented challenges. To tackle this, I adopted an object-oriented programming approach. This strategy helped reduce development time and facilitated the early detection of unexpected errors through component reuse.

Custom Storage

Custom storage is a utility that offers generic local storage operations. These operations can be utilized by other specific local storage classes, which I will elaborate on later.

src/lib/custom-storage.ts

export class CustomStorage<T> {
  private key: string;

  constructor(key: string) {
    this.key = key;
  }

  public getItems(): T | null {
    try {
      const data = localStorage.getItem(this.key);
      if (!data) return null;

      return JSON.parse(data) as T;
    } catch (error) {
      throw new Error('Failed to retrieve items from storage');
    }
  }

  public setItems(items: T[]): void {
    try {
      localStorage.setItem(this.key, JSON.stringify(items));
    } catch (error) {
      throw new Error('Failed to set items in storage');
    }
  }

  public clearItems(): void {
    try {
      localStorage.removeItem(this.key);
    } catch (error) {
      throw new Error('Failed to clear items from storage');
    }
  }
}

The custom storage has three public methods: getItems, setItems, and clearItems. These methods operate the local storage API in a basic way, with any errors being handled as exceptions.

Items Storage

The ItemsStorage instance and its public methods are invoked in event handlers, such as those triggered by onClick. Initially, I thought of having this class inherit from the CustomStorage class. However, I realized that local storage itself is indifferent to data inconsistency. So, I implemented a polymorphism-like approach to check for data inconsistencies.

In the actual project, I have created similar classes like ItemsStorageA, ItemsStorageB, and ItemsStorageC.

src/lib/items-storage.ts

import { Item } from '../types';
import { CustomStorage } from './custom-storage';
import { isValidItems, isValidItemFields } from '../utils';

const STORAGE_ITEMS_KEY = 'items';

class ItemsStorage {
  private static instance: ItemsStorage;
  private storage: CustomStorage<Item>;

  private constructor() {
    this.storage = new CustomStorage<Item>(STORAGE_ITEMS_KEY);
  }

  public static getInstance(): ItemsStorage {
    return this.instance ?? (this.instance = new ItemsStorage());
  }

  public getItems(): Item[] | null {
    try {
      const items = this.storage.getItems();
      if (!isValidItems(items)) {
        throw new Error('Invalid items');
      }

      return items;
    } catch (error: unknown) {
      this.logError(error);
      return null;
    }
  }

  public setItem(item: Item): void {
    try {
      if (!isValidItemFields(item)) {
        throw new Error('Invalid item fields');
      }

      const currentItems = this.storage.getItems();
      if (!isValidItems(currentItems)) {
        throw new Error('Invalid items');
      }

      const items: Item[] = [...currentItems, item];
      this.storage.setItems(items);
    } catch (error: unknown) {
      this.logError(error);
    }
  }

  public clearItems(): void {
    try {
      this.storage.clearItems();
    } catch (error: unknown) {
      this.logError(error);
    }
  }

  private logError(error: unknown): void {
    let errorMessage = 'An error occurred in ItemsStorage';
    if (error instanceof Error) {
      errorMessage += `: ${error.message}`;
    }
    console.error(errorMessage);
  }
}

export const itemsStorage = ItemsStorage.getInstance();

I designed ItemsStorage as a singleton, but it doesn’t necessarily have to be one. This was more a matter of convenience I wanted to avoid creating a new instance every time it was called. Since this class merely operates the local storage, we could instantiate it at the bottom of the file and export it.

When the getItems or setItem methods are invoked, they check for data consistency. If an inconsistency is detected in the existing data or in the data to be added, an error is thrown, and the data retrieval or addition operation is halted. One approach to handling invalid data during the addition process is to replace all the data with the new data, without stopping the process if even a single invalid data point is found. However, this method could potentially delay the discovery of bugs and compromise debugging efficiency.

The below utils.ts file contains several validation functions for the ItemsStorage class methods. These functions perform type checking and null checking. Originally, these were part of the ItemsStorage class, but I moved them to utils.ts. If there is a future need for active use of local storage more, I would like to further abstract these functions for reuse.

src/utils.ts

import { Item } from './types';

export function isValidItems(items: unknown): items is Item[] {
  if (!items || !Array.isArray(items)) {
    return false;
  }

  for (const item of items) {
    if (!isValidItemFields(item)) {
      return false;
    }
  }

  return true;
}

export function isValidItemFields(item: unknown): item is Item {
  if (!item || typeof item !== 'object') {
    return false;
  }

  if (!('id' in item) || !('name' in item)) {
    return false;
  }

  return idNumber(item.id) && isString(item.name);
}

export function idNumber(num: unknown): num is number {
  return typeof num === 'number';
}

export function isString(str: unknown): str is string {
  return typeof str === 'string';
}

Demo Page

Finally, I have prepared a demo page. This page includes three operations: retrieving items, adding an item, and clearing items, all of which are handled by event handlers.

src/App.tsx

import { itemsStorage } from './lib/items-storage';
import './App.css';

function App() {
  const handleAddItem = () => {
    const item = { id: Math.random(), name: 'Item' };
    itemsStorage.setItem(item);
  };

  const handleGetItems = () => {
    const items = itemsStorage.getItems();
    console.log('Items:', items);
  };

  const handleClearItems = () => {
    itemsStorage.clearItems();
  };

  return (
    <>
      <h1>localStorage Demo</h1>
      <div className='card'>
        <button onClick={handleAddItem}>Add Item</button>
        <button onClick={handleGetItems}>Get Items</button>
        <button onClick={handleClearItems}>Clear Items</button>
      </div>
    </>
  );
}

export default App;

Thank you for reading this article to the end. While it is unlikely we will often encounter the need to actively use local storage like this, if such a time comes again, I am confident that the lessons learned here will prove invaluable!!

I have summarized this demo in a repository. If you are interested, feel free to check it out!
https://github.com/yutakusuno/type-safe-local-storage

That is about it. Happy coding!

[Next.js] Firebase Authentication with Google Sign-in Using Cookies, Middleware, and Server Actions

Yuta Kusuno — Mon, 15 Apr 2024 00:56:46 +0000

This post provides a explanation of implementing user authentication in a Next.js 14 application using Firebase Authentication with Google sign-in. It utilizes cookies and server actions to effectively manage user sessions. Since this is a demo, there are no token updates or rigorous checking of tokens. Please customize it accordingly according to your project specifications.

Repository:
https://github.com/yutakusuno/nextjs-firebase-auth-google-signin

Overview

UI

As for the components I implemented, all I have is the home page and a very simple header. I have kept it simple so that you can easily utilize it in your projects.

Before signing in (localhost:3000/)

When a user clicks the sign in button

After signing in (localhost:3000/home)

Project Structure

├── actions                 // added
│   └── auth-actions.ts
├── app
│   ├── home                // added
│   │   └── page.tsx
│   ├── favicon.ico
│   ├── globals.css
│   ├── layout.tsx          // fixed
│   └── page.tsx
├── components              // added
│   └── header.tsx
├── hooks                   // added
│   └── use-user-session.ts
├── libs                    // added
│   └── firebase
│       ├── auth.ts
│       └── config.ts
├── public
├── .env                    // added
├── .eslintrc.json
├── .gitignore
├── .prettierrc.yaml
├── constants.ts            // added
├── middleware.ts           // added
├── next-env.d.ts
├── next.config.mjs
├── package-lock.json
├── package.json
├── postcss.config.mjs
├── README.md
├── tailwind.config.ts
└── tsconfig.json

Package Versions (Package.json)

{

  ...

  "dependencies": {
    "firebase": "^10.11.0",
    "next": "14.2.1",
    "react": "^18",
    "react-dom": "^18"
  },
  "devDependencies": {
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "eslint": "^8",
    "eslint-config-next": "14.2.1",
    "eslint-config-prettier": "^9.1.0",
    "postcss": "^8",
    "tailwindcss": "^3.4.1",
    "typescript": "^5"
  }
}

Code

Now let's look at the implementation.

Environment Variables

This environment file .env securely stores Firebase project configuration values (API key, auth domain, etc.).

If you have not yet set up your Firebase project, click here.

# .env

NEXT_PUBLIC_FIREBASE_API_KEY="your api key"
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN="your auth domain"
NEXT_PUBLIC_FIREBASE_PROJECT_ID="your project id"
NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET="you storage bucket"
NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID="your messaging sender id"
NEXT_PUBLIC_FIREBASE_APP_ID="your app id"

Firebase Configuration

The libs/firebase/config.ts file handles the initialization and configuration of the Firebase app.

// libs/firebase/config.ts

import { getAuth } from 'firebase/auth';
import { initializeApp, getApps } from 'firebase/app';

// Load .env variables
const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
  storageBucket: process.env.NEXT_PUBLIC_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.NEXT_PUBLIC_FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.NEXT_PUBLIC_FIREBASE_APP_ID,
};

const firebaseApp =
  getApps().length === 0 ? initializeApp(firebaseConfig) : getApps()[0];

export const firebaseAuth = getAuth(firebaseApp);

Initializes the Firebase app using initializeApp or retrieves an existing instance.
Exports the firebaseAuth instance for accessing Firebase authentication services.

Firebase Authentication

The libs/firebase/auth.ts file encapsulates Firebase authentication logic.

// libs/firebase/auth.ts

import {
  type User,
  GoogleAuthProvider,
  signInWithPopup,
  onAuthStateChanged as _onAuthStateChanged,
} from 'firebase/auth';

import { firebaseAuth } from './config';

export function onAuthStateChanged(callback: (authUser: User | null) => void) {
  return _onAuthStateChanged(firebaseAuth, callback);
}

export async function signInWithGoogle() {
  const provider = new GoogleAuthProvider();

  try {
    const result = await signInWithPopup(firebaseAuth, provider);

    if (!result || !result.user) {
      throw new Error('Google sign in failed');
    }
    return result.user.uid;
  } catch (error) {
    console.error('Error signing in with Google', error);
  }
}

export async function signOutWithGoogle() {
  try {
    await firebaseAuth.signOut();
  } catch (error) {
    console.error('Error signing out with Google', error);
  }
}

onAuthStateChanged: Listens for changes in the user's authentication state.
signInWithGoogle: Initiates Google sign-in using a popup window.
signOutWithGoogle: Signs out the current user from Firebase.

Constants

// constants.ts

export const ROOT_ROUTE = '/';
export const HOME_ROUTE = '/home';

export const SESSION_COOKIE_NAME = 'user_session';

Session Management in Server Actions

In actions/auth-actions.ts, it implements server actions for creating and removing session cookies.

// actions/auth-actions.ts

'use server';

import { cookies } from 'next/headers';
import { redirect } from 'next/navigation';

import { HOME_ROUTE, ROOT_ROUTE, SESSION_COOKIE_NAME } from '@/constants';

export async function createSession(uid: string) {
  cookies().set(SESSION_COOKIE_NAME, uid, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    maxAge: 60 * 60 * 24, // One day
    path: '/',
  });

  redirect(HOME_ROUTE);
}

export async function removeSession() {
  cookies().delete(SESSION_COOKIE_NAME);

  redirect(ROOT_ROUTE);
}

createSession: Sets a cookie named SESSION_COOKIE_NAME containing the user ID and redirects to the home page.
- HTTP-only: The cookie is flagged as HTTP-only, enhancing security by preventing client-side JavaScript from accessing its content.
- Secure: In a production environment, the secure flag is set, ensuring the cookie is transmitted only over HTTPS connections.
- Max Age: The cookie expires after one day (24 hours) of inactivity.
removeSession: Deletes the SESSION_COOKIE_NAME cookie and redirects to the root page.

Session Management in Client

In hooks/use-user-session.ts, it provides a custom hook for managing user sessions.

// hooks/use-user-session.ts

import { useEffect, useState } from 'react';

import { onAuthStateChanged } from '../libs/firebase/auth';

export function useUserSession(InitSession: string | null) {
  const [userUid, setUserUid] = useState<string | null>(InitSession);

  // Listen for changes to the user session
  useEffect(() => {
    const unsubscribe = onAuthStateChanged(async (authUser) => {
      if (authUser) {
        setUserUid(authUser.uid);
      } else {
        setUserUid(null);
      }
    });

    return () => unsubscribe();
  }, []);

  return userUid;
}

useUserSession:
- Accepts an initial session ID.
- Maintains the current user ID (userUid) in state.
- Listens for Firebase auth state changes using onAuthStateChanged.
- Returns the current userUid.

Application Layout

//app/layout.tsx

import type { Metadata } from 'next';
import { Inter } from 'next/font/google';
import { cookies } from 'next/headers';

import Header from '@/components/header'; // added
import { SESSION_COOKIE_NAME } from '@/constants'; // added
import './globals.css';

const inter = Inter({ subsets: ['latin'] });

export const metadata: Metadata = {
  title: 'Create Next App',
  description: 'Generated by create next app',
};

export default async function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  // added
  const session = cookies().get(SESSION_COOKIE_NAME)?.value || null;

  return (
    <html lang='en'>
      <body className={inter.className}>
        <Header session={session} /> // added
        {children}
      </body>
    </html>
  );
}

Retrieves the session cookie from the request headers.
Renders the Header component, passing the session as a prop.
Displays the application's content.

By passing session information from the RSC to the RCC, the Header component for authenticated users can be loaded from the beginning if the user is already logged in.

Header Component

// components/header.tsx

'use client';

import { useUserSession } from '@/hooks/use-user-session';
import { signInWithGoogle, signOutWithGoogle } from '@/libs/firebase/auth';
import { createSession, removeSession } from '@/actions/auth-actions';

export function Header({ session }: { session: string | null }) {
  const userSessionId = useUserSession(session);

  const handleSignIn = async () => {
    const userUid = await signInWithGoogle();
    if (userUid) {
      await createSession(userUid);
    }
  };

  const handleSignOut = async () => {
    await signOutWithGoogle();
    await removeSession();
  };

  if (!userSessionId) {
    return (
      <header>
        <button onClick={handleSignIn}>Sign In</button>
      </header>
    );
  }

  return (
    <header>
      <nav>
        <ul>
          <li>
            <a href='#'>Menu A</a>
          </li>
          <li>
            <a href='#'>Menu B</a>
          </li>
          <li>
            <a href='#'>Menu C</a>
          </li>
        </ul>
      </nav>
      <button onClick={handleSignOut}>Sign Out</button>
    </header>
  );
}

export default Header;

Uses useUserSession to get the current user's session ID.
Displays a sign-in button if the user is not signed in.
Displays a sign-out button and navigation links if the user is signed in.
Based on the event handlers (handleSignIn or handleSignOut), signing in or signing out process. At the same time, calling server actions createSession or removeSession.

Middleware

// middleware.ts

import { type NextRequest, NextResponse } from 'next/server';
import { HOME_ROUTE, ROOT_ROUTE, SESSION_COOKIE_NAME } from './constants';

const protectedRoutes = [HOME_ROUTE];

export default function middleware(request: NextRequest) {
  const session = request.cookies.get(SESSION_COOKIE_NAME)?.value || '';

  // Redirect to login if session is not set
  if (!session && protectedRoutes.includes(request.nextUrl.pathname)) {
    const absoluteURL = new URL(ROOT_ROUTE, request.nextUrl.origin);
    return NextResponse.redirect(absoluteURL.toString());
  }

  // Redirect to home if session is set and user tries to access root
  if (session && request.nextUrl.pathname === ROOT_ROUTE) {
    const absoluteURL = new URL(HOME_ROUTE, request.nextUrl.origin);
    return NextResponse.redirect(absoluteURL.toString());
  }
}

Identifies protected routes (e.g., home page).
Redirects users to the login page if they are not signed in and trying to access a protected route.
Redirects signed-in users to the home page if they try to access the root page.

Overall Implementation

The application utilizes the following flow:

The user visits the application.
The middleware checks the session cookie.
- If the user is not signed in and tries to access a protected route, they are redirected to the login page.
- If the user is signed in and tries to access the root page, they are redirected to the home page.
On the login page, the user clicks the "Sign In" button.
The signInWithGoogle function is called, initiating the Google sign-in process.
Upon successful sign-in, Firebase sends the user's profile information to the application.
The onAuthStateChanged function detects the user's signed-in state.
The useUserSession hook updates the userUid state.
The createSession function sets the session cookie and redirects the user to the home page.
The user can now navigate through the protected areas of the application.
To sign out, the user clicks the "Sign Out" button in the header.
The signOutWithGoogle function is called, signing the user out of Firebase.
The onAuthStateChanged function detects the user's signed-out state.
The useUserSession hook updates the userUid state to null and calls the removeSession.

If you like it, feel free to adjust the code snippets provided and have them customized to your project's specific requirements and preferences.

Repository:
https://github.com/yutakusuno/nextjs-firebase-auth-google-signin

That is about it. Happy coding!

[React] Passing Environment Variables to Service Workers

Yuta Kusuno — Thu, 18 Jan 2024 04:33:56 +0000

When working with Firebase Cloud Messaging in a React application, creating a service worker (the following firebase-messaging-sw.js) in the public directory becomes essential. However, handling environment-specific configurations, such as API keys, poses a challenge due to the inability to access environment variables using process.env within the public directory. This blog post explores two approaches to dynamically pass environment variables to the service worker.

// public/firebase-messaging-sw.js

// Give the service worker access to Firebase Messaging.
// Note that you can only use Firebase Messaging here. Other Firebase libraries are not available in the service worker.
importScripts('https://www.gstatic.com/firebasejs/8.10.1/firebase-app.js');
importScripts('https://www.gstatic.com/firebasejs/8.10.1/firebase-messaging.js');

// Initialize the Firebase app in the service worker by passing in your app's Firebase config object.
// https://firebase.google.com/docs/web/setup#config-object
firebase.initializeApp({
  apiKey: 'api-key',
  authDomain: 'project-id.firebaseapp.com',
  databaseURL: 'https://project-id.firebaseio.com',
  projectId: 'project-id',
  storageBucket: 'project-id.appspot.com',
  messagingSenderId: 'sender-id',
  appId: 'app-id',
  measurementId: 'G-measurement-id',
});

// Retrieve an instance of Firebase Messaging so that it can handle background messages.
const messaging = firebase.messaging();

Using a Separate Script to Build Environment Variables

Create a .env file with your Firebase configurations.

REACT_APP_FIREBASE_API_KEY = 'api-key'
REACT_APP_FIREBASE_AUTH_DOMAIN = 'project-id.firebaseapp.com',
REACT_APP_FIREBASE_PROJECT_ID = 'project-id'
REACT_APP_FIREBASE_STORAGE_BUCKET = 'project-id.appspot.com'
REACT_APP_FIREBASE_MESSAGING_SENDER_ID = 'sender-id'
REACT_APP_FIREBASE_APP_ID = 'app-id'
REACT_APP_FIREBASE_MEASUREMENT_ID = 'G-measurement-id'

Create a script (swEnvBuild.js) to build a JavaScript file (swEnv.js) containing the environment variables.

// src/swEnvBuild.js

const fs = require("fs");

// This dotenv is the one used inside React.
// Load dotenv Intentionally because build process does not have access to .env file yet.
const dotenv = require("dotenv");
dotenv.config();

const {
  REACT_APP_FIREBASE_API_KEY,
  REACT_APP_FIREBASE_AUTH_DOMAIN,
  REACT_APP_FIREBASE_PROJECT_ID,
  REACT_APP_FIREBASE_STORAGE_BUCKET,
  REACT_APP_FIREBASE_MESSAGING_SENDER_ID,
  REACT_APP_FIREBASE_APP_ID,
  REACT_APP_FIREBASE_MEASUREMENT_ID,
} = process.env;

const content = `const swEnv = {
    REACT_APP_FIREBASE_API_KEY: '${REACT_APP_FIREBASE_API_KEY}',
    REACT_APP_FIREBASE_AUTH_DOMAIN: '${REACT_APP_FIREBASE_AUTH_DOMAIN}',
    REACT_APP_FIREBASE_PROJECT_ID: '${REACT_APP_FIREBASE_PROJECT_ID}',
    REACT_APP_FIREBASE_STORAGE_BUCKET: '${REACT_APP_FIREBASE_STORAGE_BUCKET}',
    REACT_APP_FIREBASE_MESSAGING_SENDER_ID: '${REACT_APP_FIREBASE_MESSAGING_SENDER_ID}',
    REACT_APP_FIREBASE_APP_ID: '${REACT_APP_FIREBASE_APP_ID}',
    REACT_APP_FIREBASE_MEASUREMENT_ID: '${REACT_APP_FIREBASE_MEASUREMENT_ID}'
 }`;

fs.writeFileSync("./public/swEnv.js", content);

Modify the npm start command in package.json to run the build script before starting the development server. Only the npm start command is being modified for testing in the development environment. When deploying, I think it is necessary to modify the npm build command.

"scripts": {
- "start": "react-scripts start",
+ "start": "node src/swEnvBuild.js && react-scripts start",

Now, running npm run start will create public/swEnv.js.

// public/swEnv.js

const swEnv = {
  REACT_APP_FIREBASE_API_KEY: 'api-key',
  REACT_APP_FIREBASE_AUTH_DOMAIN: 'project-id.firebaseapp.com',
  REACT_APP_FIREBASE_PROJECT_ID: 'project-id',
  REACT_APP_FIREBASE_STORAGE_BUCKET: 'project-id.appspot.com',
  REACT_APP_FIREBASE_MESSAGING_SENDER_ID: 'sender-id',
  REACT_APP_FIREBASE_APP_ID: 'app-id',
  REACT_APP_FIREBASE_MEASUREMENT_ID: 'G-measurement-id'
}

Update public/firebase-messaging-sw.js to import and use the dynamically generated environment variables.

// public/firebase-messaging-sw.js

importScripts("https://www.gstatic.com/firebasejs/8.3.1/firebase-app.js");
importScripts("https://www.gstatic.com/firebasejs/8.3.1/firebase-messaging.js");
importScripts("swEnv.js"); // Added

firebase.initializeApp({
  apiKey: swEnv.REACT_APP_FIREBASE_API_KEY, // Changed... repeat for other variables
  authDomain: swEnv.REACT_APP_FIREBASE_AUTH_DOMAIN,
  projectId: swEnv.REACT_APP_FIREBASE_PROJECT_ID,
  storageBucket: swEnv.REACT_APP_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: swEnv.REACT_APP_FIREBASE_MESSAGING_SENDER_ID,
  appId: swEnv.REACT_APP_FIREBASE_APP_ID,
  measurementId: swEnv.REACT_APP_FIREBASE_MEASUREMENT_ID,
});

const messaging = firebase.messaging();

Using Query Parameters

Call registerServiceWorker in src/App.jsx to dynamically construct the service worker script URL with query parameters.

export const registerServiceWorker = async () => {
  let scriptURL = "firebase-messaging-sw.js";
  scriptURL += `?apiKey=${process.env.REACT_APP_FIREBASE_API_KEY}`;
  scriptURL += `&authDomain=${process.env.REACT_APP_FIREBASE_AUTH_DOMAIN}`;
  scriptURL += `&projectId=${process.env.REACT_APP_FIREBASE_PROJECT_ID}`;
  scriptURL += `&storageBucket=${process.env.REACT_APP_FIREBASE_STORAGE_BUCKET}`;
  scriptURL += `&messagingSenderId=${process.env.REACT_APP_FIREBASE_MESSAGING_SENDER_ID}`;
  scriptURL += `&appId=${process.env.REACT_APP_FIREBASE_APP_ID}`;
  scriptURL += `&measurementId=${process.env.REACT_APP_FIREBASE_MEASUREMENT_ID}`;

  if ("serviceWorker" in navigator) {
    try {
      const registration = await navigator.serviceWorker.register(scriptURL);
      if (registration.installing) {
        console.log("Service worker installing");
      } else if (registration.waiting) {
        console.log("Service worker installed");
      } else if (registration.active) {
        console.log("Service worker active");
      }
    } catch (error) {
      console.error(`Registration failed with ${error}`);
    }
  }
};

Update public/firebase-messaging-sw.js to extract query parameters and initialize Firebase.

// public/firebase-messaging-sw.js

importScripts("https://www.gstatic.com/firebasejs/8.3.1/firebase-app.js");
importScripts("https://www.gstatic.com/firebasejs/8.3.1/firebase-messaging.js");

const params = new URL(location).searchParams;
const apiKey = params.get("apiKey");
const authDomain = params.get("authDomain");
const projectId = params.get("projectId");
const storageBucket = params.get("storageBucket");
const messagingSenderId = params.get("messagingSenderId");
const appId = params.get("appId");
const measurementId = params.get("measurementId");

firebase.initializeApp({
  apiKey: apiKey,
  authDomain: authDomain,
  projectId: projectId,
  storageBucket: storageBucket,
  messagingSenderId: messagingSenderId,
  appId: appId,
  measurementId: measurementId,
});

const messaging = firebase.messaging();

Both approaches provide solutions for passing environment variables to service workers in a React application. Choose the approach that best fits your project requirements and development workflow. Additionally, alternative methods, such as using Webpack and Babel or workbox-webpack-plugin with InjectManifest are available. I will try these as well when I get a chance.

That is about it. Happy coding!

[JS] CommonJS vs. ES Modules: Synchronous and Asynchronous Module Loading

Yuta Kusuno — Mon, 15 Jan 2024 03:25:40 +0000

JavaScript employs two main module systems: CommonJS using require() and module.exports for imports and exports, and ECMAScript Modules (ESM), defined in the ECMAScript standard, utilizing import and export. CommonJS features synchronous module loading, while ESM brings asynchronous loading. I will explore and compare each module loading process.

CommonJS Example

In the CommonJS, module loading is synchronous. Consider the following code structure:

cjs.js:

console.log("cjs start");

require("./test1");
require("./test2");
require("./test3");

console.log("cjs end");

test1.js:

console.log("test1");

test2.js:

console.log("test2");

test3.js:

console.log("test3");

Execute the following command to observe synchronous module loading in action:

NODE_DEBUG=module node cjs.js

The output would be:

Let us break down the code and understand the flow:

cjs.js: This is the main script that is executed. It starts by logging cjs start.
Next, the contents of the test1.js is loaded and the JavaScript code is evaluated and executed. Then, similarly test2.js and test3.js are executed.
While loading the modules synchronously, each module (test1.js, test2.js, and test3.js) logs its respective message.
After all required modules are loaded and executed, the main script continues to execute and logs cjs end.

Unlike imports in ESM, require in CommonJS is synchronous and blocks the execution of the main script until the required modules are loaded.

ES Modules Example

In the ES Modules, the loading paradigm shifts to asynchronous. Consider the following code structure:

esm.js:

console.log("esm start");

import("./test1.js");
import("./test2.js");
import("./test3.js");

console.log("esm end");

The content of test* files need not be changed. Execute the following command to confirm asynchronous module loading:

NODE_DEBUG=esm node esm.js

The output would be:

Let us break down the code and understand the flow:

esm.js is the main script that is executed. It starts by logging esm start.
Next, it uses dynamic imports to import and execute test1.js, test2.js, and test3.js. Dynamic imports are asynchronous, so they do not block the execution of the main script.
While the dynamic imports are in progress, esm.js continues to execute and logs esm end.
As the dynamic imports complete, each imported module (test1.js, test2.js, and test3.js) logs its respective message.

Therefore, the expected output reflects the asynchronous nature of dynamic imports, and you will see esm start and esm end logged first, followed by the logs from test1.js, test2.js, and test3.js.

CommonJS employs synchronous module loading, meaning that until one module is fully loaded, the loading of other modules is restricted. On the other hand, ESM Modules utilize asynchronous loading, enabling the concurrent loading of multiple modules. This characteristic is particularly advantageous as the number of modules to be loaded increases, potentially leading to improved performance.

That is about it. Happy coding!

[JS] What Happens When “use strict” Is Defined

Yuta Kusuno — Fri, 05 Jan 2024 02:35:32 +0000

JavaScript's "use strict" directive allows you to opt into a restricted variant of the language, enabling a more robust and error-prone coding environment. When "use strict" is defined, several changes occur in the behavior of your code, enhancing its reliability. In ES Modules available from (ES6)ES2015, it is always in strict mode though. In this post, I will explore various scenarios illustrating the impact of strict mode.

Declaration Before Assignment

In strict mode, attempting to assign a value to a variable without prior declaration results in a ReferenceError. For instance:

"use strict";
exampleVar = 1; // ReferenceError: exampleVar is not defined

Here, the absence of a declared variable exampleVar leads to a runtime error.

Restrictions on delete Operator

Strict mode imposes restrictions on the use of the delete operator with variables. An attempt to delete a variable declared with let raises a SyntaxError:

"use strict";
let exampleLet = 1;
delete exampleLet; // SyntaxError: Delete of an unqualified identifier in strict mode.

Duplicate Parameter Names

Strict mode disallows the use of duplicate parameter names within function declarations:

"use strict";
function exampleFunc(param1, param1) {} // SyntaxError: Duplicate parameter name not allowed in this context

This ensures parameter uniqueness and avoids potential confusion.

Octal Literals

Old-style octal literals are prohibited in strict mode. Instead, you should use the modern 0o prefix:

"use strict";
let oldOctal = 010; // SyntaxError: Octal literals are not allowed in strict mode.
let modernOctal = 0o10; // OK

Read-Only Properties

In strict mode, attempts to modify read-only properties result in a TypeError. Consider the following example:

"use strict";
const object = {};
Object.defineProperty(object, 'propertyX', {
  value: 0,
  writable: false,
});

object.propertyX = 1; // TypeError: Cannot assign to read only property 'propertyX' of object '#<Object>'

In this case, it sets writable: false, the result might be taken for granted. However, the TypeError does not occur without "use strict".

Reserved Keywords as Variable Names

Certain keywords such as private, package, and protected are reserved in strict mode and cannot be used as variable names:

"use strict";
var private = 1; // SyntaxError: Unexpected strict mode reserved word

Prohibition of 'with' Statement

The with statement is forbidden in strict mode due to its potential for creating ambiguous code. Any attempt to use it will result in a SyntaxError:

"use strict";
let area;
const radius = 1;
with (Math) {
  area = PI * radius * radius;
} // SyntaxError: Strict mode code may not include a with statement

Limited Visibility of `eval` Declarations

Declarations made within eval statements are not visible outside of the eval scope:

"use strict";
eval("var exampleVar = 1;");
console.log(exampleVar); // ReferenceError: x is not defined

Here, exampleVar is only defined within the eval statement, causing an error when trying to access it externally.

That is about it. Happy coding!

[JS] The Top-Level Scope Is NOT Always the Global Scope

Yuta Kusuno — Thu, 04 Jan 2024 02:45:33 +0000

Understanding the scope in JavaScript is crucial for writing robust and maintainable code. While in browsers, the top-level scope has historically been synonymous with the global scope. And it is also called the global object shared by all scripts. However, Node.js has a noteworthy distinction. The top-level scope is not the global scope. I will delve into the difference between the top-level scope in browsers and Node.js using globalThis, which can access to the global object in the both JavaScript environments.

The Global Scope in Browsers

In traditional browser environments, any code that does not specifically start up as a background task has a Window as its global object. When a variable is declared using var outside of any function or block, it becomes a global variable associated with the Window object. Let us illustrate this with a simple example:

// Browser Example

<script>
  var globalVar = "I am global";

  console.log(globalVar); // Outputs: I am global
  console.log(globalThis.globalVar); // Outputs: I am global
</script>

In this case, globalThis is the Window object. globalVar is accessible globally and can be accessed from the top-level scope associated with the Window object.

However, if I add the type="module" to the script tag, the result changes.

// Browser Example

<script type="module">
  var localVar = "I am local";

  console.log(localVar); // Outputs: I am local
  console.log(globalThis.localVar); // Outputs: undefined
</script>

ECMAScript evaluates the internal code as a Module rather than a Script. The top-level var creates a global variable in Script, while it does not in Module scope.

A Different Point in Node.js

On the other hands, Node.js has different behavior from browsers. Scripts running under Node.js have an object called global as their global object. Variables declared with var at the top level of a module are local to that module. Let us demonstrate this with an example.

// Node.js Example

var localVar = "I am local";

console.log(localVar); // Outputs: I am local
console.log(globalThis.localVar); // Outputs: undefined

In this case, localVar is scoped to the module, and attempting to access it from another module would result in an undefined variable.

In both Node.js CommonJS modules and native ECMAScript modules, top-level variable declarations are scoped to the module, and do not become properties of the global object.

That is about it. Happy coding!

[JS] Look Back on Hoisting

Yuta Kusuno — Wed, 03 Jan 2024 03:17:14 +0000

In JavaScript, understanding hoisting is crucial for any developer. Hoisting can be a tricky concept at first, but once you grasp it, you will have a solid foundation for writing efficient and error-free code. I will explore how it works, and provide examples to help you master this essential JavaScript concept.

What is Hoisting?

Hoisting is a JavaScript behavior where variable and function declarations are moved to the top of their containing scope during the compilation phase. This allows you to use variables and functions before they are declared in your code.

Variables Hoisting

Let us see an example:

console.log(a); // Output: undefined
var a = 5;
console.log(a); // Output: 5

In this example, the variable a is hoisted to the top of the scope during the compilation phase, resulting in the first console.log(a) printing undefined. However, the second console.log(a) prints 5 because the variable has been assigned the value by that point in the code.

Function Hoisting

Function declarations are also hoisted. Consider the following example:

sayHello(); // Output: Hello!

function sayHello() {
  console.log("Hello!");
}

In this case, the sayHello function is hoisted to the top of the scope, allowing us to call it before its actual declaration.

Variable Hoisting vs. Function Hoisting

It is important to note that while both variable and function declarations are hoisted, there are differences in how they are handled during hoisting. Function declarations are completely hoisted, including both the function name and its implementation. On the other hand, variable declarations are hoisted, but only the variable name is moved to the top, not the assignment.

console.log(myVariable); // Output: undefined
var myVariable = "I am hoisted!";

hoistedFunction(); // Output: "I am hoisted!"
function hoistedFunction() {
  console.log("I am hoisted!");
}

Good ideas

To avoid confusion and potential bugs related to hoisting, it is a good practice to declare variables at the top of their scope and define functions before using them.

That is about it. Happy coding!

DEV Community: Yuta Kusuno

[Rails] How We Reduced API Response Rendering Time by 30%

What is Jbuilder?

Background of the Issue

Identifying the Bottleneck

About props_template

Implementation Process

Schema Testing

Converting Templates

Observations in the Production Environment

Conclusion

[Rails] count vs length vs size with Samples and a Diagram

Rails version

The .count Method

The .length Method

The .size Method

Review count vs length vs size with a Diagram

[Hono] Simple Messaging App Using Bun and WebSocket

Tech Stack

Project Structure

UI

What is Hono?

What is Bun?

What is WebSocket?

Implementation

Backend: WebSocket Configuration

Backend: WebSocket Connection and Disconnection

Backend: /messages Endpoint

Frontend: Setting up WebSocket

Frontend: Sending Messages

[TS] Consider Type-Safe localStorage

Data type

Custom Storage

Items Storage

Demo Page

[Next.js] Firebase Authentication with Google Sign-in Using Cookies, Middleware, and Server Actions

Overview

UI

Project Structure

Package Versions (Package.json)

Code

Environment Variables

Firebase Configuration

Firebase Authentication

Constants

Session Management in Server Actions

Session Management in Client

Application Layout

Header Component

Middleware

Overall Implementation

[React] Passing Environment Variables to Service Workers

Using a Separate Script to Build Environment Variables

Using Query Parameters

[JS] CommonJS vs. ES Modules: Synchronous and Asynchronous Module Loading

CommonJS Example

ES Modules Example

[JS] What Happens When “use strict” Is Defined

Declaration Before Assignment

Restrictions on delete Operator

Duplicate Parameter Names

Octal Literals

Read-Only Properties

Reserved Keywords as Variable Names

Prohibition of 'with' Statement

Limited Visibility of eval Declarations

[JS] The Top-Level Scope Is NOT Always the Global Scope

The Global Scope in Browsers

A Different Point in Node.js

[JS] Look Back on Hoisting

What is Hoisting?

Variables Hoisting

Function Hoisting

Variable Hoisting vs. Function Hoisting

Good ideas

Limited Visibility of `eval` Declarations