Forem: Daniel Santos

Migrando do esbuild para o rspack em Funções AWS Lambda: Guia Prático com AWS SAM e Makefile

Daniel Santos — Fri, 07 Mar 2025 12:33:21 +0000

Nos últimos anos, o ecossistema de ferramentas para desenvolvimento em JavaScript e TypeScript tem evoluído rapidamente, oferecendo opções cada vez mais eficientes para construir e otimizar aplicações. Uma dessas ferramentas que tem ganhado destaque é o rspack , um bundler moderno baseado em Rust que combina desempenho excepcional com compatibilidade com o Webpack, permitindo aproveitar plugins e configurações já conhecidas no mercado.

Recentemente, ao trabalhar em uma função AWS Lambda utilizando o AWS SAM, decidi migrar o processo de build do esbuild para o rspack. Essa mudança não foi motivada por limitações do esbuild , que continua sendo uma excelente escolha, mas sim pela busca por padronização e flexibilidade em meus projetos.

Neste tutorial, compartilho o passo a passo dessa migração, desde a instalação do rspack até a configuração do AWS SAM para utilizar um Makefile personalizado. O objetivo é fornecer um guia prático para quem deseja explorar essa ferramenta em seus próprios projetos, seja para funções Lambda ou outras aplicações baseadas em Node.js.

Substituindo o esbuild pelo rspack

A primeira etapa da migração é substituir o esbuild pelo rspack no projeto

yarn add -D @rspack/cli @rspack/core terser-webpack-plugin
yarn remove esbuild

Para facilitar o processo de build, adicionaremos um script ao package.json. Esse script será responsável por executar o comando de build do rspack sempre que necessário:

"scripts": {
    ...
    ...
    "build": "rspack build",
    ...
    ...
  },

Com isso, você poderá rodar yarn build para gerar o bundle da função Lambda diretamente a partir do terminal, simplificando o fluxo de trabalho.

Configurando o rspack

O próximo passo é criar o arquivo de configuração do rspack, o rspack.config.cjs. Esse arquivo define como o código será empacotado, incluindo entradas, saídas, regras de processamento e otimizações.

const path = require('path');
const minify = require('terser-webpack-plugin');

module.exports = {
    mode: 'production',
    target: 'node',
    entry: './app.ts',
    resolve: {
        extensions: ['.ts', '.js']
    },
    module: {
        rules: [
            {
                test: /\.ts$/,
                exclude: [/node_modules/],
                loader: 'builtin:swc-loader',
                options: {
                    jsc: {
                        parser: {
                            syntax: 'typescript',
                        },
                    },
                },
                type: 'javascript/auto',
            },
        ],
    },
    output: {
        filename: 'app.js',
        path: path.resolve(__dirname, 'dist'),
        library: {
            type: 'commonjs',
        }
    },
    optimization: {
        minimize: true,
        minimizer: [new minify()],
    }
};

Atualizando o AWS SAM

No arquivo template.yaml do AWS SAM, precisamos ajustar a configuração da função Lambda para usar um Makefile personalizado em vez do esbuild. Isso nos dá maior controle sobre o processo de build.

Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
-      CodeUri: hello-world/
+      CodeUri: src/ # deve apontar para o diretório do Makefile
      Handler: app.lambdaHandler
      Runtime: nodejs20.x
      Architectures:
      - x86_64
      Events:
        HelloWorld:
          Type: Api
          Properties:
            Path: /increment
            Method: post
    Metadata:
+      BuildMethod: makefile  
-      BuildMethod: esbuild
-      BuildProperties:
-        Minify: true
-        Target: es2020
-        Sourcemap: true
-        EntryPoints:
-        - app.ts

Criando o Makefile

Finalmente, criamos um Makefile para definir o processo de build. O Makefile é uma ferramenta que permite automatizar tarefas, como instalação de dependências, execução de scripts e cópia de arquivos.

build-VisitCounterFunction:
    yarn install --force && yarn build
    cp dist/app.js $(ARTIFACTS_DIR) # variável gerida pelo AWS SAM

The astro-deck's CLI

Daniel Santos — Thu, 10 Aug 2023 00:08:19 +0000

Last month I wrote about the beginning of astro-deck, a couple things happened since then, and today I want to talk about its CLI.

