DEV Community: Nova Script

Exemplificando um grande problema que o GraphQL resolve: overfetching.

Nova Script — Thu, 03 Nov 2022 13:54:16 +0000

O problema:

Imagine o seguinte cenário: você é dono de uma aplicação web qualquer que possui: uma API Rest e um frontend qualquer.

No frontend, é dado uma ocasião onde você precisa mostrar pro usuário final uma lista contendo todos os nomes dos usuários que estão online naquele momento.

Então, você faz uma requisição para a sua API, no endpoint:

GET /online_users

Que retorna:

[
    {"name": "Hobbit", "email": "hobbit@csgo.com", "social": {"instagram": "@hobbit" ...}, ...},
    {"name": "Shiro", "email": "shiro@cloud9.com", "social": {"instagram": "@shiro" ...}, ...},
    {"name": "Groove", "email": "groove@gambit.com", "social": {"instagram": "@groove" ...}, ...},
    ...
]

Porém, perceba que para a ocasião dada, não precisamos de todos os dados que o nosso endpoint retorna (email, redes sociais e etc), mas sim apenas do nome de cada usuário.

É exatamente aí que o GraphQL começa a fazer sentido.

Com o GraphQL, é possível pedir ao backend para que o endpoint retorne APENAS as informações que você precisa.

Mas porque não apenas ignorar os campos que não vou utilizar?

Ainda no nosso cenário imaginado, veja também que a sua API está hospedada na AWS (Amazon Web Services).
Nessa plataforma, você paga apenas pelos recursos que consome. Mais especificamente, você paga por tráfego: quanto maior a quantidade de informação (bytes) que trafega na sua API (recebimento e envio de dados), maior será o custo da sua aplicação no final do mês.

Cada campo "ignorado" possui, portanto, um custo em dinheiro.

Ainda, imagine que a sua aplicação web recebe milhares de visitantes por dia e, portanto, cada vez que você precisar mostrar para esses visitantes quem está online, você vá desperdiçando cada vez mais informação.

Agora, imagine quantos outros endpoints existem dentro da sua aplicação e a quantidade de informação sendo "ignorada" pelo frontend. Multiplique isso pelo número de milhares de visitantes por dia.

Você verá, então, quanto dinheiro está sendo jogado fora.

O gasto de recursos aumenta significantemente à medida em que seu site aumenta a quantidade de clientes.

Esse problema se chama overfetching.

Ou seja:

O GraphQL permite que você peça ao back-end somente o que for utilizar, sem desperdiçar informação.

Se gostou do conteúdo, não deixe de me apoiar com seu like aqui ou na rede social onde você o encontrou! ;D

[DOCKER] [NODE]: Como 'buildar' a node_modules só quando for necessário!

Nova Script — Mon, 26 Sep 2022 13:34:35 +0000

Introdução:

Nem todas as vezes que mudamos nosso código, isso significa que nós implementamos novas dependências: se não inserimos nenhum pacote novo no nosso projeto, então não há motivo algum para reconstruir (rebuild) a pasta node_modules.

Então, vamos entender como melhorar nossa eficiência, já que nosso tempo de debugging e desenvolvimento para aplicações Node rodando Docker será significantemente reduzido.

Como Node Dockerfiles são implementados normalmente:

Vamos olhar rapidinho esse Dockerfile que está mal implementado.

FROM node:16

# Cria diretório do aplicativo
WORKDIR /usr/src/app

# Copia o código inteiro
COPY . .

# Instala as dependências
RUN npm install

# Roda o servidor
EXPOSE 8080
CMD [ "node", "server.js" ]

Todo o problema de eficiência aqui reside
na linha COPY . ..

Isso é ruim, pois fazer isso significa que: todas as vezes que você fizer uma mudança no código presente em ., a pasta node_modules terá que ser reconstruída, de novo e de novo e de novo...

Arrumando isso:

Ao invés disso, nós devemos primeiramente copiar apenas nosso arquivo package.json e package-lock.json (que controlam nossas dependências) para o diretório do aplicativo e então instalar elas.

Então, vamos atualizar nosso Dockerfile para:

# Copia package.json e package-lock.json
COPY package*.json ./

# Instala as dependências
RUN npm install

E só então, copiamos o resto dos nossos arquivos:

COPY . .

Então, nossa versão corrigida do Dockerfile será:

FROM node:16

# Cria diretório do aplicativo
WORKDIR /usr/src/app

# Copia package.json e package-lock.json
COPY package*.json ./

# Instala as dependências
RUN npm install

# Copiamos o resto dos arquivos
COPY . .

# Roda o servidor
EXPOSE 8080
CMD [ "node", "server.js" ]

Explicação:

É tudo sobre camadas cacheadas do Docker, ou Docker cached layers.

Cada imagem do Docker consiste de uma série de camadas.

Comandos no seu Dockerfile vão gerar novas camadas.

Ao invés de manter tudo dentro de uma só camada, nós devemos quebrar em partes diferentes.

Pois o Docker sempre vai tentar usar uma camada que já existe, ao invés de criar uma nova, se for possível.

Essa é a explicação simples e rápida.
Você pode ler mais detalhes na documentação oficial.

Conclusão:

Agora, toda vez que modificarmos a package.json, o comando npm install será executado novamente.
Caso não modifiquemos, então essa etapa será simplesmente ignorada.

