Forem: Paulo Lôbo

Lamba LLRT(Low Latency Runtime Javascript)

Paulo Lôbo — Tue, 20 Aug 2024 12:42:53 +0000

Aviso: todo e qualquer conteúdo postado é com objetivo de relembrar ou manter os meus conhecimentos e espero que possa te ajudar na sua caminhada pelo aprendizado também.
Esse post é vivo e será atualizado periodicamente.
Caso você encontre alguma falha ou perceba que falta algo, me ajude a melhorar :)

Você já parou para pensar que estamos sendo cada vez mais exigidos em relação à performance das nossas aplicações? A cada dia, somos desafiados a torná-las mais rápidas, e, com isso, somos levados a avaliar soluções e arquiteturas que nos possibilitem alcançar esse resultado.

Portanto a ideia é trazer um post curto, informando sobre uma nova evolução que pode nos ajudar a ter um aumento considerável de performance em aplicações serverless no AWS Lambda. Essa solução é o LLRT Javascript.

LLRT Javascript(Low Latency Runtime Javascript)

Um novo runtime JavaScript está sendo desenvolvido pela equipe da AWS. No momento, ele é experimental, e há esforços para lançar uma versão estável até o final de 2024

veja a descrição que a AWS apresenta:

LLRT (Low Latency Runtime) is a lightweight JavaScript runtime designed to address the growing demand for fast and efficient Serverless applications. LLRT offers up to over 10x faster startup and up to 2x overall lower cost compared to other JavaScript runtimes running on AWS Lambda
It's built in Rust, utilizing QuickJS as JavaScript engine, ensuring efficient memory usage and swift startup.

Veja que eles pretendem entregar algo até 10x mais rápido do que outros runtimes JS.

Toda essa construção é feita utilizando o Rust, que é uma linguagem com alto poder de desempenho e o QuickJS, que é um motor de JavaScript leve e de alto desempenho, projetado para ser pequeno, eficiente e compatível com a especificação ECMAScript mais recente, incluindo recursos modernos como classes, async/await, e módulos. Além disso, é utilizada uma abordagem que não usa JIT. Com isso, ao invés de alocar recursos para compilação Just-In-Time, conserva esses recursos para a execução de tarefas do próprio código.

Mas calma que nem tudo são flores, são tradeoffs(trocadilho horrível, eu sei rsrs).
Portanto, há alguns pontos importantes para se avaliar antes de pensar em adotar o LLRT JS. Veja o que a AWS informa:

There are many cases where LLRT shows notable performance drawbacks compared with JIT-powered runtimes, such as large data processing, Monte Carlo simulations or performing tasks with hundreds of thousands or millions of iterations. LLRT is most effective when applied to smaller Serverless functions dedicated to tasks such as data transformation, real time processing, AWS service integrations, authorization, validation etc. It is designed to complement existing components rather than serve as a comprehensive replacement for everything. Notably, given its supported APIs are based on Node.js specification, transitioning back to alternative solutions requires minimal code adjustments.

Além disso, a ideia é que o LLRT JS não seja um substituto para o node.js e nem nunca será.

Veja:

LLRT only support a fraction of the Node.js APIs. It is NOT a drop in replacement for Node.js, nor will it ever be. Below is a high level overview of partially supported APIs and modules. For more details consult the API documentation.

Testes Avaliativos

Levando em consideração a aplicabilidade que foi citada pela própria AWS, vamos realizar dois testes para avaliar e comparar o LLRT com o NodeJS. Um dos testes será para o cálculo de números primos e o outro para uma chamada simples de API.

Porque utilizar o cálculo de números primos?
A resposta é que o alto processamento requerido para identificar números primos resulta da necessidade de realizar muitas operações matemáticas(divisões) para verificar a primalidade, da distribuição imprevisível dos primos, e da complexidade crescente com o tamanho dos números. Esses fatores combinam-se para tornar a verificação de primalidade e a busca por números primos uma tarefa computacionalmente intensa, especialmente em grandes escalas.

Mãos na massa então...

Crie a primeira função lambda com nodejs:

Agora, vamos criar a função com o LLRT JS. Optei por utilizar a opção de layer.

Crie a layer:

Depois crie a função:

E adicione essa layer a função LLRT JS criada:

Para o teste de números primos, vamos usar o seguinte código:

let isLambdaWarm = false
export async function handler(event)  {

    const limit = event.limit || 100000;  // Defina um limite alto para aumentar a complexidade
    const primes = [];
    const startTime = Date.now()
    const isPrime = (num) => {
        if (num <= 1) return false;
        if (num <= 3) return true;
        if (num % 2 === 0 || num % 3 === 0) return false;
        for (let i = 5; i * i <= num; i += 6) {
            if (num % i === 0 || num % (i + 2) === 0) return false;
        }
        return true;
    };

    for (let i = 2; i <= limit; i++) {
        if (isPrime(i)) {
            primes.push(i);
        }
    }

  const endTime = Date.now() - startTime

    const response = {
        statusCode: 200,
        body: JSON.stringify({
            executionTime: `${endTime} ms`,
            isLambdaWarm: `${isLambdaWarm}`
        }),
    };


    if (!isLambdaWarm) { 
        isLambdaWarm = true
    }

    return response;
};

E para o teste de API, vamos usar o código abaixo:

let isLambdaWarm = false
export async function handler(event) {

  const url = event.url || 'https://jsonplaceholder.typicode.com/posts/1'
  console.log('starting fetch url', { url })
  const startTime = Date.now()

  let resp;
  try {
    const response = await fetch(url)
    const data = await response.json()
    const endTime = Date.now() - startTime
    resp = {
      statusCode: 200,
      body: JSON.stringify({
        executionTime: `${endTime} ms`,
        isLambdaWarm: `${isLambdaWarm}`
      }),
    }
  }
  catch (error) {
    resp = {
      statusCode: 500,
      body: JSON.stringify({
        message: 'Error fetching data',
        error: error.message,
      }),
    }
  }

  if (!isLambdaWarm) {
    isLambdaWarm = true
  }

  return resp;
};

Resultados dos testes

O objetivo é mais educacional aqui, portanto nossa amostra para cada teste é constituído de 15 dados em warm start e 1 de cold start.

Consumo de memória

LLRT JS - para ambos os testes, houve o consumo da mesma quantidade de memória: 23mb.

NodeJS - para o teste de números primos, o nodejs começou consumindo 69mb e indo até 106mb.
Já para o teste de API, o mínimo foi 86mb e o máximo com 106mb.

Tempo de execução
após a remoção dos outliers, esse foi o resultado:

Relatório final

Consumo de memória - para o consumo de memória foi observado que o LLRT fez o melhor uso do recurso disponível se comparado ao nodejs.

Performance - percebemos que no cenário de alto processamento, o node manteve uma performance bem superior ao LLRT, tanto no cold start quanto warm start.
Para o cenário de menor processamento, o LLRT obteve uma certa vantagem, principalmente no cold start.

Vamos, então, aguardar os resultados finais e esperar que possamos ter ainda mais melhorias significativas. Mas é muito bom ver a flexibilidade do JavaScript e perceber o quanto ele pode e ainda tem a nos oferecer.

Espero que tenha gostado e que isso tenha ajudado a melhorar sua compreensão ou até mesmo aberto caminhos para novos conhecimentos. Conto com você para críticas e sugestões, para que possamos melhorar o conteúdo e mantê-lo sempre atualizado para a comunidade.

Angular - Estratégias de roteamento e History API

Paulo Lôbo — Thu, 15 Aug 2024 21:33:17 +0000

Aviso: todo e qualquer conteúdo postado é com objetivo de relembrar ou manter os meus conhecimentos e espero que possa te ajudar na sua caminhada pelo aprendizado também.
Esse post é vivo e será atualizado periodicamente.
Caso você encontre alguma falha ou perceba que falta algo, me ajude a melhorar :)

Veja um resumo do passo a passo que o angular faz para realizar o roteamento de uma aplicação:

Configuração de Rotas: primeiro, você define as rotas no módulo de roteamento com RouterModule.forRoot(routes);
Serviço Router: depois, você utiliza os serviços do Router para realizar a navegação;
Atualização da URL: em seguida o angular atualiza a History API e também atualiza a url na barra de endereços do navegador, ou não(falo dele no final);
Correspondência de Rotas: O angular compara a URL com as rotas definidas e carrega o componente correspondente;
Renderização e Detecção de Mudanças: Por fim, renderiza o componente e atualiza o DOM.

Tipos de estratégias