I didn't know right from the beginning how to distribute astro-deck, I was just building some functionalities on top of Astro, and hoping to someday find out a better way to organize it.

At its early days, astro-deck was nothing more than scripts inside package.json that just pointed to astro CLI commands:

"scripts": {
    "deck": "tsx src/scripts/deck.ts",
    "dev": "astro dev",
    "build": "astro build",
    "preview": "astro preview",
}

Everything was working fine, but I was testing the wrong way, I was creating a deck file inside the project and running these npm script. This is not the way users interact with tools like astro, nextjs and etc, they interact directly with a CLI.

yeah, that was literally me remembering that I interact with CLIs everyday

I read a little about CLIs, it really is a fascinating world, here are some links that helped me a lot:

I ended up choosing NodeJS + yargs to build the CLI, there is a lot of content on the internet about them, and the short time I used it, it seemed like a good combo.

let's get to work

I started with the simplest, the deck command, as you saw in the first snippet, its only mission was to call a function inside src/scripts, I changed this script location and made some adjustments, here's the final version of the deck command:

const command: CommandModule<{}, { path: string }> = {
    command: "deck <path>",
    describe: "Build a presentation from a given .mdx file",
    builder: {
        path: {
            describe: "Path to the .mdx file",
        },
    },

    handler: function (args) {
        const astroDeckPagesFolder = resolve(
            __dirname,
            "..",
            "..",
            "..",
            "src",
            "pages",
        );

        try {
            const filePath = resolve(args.path);
            mdxToPresentation(filePath, astroDeckPagesFolder);
        } catch (error) {
            console.error(`[astro-deck] error: ${(error as Error).message}`);
        }
    },
};

It receives a .mdx file, divides it into several other files, and saves everything in the pages folder.

The next one was the dev command, all it needs to do is to start Astro development server. As I'm writing this, Astro does not provide a way to start it programatically, so the only option is to start a new process the old way. NodeJS has child_process to make this possible, but I choose execa since it provides a better API.

My first attempt looked like this:

await execa("astro", [astroOptions, ...astroCommands.map(toString)], {
    stdio: "inherit"
});

Everything sounds ok, but it doesn't work!

This problem happens because the user does not have Astro installed globally/as a dependency.

I also tried npm explore as you can see here.

It worked but I wanted to know if there's a better way to do this, to my surprise, execa has an awesome option called preferLocal, if set to true, it will look first for locally installed binaries.

await execa("astro", [astroOptions, ...astroCommands.map(toString)], {
    stdio: "inherit",
    cwd: astroDeckFolder,
    preferLocal: true,
});

And then:

This is the final version of the astro helper:

import { resolve, dirname } from "node:path";
import { fileURLToPath } from "node:url";
import { execa } from "execa";
import type { ArgumentsCamelCase } from "yargs";

export type AstroOptions = "dev" | "build" | "preview";

const __dirname = dirname(fileURLToPath(import.meta.url));

/**
 * Runs the Astro CLI with the given options and commands
 */
export async function astro(
    args: ArgumentsCamelCase,
    astroOptions: AstroOptions,
) {
    const astroCommands = args._.slice(1);

    const astroDeckFolder = resolve(__dirname, "..", "..");

    await execa("astro", [astroOptions, ...astroCommands.map(toString)], {
        stdio: "inherit",
        cwd: astroDeckFolder,
        preferLocal: true,
    });
}

Once the development server starts, it will run the deck command under the hood and listen to any changes inside the /pages folder, thanks to the deckWatcher helper, the dev command will also listen to changes in the presentation file, and run the deck command again, if needed.

There isn't too much to talk about build and preview commands, they just move folders around and call Astro.

wrapping up

The CLI will be the bridge between the users and the functionalities of astro-deck, for now, I think it is well organized and can do the job, but remember, this is a open-source project, so suggestions and contributions are always welcome, feel free to open a issue or to tag me at Twitter.

The next steps of astro-deck will be related to improve the support of default components and themes, they will be hard tasks, and I hope to share more about them as soon as possible.

I started astro-deck

Daniel Santos — Tue, 18 Jul 2023 00:00:40 +0000