Você pode verificar esse comportamento no log da imagem, procurando por ---> Using cache, que indica que a pasta node_modules não está sendo reconstruída.

Gostou do post? :D

Se você gostou, por favor considere me seguir ou favoritar esse post!

[DOCKER] [NODE]: How to rebuild node_modules only when it's necessary!

Nova Script — Mon, 26 Sep 2022 13:15:59 +0000

Introduction:

Not everytime we change our code it means that we have implemented new dependencies: if we have not inserted a new package into our project, there's no reason at all to rebuild node_modules folder.

So let's understand how we can upgrade our efficiency, as your development and debugging time for Node applications running Docker will be significantly reduced.

How Node Dockerfiles are usually implemented:

Let's take a fast look at this usually seen Dockerfile, which is bad implemented.

FROM node:16

# Create app directory
WORKDIR /usr/src/app

# Copy source
COPY . .

# Install dependencies
RUN npm install

# Run server
EXPOSE 8080
CMD [ "node", "server.js" ]

The whole efficiency problem here is located at COPY . .

This is bad. Doing so will result in: everytime we make a change to a file in ., our modules folder will have to be built again and again and again...

Fixing it:

Instead, we should firstly only copy our package.json and package-lock.json files (which controls our dependencies) to our working directory and then install them.

So, let's update our Dockerfile to:

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install

And only then, we can copy the rest of our files:

COPY . .

So, our fixed Dockerfile version will be:

FROM node:16

# Create app directory
WORKDIR /usr/src/app

# Copy package.json and package-lock.json
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy source
COPY . .

# Run server
EXPOSE 8080
CMD [ "node", "server.js" ]

Explanation:

It's all about Docker cached layers.

Each Docker image consists of a series of layers.

Commands in your Dockerfile will always generate new layers.

Instead of keeping everything within only one layer, we should break it on different parts.

Because Docker will try to use an existent cached layer on rebuild.

That's the simple explanation.
You can read the details on official documentation.

Conclusion:

Now, everytime package.json file changes, npm install will be runned again. Otherwise, it will be simply skipped.

You can check this behavior on your log: just look for ---> Using cache, which indicates node_modules is not being rebuilded.

Liked this post? ;D

If you do, please consider following me or favoriting this post!

GIT TIPS: Creating a new empty branch

Nova Script — Mon, 11 Apr 2022 20:22:27 +0000

When to create a new empty branch?

Sometimes, it can be very useful to create a new empty branch on git. For example, imagine the following scenario: you are working on a website project but you also want to keep a good documentation aside, in the same repository. So, in order to keep things minimally separated, you can create a brand new branch called docs and keep your website code at another branch called develop.

That way, you can always easily change from one workspace to another (changing branches) and also keep everything inside your repository.

How to create it?

It's simple: let's execute the command git checkout, in order to change to another branch. Also, we're going to use the --orphan flag, which is going to be responsible for creating a branch with empty commits on it (you can git log in order to verify this, after creating the branch).

Also, we must give the branch a name right after the --orphan flag.

git checkout --orphan <branch_name>

Then, your project files from the previous branch you were working at will still be there. But they will be there just as untracked files and they can be easily removed by executing the command:

git reset --hard

When using the --hard flag, git reset will be responsible for destroying any changes you've made in your branch files, compared to the last HEAD commit (last commit you've made). Since our branch is empty and has no commits on it, all the files are going to be instantly removed.

Switching back to another branch:

After creating a commit in your new branch, it will be visible in your branch list, which you can check by using the command:

git branch

Then, you can switch between any branches by using:

git checkout <branch_name>

Enjoyed it?

Please, like this post and follow me on social media!

Desinstalando dependências inutilizadas em Python com o PIP.

Nova Script — Fri, 27 Nov 2020 16:33:26 +0000

Introdução:

Acontece: durante o desenvolvimento do seu projeto, alguns pacotes foram instalados — e possivelmente utilizados — mas hoje não são úteis e você precisa removê-los para acelerar o desempenho do Software e tornar o código enxuto.

Atenção! Seu projeto deve conter um arquivo requirements.txt ;

É essencial que o seu projeto esteja rodando em um ambiente virtual.

Caso esse artigo tenha te ajudado, compartilhe!

Como Fazer:

Para performar a “limpeza”, utilizaremos o pacote pip-check-reqs, ele vai varrer todo o código fonte do nosso projeto buscando por todas as importações presentes. Depois de criar uma árvore de dependências, ele verificará se existem dependências extras presentes no arquivo requirements.txt e as mostrará — caso existam.

Ative seu ambiente virtual.
Instale o pip-check-reqs:

pip install pip-check-reqs

Depois, dispare o procedimento com o comando:

pip-extra-reqs .

Então, ele mostrará em seu terminal todos os pacotes extras (não utilizados).

Pronto! Agora é só remover essas dependências do seu requirements.txt.

Como Testar:

Para testar se o seu projeto ainda funciona normalmente após a retirada desses pacotes, você pode:

Desinstalar todos os pacotes previamente instalados:

pip freeze | xargs pip uninstall -y

2.Reinstalar a nova lista de pacotes:

pip install -r requirements.txt

Rodar o projeto e verificar a ausência de erros!