Os frontends SPAs possuem 2 estratégias mais comuns de roteamento:
HashLocationStrategy(Hash mode) e PathLocationStrategy(History mode).

Para quem já trabalha com SPAs no dia-a-dia sabe bem a diferença mais básica das duas estratégias:

PathLocationStrategy (History Mode)

As URLs seguem o padrão tradicional de navegação na web, sem nenhum #. Por exemplo:
https://paulo.com/home.

HashLocationStrategy (Hash Mode):

As URLs incluem um # seguido do caminho. O que vem após o # não é enviado ao servidor e é tratado inteiramente pelo navegador.
Exemplo de URL: https://paulo.com/#/home.

O PathLocationStrategy é a configuração default do angular, e caso deseje utilizar a estratégia de hash, precisará declarar assim no seu arquivo de rotas:

RouterModule.forRoot(routes, {useHash: true})

Há alguns debates sobre o melhor uso de cada um. Alguns comentam sobre a estratégia de se utilizar o HashLocation somente em arquitetura SSR e outros que entendem que traz mais simplicidade e por isso o utilizam em todos os cenários, mas não vou entrar nesse detalhe. Fica a dica caso se interesse em procurar mais sobre a discussão :)

History API

Por baixo dos panos o angular usa a History API para se comunicar com o roteamento do navegador.

Link para implementação da PathLocationStrategy

Imagem mostrando o acionamento do angular durante uma mudança de rota, usando estratégia de pathlocation:

Link para implementação da HashLocationStrategy

Imagem mostrando o acionamento do angular durante uma mudança de rota, usando estratégia de hashlocation:

A History é uma interface/API do navegador que permite manipular o histórico de navegação do usuário sem recarregar a página. Ela foi introduzida com a especificação do HTML5 e oferece um conjunto de métodos para adicionar, modificar ou remover entradas do histórico do navegador, além de responder a mudanças no estado da navegação.

Veja:

repare que a cada mudança de rota, o objeto "history" vai sendo incrementado.

Tanto o location(import { Location } from "@angular/common"), quanto o router(import { Router } from "@angular/router")acionam/comunicam com a History API

Isso ocorre porque toda vez que navegamos para uma rota qualquer, o angular aciona o platformLocation, que por sua vez, aciona o método history.pushState. Da mesma forma, o método history.replaceState é invocado toda vez que utilizamos o replaceUrl.

Um ponto interessante é que o angular também atualiza o objeto Location.
O Location mantém todos os dados da rota durante a navegação.

Repare, que ao usar o PathLocation, o objeto location mostra o pathname que correlaciona com a mesma rota na url do navegador:

Já ao usar o hashlocation, o pathname fica sempre vazio e somente o atributo "hash" é alterado:
.

Em breve solto um post sobre a importância na escolha das estratégias ao criar um app Server Side Rendering(https://angular.dev/guide/ssr).

Uma observação importante é que apesar da History API conseguir suprir as principais necessidades e servir para os frontends SPA’s mais atuais, a partir do momento que avançamos para alguns cenários, como a própria necessidade de se realizar a observabilidade de um SPA, notamos algumas debilidades nessa API. Para sanar esses problemas, uma nova proposta de substituição dessa API está em andamento, que é a Navigation API. Ela ainda está em fase experimental e falaremos mais dela no post sobre monitoramento e performance de SPA.

SkipLocationChange

Lembra do que escrevi sobre o angular acionar o histórico.pushState?
O que essa opção faz é garantir que o conteúdo seja renderizado na tela, mas dessa vez sem acionar o método history.pushstate que é responsável por definir a URL do navegador. Só o status interno do Router que será atualizado. Nesse caso, o navegador não sabe que houve mudança no histórico.

Vamos a um exemplo…
Repare que,

o history.state possui tamanho == 1

E quando navego para uma próxima rota com o skipLocation ativo(this.router.navigate(['componentA'], {skipLocationChange: true});), ele não altera a url e nem o estado da api de histórico

no entanto, quando acessamos os eventos que o router emite, é possível ver que o estado interno do Router está atualizado

Dessa forma, somente o angular tem o estado mais atual e o navegador não possui a informação mais atualizada.

Eu espero que tenha gostado e te ajudado a melhorar a compreensão de algo ou até mesmo aberto caminhos para novos conhecimentos. Conto com você nas críticas e sugestões para irmos melhorando o conteúdo e mantendo sempre atualizado para a comunidade.