Last month, while scrolling through my list of starred repositories, I came across one from fersilva that caught my attention. It was a presentation on Lean 4. As I explored its source code, I recalled mdx-deck, a tool that generates presentations from Markdown JSX files. These presentations can be deployed as static websites, making them easily hostable on any platform.

The following day, I delved into the mdx-deck source code, to understand its workings and structure. This is a habit I'm trying to cultivate. It sparked a desire in me to create my own version of mdx-deck using Astro.

Over the next few weeks, I dedicated a portion of my free time to figuring out how I could bring this idea to life. I opened several issues and brainstormed ideas, transforming each aspect of the project into a question that I'm trying to answer. I'm documenting everything within a main issue to keep track of progress.

Most of the issues are still open, there's a long way ahead, maybe some questions turn up becoming blog posts in the future, like:

I still don't know how long it will take for the project to arrive in a usable version, for now I'm enjoying the process and all the lessons that come along the way.

The project is open source, so feel free to check it out and contribute.

I'll be posting some small updates on Twitter as well.

What is a Webhook and how it works

Daniel Santos — Sun, 04 Jun 2023 14:17:42 +0000

Let's imagine a crowded restaurant, the waiter's mission is to deliver customer's orders to the kitchen, and when the food is ready, take it to them.

The waiter needs to know when the food is ready, if he goes to the kitchen every 2 minutes to see if an order is ready, it would be a huge waste of time: maybe new customers will enter the restaurant in the meantime. Waiting to be served is never good!

Wouldn't it be amazing if the kitchen called the waiter when the order was ready? That way, the waiter would spend less time going to the kitchen and more time doing what matters.

A similar scenario happens when you're choosing an approach to handle real time data coming from external sources, such as an application that you don't have control over. You can call it many times at a given interval (pooling), or await for an event to be sent from source to your application (webhook).

Webhook is a common feature on products that heavily depends on integrations, like payment services providers, monitoring systems, CI/CD stuff and so on.

This is how a webhook works, as simple as adding an endpoint to your application that listens to POST calls and reporting its address to the application where the events occur. Despite being simple, the possibilities from there are countless, providing a powerful integration.

Creating Rest APIs with Rust

Daniel Santos — Mon, 12 Dec 2022 18:26:13 +0000

In this series, I'll share the learnings I got developing another personal project, today I bring a brief introduction to building Rest APIs with Rust.

Choosing the framework

Rust has big names in the framework market for building REST APIs: Rocket, Axum, Warp, and Actix. I only tested the first two and ended up opting for Axum.

Hot reload

A feature that I look for whenever possible in my development environment is Hot Reload, with it, every time a file is changed and saved the application restarts, so the cycle of writing-evaluating-refactoring code becomes extremely fast, for Rust, we have cargo watch, I suggest taking a look at the documentation for more details.

Hello, Axum

We will start by starting a new project with Cargo

$ cargo new hello_world --bin

Add the following dependencies to Cargo.toml :

[dependencies]
axum = "0.6"
tokio = { version = "1.22.0", features = ["full"] }
serde = { version = "1.0.149", features = ["derive"] }

In addition to Axum, as already mentioned, we are adding Tokio as our async runtime, and Serde, to handle JSON serialization and deserialization.

I recommend the following posts if you don't know what an async runtime is and why we need one in this scenario

With the dependencies installed, we'll edit the src/main.rs file:

// src/main.rs

use std::{error::Error, net::SocketAddr};

use axum::{
    routing::get,
    Router,
};

#[tokio::main]
async fn main() -> Result<(), Box<dyn Error>> {
    let addr = SocketAddr::from(([127, 0, 0, 1], 8000));

    let app = Router::new().route("/", get(|| async { "Hello, Axum" }));

    println!("listening on {}", addr);

    axum::Server::bind(&addr)
        .serve(app.into_make_service())
        .await
        .unwrap();

    Ok(())
}

Now we can run our application with cargo watch -x run, and it will respond to GET requests on the http://127.0.0.1:8000/ endpoint

curl -X 'GET' \
  'http://127.0.0.1:8000/'

Hello, Axum

On line x we register the GET / endpoint, Axum calls the functions that resolve endpoints as handlers, and handlers can return any structure that implements the IntoResponse trait. We can start the code split by moving the closure into a function:

// add use axum::http::StatusCode;

pub async fn hello_axum() -> impl IntoResponse {
    (StatusCode::OK, "Hello, Axum")
}

On line x, we place our handler:

// add use axum::http::StatusCode;

    let app = Router::new().route("/", get(hello_axum));

Documentation

With an endpoint defined, now it's a good time to set up the API documentation. At this point, I believe that a specification like OpenApi, together with Swagger for its visualization, is a good combo.

To implement them, we'll need some libraries, one responsible for the specification and the other for its presentation, so let's go back to the Cargo.toml file and add utoipa and utoipa-swagger-UI as dependencies:

[dependencies]
axum = "0.6"
tokio = { version = "1.22.0", features = ["full"] }
serde = { version = "1.0.149", features = ["derive"] }
utoipa = { features = ["axum_extras"], version = "2.4.2" }
utoipa-swagger-ui = { features = ["axum"], version = "3.0.1" }

And then, we use Utoipa's path attribute in our handler:

#[utoipa::path(
    get,
    path = "/",
    responses(
        (status = 200, description = "Send a salute from Axum")
    )
)]
pub async fn hello_axum() -> impl IntoResponse {
    (StatusCode::OK, "Hello, Axum")
}

A Rest API can contain many different endpoints, and we need a point where we can unite all these specifications, for that, Utoipa provides the derive macro OpenApi, and by adding it to a struct, we can store all the endpoints of our application through the paths parameter of the #[openapi] attribute:

// add use utoipa::OpenApi;

#[derive(OpenApi)]
#[openapi(paths(hello_axum))]
pub struct ApiDoc;

Once that's done, we can expose the documentation on an endpoint with SwaggerUi, and attach it to our application, using the Router.merge method:

// add use utoipa_swagger_ui::SwaggerUi;

let app = Router::new()
        .route("/", get(hello_axum))
        .merge(SwaggerUi::new("/swagger-ui").url("/api-doc/openapi.json", ApiDoc::openapi()));

And finally, if we go to http://127.0.0.1:8000/swagger-ui/, we'll see the Swagger interface:

From Utoipa, we have a range of possibilities, we can define the body and header of the requests, the HTTP codes to be returned, the format of the responses, and so on, it is worth taking some time in the library documentation to extract the maximum of OpenApi.

The post ends here, but in the next one, we will have some improvements, such as connection to a database and integration tests.

Thank you for reading this far, any doubts or questions can be asked in the comments section, if you want to contact me more easily, you can send me a message on Twitter, I am always available there.

Porquê e como utilizar Dataloaders

Daniel Santos — Wed, 19 Oct 2022 17:52:24 +0000

Por muitas vezes, fontes externas de dados podem ser o caminho crítico para o seu serviço, e é essencial assegurar-se de não o percorrer mais vezes que o necessário, uma vez que tempo e dinheiro andam lado a lado no que diz respeito ao desenvolvimento de software.

O cenário

Imagine uma aplicação utilizando GraphQL, onde é possível que um usuário poste diversas publicações, cada postagem possui o id do seu autor, e a partir desse id podemos buscar informações adicionais sobre o mesmo.

Como descrito, no resolver do atributo author seria feito o relacionamento da outra entidade.

author: {
  type: User,
  resolve: async (obj) => {
    const author =
      await prisma.$queryRaw`SELECT * FROM User WHERE id = ${obj.authorId}`;
    return author ? author[0] : null;
  },
},

Para acessar as postagens e o seu autor, teremos uma query como essa:

query allPosts {
   getPosts {
    title
    author {
      name
    }
  }
}

getPosts: {
  type: new GraphQLList(Post),
  resolve: async () => await prisma.post.findMany(),
},

Num cenário em que existem apenas 3 postagens, todas do mesmo autor, executando a query e registrando os logs do sistema no console, teríamos um resultado como esse:

prisma:query SELECT `main`.`Post`.`id`, `main`.`Post`.`title`, `main`.`Post`.`content`, `main`.`Post`.`published`, `main`.`Post`.`authorId` FROM `main`.`Post` WHERE 1=1 LIMIT ? OFFSET ?
prisma:query SELECT * FROM User WHERE id = ?
prisma:query SELECT * FROM User WHERE id = ?
prisma:query SELECT * FROM User WHERE id = ?

N + 1 problem

O ideal seria resolver essa query do GraphQL fazendo apenas duas consultas no banco de dados, uma para as postagens, e outra para cada um dos autores distintos. O que não é o caso aqui, apesar de termos apenas um usuário, ainda realizamos a mesma busca pelos seus dados 3 vezes.

O exemplo acima configura o n+1 problem, isto é, fazemos várias execuções desnecessárias, mesmo que os dados que desejávamos a princípio já tenham sido retornados, esse problema não é exclusivo do GraphQL, nem mesmo ocorre somente em acessos a bancos de dados.

Dataloader

Existem algumas formas de resolução para esse problema, a mais comum é utilizando o Dataloader, um utilitário criado a partir de uma das APIs internas do Facebook. Com o Dataloader, estratégias de batching e caching podem ser facilmente adicionadas à aplicação.

Analisando as consultas feitas ao banco de dados, podemos notar que o ponto de deficiência se encontra no resolver do atributo author, logo, precisamos inserir o Dataloader nessa função, substituindo a chamada direta ao banco de dados.

Para criar um loader, precisamos passar uma função que aceite um array de keys, e retorne um array de respostas com o mesmo tamanho. Podemos executar todas as consultas ao mesmo tempo através do método Promise.allSettled, caso alguma Promise seja rejeitada, podemos substituir o valor do erro por null, para que o array retornado seja do mesmo tamanho do array de keys fornecido.

Colocando em prática, teremos algo semelhante a isso:

const batchFn: BatchLoadFn<number, unknown> = async (keys) => {
  const promises = keys.map(
    (k) => prisma.$queryRaw`SELECT * FROM User WHERE id = ${k}`
  );
  const response = await Promise.allSettled(promises);
  return response.map((r) => (r.status === "rejected" ? null : r.value));
};

export const userDataloader = new DataLoader(batchFn);

Com o loader pronto, podemos utilizá-lo no resolver, como cada postagem possui apenas um autor, utilizamos o método .load, passando o id do autor como parâmetro.

author: {
  type: User,
  resolve: async (obj) => {
    const author = await userDataloader.load(obj.authorId);

    return author ? author[0] : null;
  },
},

Assim, a primeira chamada a um determinado autor irá realizar a busca no banco de dados e adicionar estes dados ao cache, chamadas subsequentes irão consumir deste cache criado.

Executando a query novamente, com o Dataloader implementado, temos como resultado os seguintes logs:

prisma:query SELECT `main`.`Post`.`id`, `main`.`Post`.`title`, `main`.`Post`.`content`, `main`.`Post`.`published`, `main`.`Post`.`authorId` FROM `main`.`Post` WHERE 1=1 LIMIT ? OFFSET ?
prisma:query SELECT * FROM User WHERE id = ?

Fomos de 4 consultas no banco de dados para 2, imagine se o usuário tivesse dezenas ou centenas de posts, com certeza a diferença seria ainda mais significativa.

É importante destacar, que caso os dados na sua fonte sofram alguma alteração, o cache do Dataloader não terá conhecimento dessa mudança. Portanto, você precisa remover esse dado específico através do método .clear(), e assim, chamadas futuras ao método .load() irão atualizar o cache.

// mutation
changeOneUser: {
    type: User,
    args: {
      id: {
        type: GraphQLInt,
      },
      name: {
        type: GraphQLString,
      },
    },
    resolve: async (_, { id, name }) => {
      const data = await prisma.user.update({
        where: {
          id,
        },
        data: {
          name,
        },
      });

      userDataloader.clear(id);

      return data;
    },
  },

Finalizando

Apesar de não fazer parte da ideia inicial deste texto, é preciso destacar aqui o Prisma já possui uma solução para este problema através do método .findUnique, optei por não utilizá-lo aqui para demonstrar como seria realizada uma implementação manual através da biblioteca em questão.

Outro ponto relevante a ser levantado, é de que o Dataloader pode ser usado também com outras linguagens além do Javascript, como Java, Go, Python e por aí vai.

E por fim, você pode acessar o restante do código através deste repositório: dataloader-example