DEV Community: Fernanda Kipper

Funções Serverless na AWS: Simplificando o nosso Processo de Desenvolvimento

Fernanda Kipper — Thu, 18 Jan 2024 12:09:10 +0000

Neste post nós vamos explorar como as funções serverless da AWS, as Lambda Functions, podem simplificar, e muito, o nosso processo de desenvolvimento. Ao longo do post nós vamos conseguir entender como elas permitem que a gente se concentre no desenvolvimento da regra de negócio da nossa aplicação, sem se preocupar com a infraestrutura, servidor, memória ram...

Introdução à Arquitetura Serverless

Antes de tudo, quebrando a primeira ideia que você possa ter: não, arquitetura serverless não é uma arquitetura sem servidor. Diferente do que o nome nos faz imaginar, a arquitetura serverless tem sim um servidor. O que acontece é que ele não fica 100% do tempo pronto esperando uma requisição, na verdade, o servidor vai ao ar apenas quando essa requisição chega! E melhor, depois de executado o que for necessário, o servidor ja é desligado novamente automaticamente. Esse tempo de provisionar e começar a executar a maquina é chamado de Cold Start e pode ser um problema dependendo da nossa aplicação. Mas como veremos até o final desse post, existem maneiras de diminuir ele e manter bem alta a performance da nossa função. Além disso que eu comentei, como não precisamos hospedar um servidor, também não precisamos nos preocupar a infraestrutura dele. Quanto de RAM meu servidor precisa? Qual CPU devo utilizar? Um SSD de 1 TB basta? Essas são perguntas que não fazemos, pois quem cuida disso é a provedora desse serviço, no nosso caso, a AWS (Amazon Web Services). Essa arquitetura permite que a gente se concentre exclusivamente na regra de negócio da nossa aplicação, sem precisar gerenciar toda uma infraestrutura e sem se preocupar com código boilerplate para iniciar um servidor web (usando express.js por exemplo).

Claro, esse conceito se aplica não apenas às funções Lambda da AWS, mas também aos serviços serverless oferecidos por outras provedoras, como Google e Azure (da Microsoft). Sendo assim, as funções serverless acabam sendo ideais para tarefas esporádicas ou infrequentes, ou tarefas independentes que não precisam existir dentro de um servidor nosso, pois acabam ajudando a economizar custos e fazer a gente focar no valor que queremos entregar ao usuário, ao invés de gastar nosso tempo gerenciando servidores.

Nossa função serverless na AWS

No tutorial de hoje nós vamos criar uma função serverless na AWS (Lambda Function) que ficará disponível via uma URL para toda a internet. Para isso, precisaremos criar uma conta na AWS (https://aws.amazon.com/resources/create-account/) e depois logar no nosso Console (https://console.aws.amazon.com/). Então, na barra de pesquisa iremos buscar por “Lambda” e clicar na primeira opção, como na imagem:

Criando a nossa função

Agora, na aba “Functions”, vamos clicar no botão “Create Function” para… criar a nossa função.

Isso nos levará a uma outra pagina onde vamos definir algumas informações importantes.

A primeira é o nome da nossa função. Vou colocar KipperNodeFunction mas você pode colocar o que achar melhor.

Escolha da Linguagem e Ambiente de Execução

Na segunda opção definimos o ambiente de execução em que a nossa função será executada. A seleção do ambiente já determina qual a linguagem que usaremos (claro, até porque não tem como rodar JS em um ambiente .NET, por exemplo). Essa é uma das propriedade que a AWS usa para saber o que ela deve provisionar quando a nossa função for executada e nosso servidor precisar ser criado. Para o Node.js, o ambiente de execução que utilizaremos, a AWS oferece as versões 20, 18, 16 e 14. Mas também podemos utilizar um contêiner personalizado, se quisermos. A escolha do ambiente de execução correto é crucial para a execução eficiente da nossa função.

Ponto de Entrada

Para que a nossa função seja acessível pela internet, habilitar a URL é essencial. Isso nós podemos encontrar na seção de configurações avançadas. Ao habilitarmos essa opção, a nossa função será acionada quando a rota que nos será fornecida for acessada, servindo como o ponto inicial de execução. Quando uma função é acionada, ela recebe um objeto de evento e um objeto de contexto, fornecendo informações sobre o evento que chamou a função e todo o contexto envolvido. Eles acabam sendo dois parâmetros que são passados para a nossa função.

Aqui vai uma dica: é MUITO importante evitar código recursivo na nossa função, pois ele pode levar a chamadas infinitas e tempos de execução altíssimos, o que pode levar a contas extratosféricas. Além disso, o código recursivo acumula recursos de memória a cada chamada recursiva, aumentando ainda mais o uso de recursos e os nossos custos.

Na mesma seção também devemos habilitar o CORS para permitir que a nossa função seja executada a partir de qualquer origem.

Com a função criada, caímos no dashboard da nossa função e já temos um URL disponível para acessar, mas que por enquanto não faz nada…

Configuração de Gatilhos e Ações

O AWS Lambda pode ser configurado para acionar outros serviços da AWS ou serviços de terceiros. Além disso, também podemos fazer o inverso. Fazer com que outros serviços da AWS acionem a nossa função. Um uso interessante é na limpeza de Cache de CDN’s. Podemos configurar para que um outro serviço da AWS, chamado EventBridge Scheduler, execute a nossa Lambda uma vez ao dia e essa nossa Lambda estar configurada para invalidar o cache da nossa CDN. Assim, podemos ter uma limpeza de cache automatizada e sem provisionar um servidor pra isso.

Nosso código

Jogando a página um pouco mais para baixo, nós chegamos em uma seção onde conseguimos programar! É aqui que a mágica acontece, é essa função que é executada quando alguma requisição bate na URL que nós recebemos.

Boas práticas

Criar um agente HTTP

Por padrão, a cada requisição o Node.js cria uma nova conexão TCP. Para evitarmos que isso aconteça sempre, podemos criar um agente HTTP customizado e definir o parâmetro keepAlive como true. (Para saber mais, clique aqui)

Separar a lógica da função do handler principal

Outra dica muito importante é a separação da lógica da função e do handler da nossa função. Como podemos ver na imagem abaixo, ao separar as duas funções (poderíamos até separar em arquivos diferentes), temos o nosso código com uma uma função que pode ser testada de maneira unitária (testes unitários), o que faz aumentar a sua confiabilidade e nos garante o Separation of Concerns, um design pattern que diz que devemos separar a responsabilidade de cada função. Quase como o “S” de “SOLID” (link para algum outro post do NodeBR?).

NÃO USAR código recursivo!!!

Vou ressaltar a importância disso porque basta um simples bug que a nossa conta vais às alturas! Então, tomem MUITO cuidado com isso!

Vamos testar?

Abrindo o Postman, uma aplicação que basicamente executa requisições, podemos fazer uma chamada GET para o URL que nos foi fornecido e veremos que ele está retornando o resultado como esperado!

Permissões e Considerações de Segurança

Por fim, vale ressaltar que, ao configurar funções serverless na AWS, é crucial garantir que elas tenham apenas as permissões necessárias e restrições de acesso. Tipicamente, as funções serverless têm permissões limitadas e não têm acesso a outros serviços da AWS, como por exemplo nossas instâncias do EC2 ou arquivos no S3, a menos que sejam explicitamente concedidas.

Também é importante observar que a URL da função é pública e pode ser acessada sem autenticação nesse nosso caso, mas que também podemos configurá-la para que fique mais segura. Para isso, devemos habilitar a autenticação da nossa função, e dessa forma a AWS passará a controlar quem faz as chamadas da função, validando o token de autenticação enviado no header.

Conclusão

Neste artigo, destacamos como a integração das Lambda Functions da AWS com Node.js transforma o desenvolvimento de software. Esta combinação nos permite focar na lógica de negócios, eliminando a complexidade do gerenciamento de infraestrutura. Com Node.js, aproveitamos sua eficiência e flexibilidade, enquanto a AWS oferece uma infraestrutura gerenciada e escalável. Isso resulta em um processo de desenvolvimento mais ágil, eficiente e menos oneroso.

A sinergia entre Node.js e as funcionalidades serverless da AWS representa uma estratégia moderna de desenvolvimento. Essa abordagem não só agiliza a criação de software robusto e seguro, mas também atende às exigências de um mercado que demanda inovação rápida e soluções eficazes. Assim, desenvolvedores podem se dedicar inteiramente à entrega de valor, impulsionando o avanço tecnológico e a satisfação do usuário.

Assista à live completa no YouTube!

Acompanhe a comunidade NodeBR
Me acompanhe em todas redes!

Introdução ao SSH

Fernanda Kipper — Tue, 24 Oct 2023 03:42:55 +0000

O SSH desempenha um papel fundamental na segurança e na administração de sistemas e serviços online e por isso se tornou uma tecnologia necessária para os desenvolvedores.

Neste artigo, vamos entender os conceitos básicos que envolvem o protoloco SSH, entendendo os principais comandos e sair daqui sabendo utilizá-lo no nosso dia-a-dia!

O que é SSH

SSH, ou Secure Shell, é um protocolo de comunicação que permite a conexão segura entre dois computadores, possibilitando a transferência de dados e a execução de comandos à distância. Em muitos aspectos, o SSH é semelhante ao HTTP, um protocolo amplamente utilizado na web. No entanto, a principal diferença que distingue o SSH é a segurança que oferece.

Comunicação segura

O grande diferencial do SSH é a encriptação dos dados transmitidos entre os dois computadores. Isso significa que qualquer informação enviada ou recebida através de uma conexão SSH é codificada, tornando-a praticamente impenetrável para interceptações não autorizadas.

Como funciona

O SSH utiliza um mecanismo de chaves pública e privada para autenticar e proteger as conexões.
Esse método de autenticação garante que apenas as partes autorizadas tenham acesso aos sistemas envolvidos.

As chaves pública e privada agem como um sistema de bloqueio e chave, onde a chave privada é mantida em segredo pelo dono e a chave pública é compartilhada com o servidor SSH.

Usos Comuns do Protocolo SSH

Uma das aplicações mais comuns do SSH é permitir o acesso remoto a servidores e computadores. Isso é especialmente útil em ambientes de servidores e nuvem, como por exemplo instâncias EC2 da AWS, onde nós podemos nos conectar a instâncias remotas para gerenciá-las.

Outros usos incluem: Transferência de Arquivos Segura, Túneis Seguros....

Começando com SSH

Listando suas chaves SSH

Quando você gera chaves SSH, elas são armazenadas por padrão na pasta .ssh no diretório do seu usuário. Para listar todas as chaves SSH disponíveis, você pode usar o seguinte comando no seu terminal:

LINUX e MacOS

ls ~/.ssh

Windows

dir ~/.ssh

Este comando listará os arquivos na pasta .ssh, que geralmente podem ser os seguintes tipos de arquivos:

id_rsa: Sua chave privada RSA.
id_rsa.pub: Sua chave pública RSA correspondente.
id_dsa: Sua chave privada DSA (se você a gerou).
id_dsa.pub: Sua chave pública DSA correspondente.
Outros arquivos, dependendo de como você configurou suas chaves SSH.

Gerando uma Chave SSH

1. Instalando o Cliente SSH

O primeiro passo é garantir que você tenha um cliente SSH instalado em seu computador. Os clientes SSH estão disponíveis para Mac, Windows e Linux. Você pode encontrar links para download nos seguintes sites:

OpenSSH para Windows: Instale aqui se você for usuário do Windows.

OpenSSH para Linux: A maioria das distribuições Linux já inclui o OpenSSH, portanto, você não precisa instalá-lo separadamente.

OpenSSH para Mac: O macOS também inclui o OpenSSH. Portanto, você pode prosseguir para o próximo passo.

2. Gerando o Par de Chaves SSH

Com o cliente SSH instalado, abra o seu terminal e execute o seguinte comando:

ssh-keygen

Quando você executar este comando, o utilitário ssh-keygen iniciará o processo de geração de chaves. Ele solicitará que você indique onde deseja armazenar as chaves. Por padrão, as chaves são armazenadas na pasta .ssh em seu diretório de usuário.

O utilitário ssh-keygen também solicitará que você defina uma senha para proteger sua chave privada. Embora seja opcional, é altamente recomendável definir uma senha para aumentar a segurança.

IMPORTANTE: O uso de uma senha para proteger sua chave privada é altamente recomendado, pois adiciona uma camada adicional de segurança. Mesmo com acesso ao seu computador, sem a senha não é possível utilizá-la.

Recuperando sua chave pública

Após gerar o par de chaves, você pode recuperar a chave pública, que é a parte que você compartilhará com servidores e serviços que deseja acessar com SSH como AWS e GitHub.

Para copiar a chave pública para sua área de transferência, execute o seguinte comando:

No macOS e Windows:

pbcopy < ~/.ssh/id_rsa.pub

No Linux:

cat ~/.ssh/id_rsa.pub

A chave privada (id_rsa) permanecerá armazenada em seu computador e nunca deve ser compartilhada com ninguém.

That's all, folks!

Obrigada por ter lido até aqui e espero que o post tenha te ajudado a entender mais sobre o protocolo 💜

A Beginner's Guide to JavaScript's Single Thread and Event Loop

Fernanda Kipper — Mon, 10 Apr 2023 01:06:01 +0000

As a Single Thread non-blocking language, JavaScript can be a bit tricky to understand at first.
When I first began exploring the language, I found myself overwhelmed with questions about how it worked. In this article, I'll try to answer some of the most common questions I had when I first started learning about the JavaScript event loop. By the end of this article, you'll have a better grasp of how JavaScript manages to remain non-blocking despite being single-threaded, and you'll be better equipped to build efficient and responsive applications using this powerful language.

Single Thread

JavaScript is a single-threaded language, which means that it has only one thread of execution. This means that all operations are executed sequentially, one after the other, in a single call stack.

The call stack is a data structure used by JavaScript to manage function invocations. It keeps track of the current position in the execution context (the point where the code is currently being executed) and all pending function calls that have been made but not yet completed.

Whenever a function is called, a new frame is added to the top of the call stack, representing the execution context of that function. When a function completes, its frame is removed from the top of the call stack and control is returned to the previous function in the stack. This allows JavaScript to maintain the order of function calls and ensure that each function completes before the next one is executed.

Look at the following example of how the Call Stack works

Non-blocking

Non-blocking code is code that allows other code to execute while it is running. Specifically, asynchronous code, that should not block the execution of synchronous code that does not depend on it.

Asynchronous code should execute in the background, without interrupting the flow of the main program. Instead of waiting for an operation to complete before moving on to the next line of code, asynchronous code should allow the program to continue executing while the operation runs in the background.

Now, you should be thinking, how does JavaScript manages to be non-blocking since executes only in one thread?

Event loop

Event Loop is the mechanism used to JavaScript to handle asyncronous code.
When an asynchronous operation is started, it is added to the callback queue and removed from from call stack. The event loop constantly checks this queue for pending tasks waiting to be executed. If there are any pending tasks, the event loop will retrieve the next task and add it to the call stack for execution. Once the task is complete, its callback function is added to the callback queue. The event loop will continue to check the callback queue for pending tasks and add them to the call stack as necessary. This process allows JavaScript to execute asynchronous code in a non-blocking way, ensuring that the main program can continue to run while waiting for long-running tasks to complete.

Consider the following code:

What would happen in the Call Stack and Callback Queue would be:

1 - First the fetchData() function would be added to the Call Stack
2 - fetch() is added to the Call Stack and initiates a network request. The Promise created by fetch()is added to the queue.
3- console.log("hello") is added to the Call Stack.

4 - After that, console.log("hello") would be executed and removed of the Call Stack
5 - fetchData() is finished executing and is removed from the Call Stack
6 - The Promise created by fetch() is resolved with the response data and the then() method attached to the Promise is added to the queue.

7 - Event Loop would takes console.log(data) and adds to Call Stack
8- console.log(data) would be executed
9 - There are no more tasks to execute, and the program terminates.

Ok, that makes sense, but now you probably asking yourself, how does the fetch gets executeded?

Browser APIs

Browser APIs (Application Programming Interfaces) are interfaces provided by the browser or the host environment that allow us to perform various operations, such as making network requests, setting timeouts, and manipulating the DOM.

These APIs are used to handle asynchronous operations in JavaScript by offloading them to the browser or the host environment, which can perform the operation in the background without blocking the main program.

So, when a fetch request is made using the fetch() method , the browser's web API (Fetch API) handles the request, sending it to the server and waiting for a response. During this time, the JavaScript program can continue to execute, thanks to the event loop, which checks the callback queue for any pending tasks. Once the server responds with the requested data, the web API adds the response to the callback queue, triggering the callback function associated with the original fetch() request.

Interesting, isn't it?

Overall, understanding the principles behind the event loop, non-blocking code, and web APIs has been essential in my growth as a JavaScript developer, and I hope this article have helped you to get a better understing of these concepts.

This kind of knowledge can be a key piece for you to take your programming skills to another level.

Thats all :)

A Beginner's Guide to Github Actions

Fernanda Kipper — Sun, 12 Feb 2023 13:48:01 +0000

In this article, we will be diving into the world of GitHub Actions, exploring the basics of this powerful automation tool. Whether you are a beginner or an experienced developer, you will find that GitHub Actions is a valuable tool to have in your arsenal.

What is GitHub Actions?

GitHub Actions is a feature provided by GitHub that allows users to automate their software development workflows, including building, testing, and deploying code. With GitHub Actions, you can create custom automated processes that run whenever specific events occur in a GitHub repository. For example, you can configure a workflow that automatically builds and deploys your code whenever you push changes to a specific branch.

So, after this brief explanation, let's jump to the GitHub Actions features.

Workflow Files

A workflow file specifies the steps that should be taken to automate any task, like building, testing, and deploying your code or even sending an sms when someone opens a pull request.

The workflow files are composed of Events, Jobs, Runners, Steps and Actions.

Events

Events are the triggers for the workflow, they are what needs to happen for this workflow to fire and run the automated work.
Events are defined in the yaml workflow file by passing the on property.

Examples of events:

PR Created
Push
Issue Created
Collaborator Join
PR Merged

And you can specify branches, statuses, tags and paths to specifically limit the trigger to the desired event.

I recommend reading the documentation to know all existing events.

Jobs

Jobs group a set of steps that will be executed. After the Worflow is triggered, it will run all the jobs presented on it.
Inside the job we need to specified the runs-on property, that correspond to the enviroment this job will run, most commom is ubuntu-latest.

Steps

Each step in a job represents a single task that should be performed. The steps can be defined using either an action or a command-line command.

An action is called using the uses property, and its parameters are passed to the action through the with property. Alternatively, a command-line command can be executed using the run property.

Heres an example of an workflow.yaml file:

name: Test Workflow 

on:
  push: # Push event
    branches: # On branches 
      - 'releases/**'
      - 'master'

jobs:
  hello_world: # Define the job
    runs-on: ubuntu-latest # Specify the runner to run the job on
    name: Lint code
    steps:
      - name: Run Linter
        uses: github/super-linter@v3 # Use Github Super Linter repository
        with: # Input fot the action
          some_api_key: ${{ secrets.api_key }} # Get the API key from repository secrets
      - name: Print IPv4 # Some random command
        run: ifconfig -a # Run ifconfig command

⚠️ In order for your Workflow file to work correctly, it needs to be placed inside the /.github/workflows path within your repository.

-root
  -.github
    -workflows
     your_worflow_file.yaml

Once you've set up a workflow file within your repository, there's nothing left to do but code!

Actions Files

The actions are a pre-packaged set of instructions that perform a specific task. Whether you create your own custom actions or use actions from the GitHub Actions Marketplace, you can easily integrate them into your workflows using YAML files.

Actions are defined in a action.yaml file and must be stored in the root directory of your repository. It is recommended to store actions that will be used by third-parties or across multiple projects in a separate, dedicated repository that is publicly accessible. This ensures that the action is easily accessible and reusable by others.

Actions files are formed by name, description, inputs and runner.

Inputs

The inputs section defines the data needed to perform this action, which must be provided in the workflow that invokes them as mentioned earlier.

Runs

The runs section specifies the runtime environment for the action (example: Node.js version 12), and the main entry point for the action (example: dist/index.js).

Here´s an example:

name: "My Custom Action"
description: "A custom action for doing something cool."
inputs:
  input1:
    description: "The first input for the action."
    required: true
  input2:
    description: "The second input for the action."
    required: false
  input3:
    description: "The third input for the action."
    required: false
  ...

runs:
  using: "node12"
  main: "dist/index.js"

Main file

The main file used in an action is typically a script file that is executed when the action is triggered in a workflow. The script file can be written in a variety of programming languages, such as JavaScript, Python, or Ruby.

Here is an example of a JavaScript script that could be used as the main file in an action:

const core = require('@actions/core');
const exec = require('@actions/exec');

async function run() {
  try {
    const command = core.getInput('command');
    console.log(`Running command: ${command}`);

    await exec.exec(command);
  } catch (error) {
    core.setFailed(error.message);
  }
}

run();

Note that i used the @actions/core and @actions/exec, these libraries are part of the GitHub Actions Toolkit, a collection of libraries and tools provided by GitHub to simplify the development of custom actions for GitHub Actions.

The actual implementation of your main file will depend on the requirements of your action and the tools and services that you are integrating with.

Illustration

To summarize, I found this image on the internet that excellently illustrates the hierarchy within GitHub Actions, showing all the components discussed and their interrelationships. It serves as a visual representation of the concepts covered in this article and I believe it can help to better visualize how it works.

Thank you for reading this far and I hope it helped you understand a little more about this incredible feature on GitHub! 😊

Iniciando estudos de RxJs em Angular

Fernanda Kipper — Thu, 20 Oct 2022 17:33:03 +0000

O que é RxJs?

RxJs é uma biblioteca que fornece formas de trabalhar com programação assíncrona e baseada em eventos - reativa - usando observables. A biblioteca provém um tipo principal o Observable, tipos satélites como Subjects, Observers e Schedulers e também operadores para lidar a coleção de eventos assíncronos.

Recapitulando: o que são Observables?

O Observable é a peça chave do Design Pattern Observer, baseado em eventos o padrão define Observable como o objeto de interesse e que pode ser observado, o mesmo guarda uma lista de interessados em suas mudanças - Observers ou Subscribers - e emite um evento avisando aos interessados todas as vezes que ocorrer uma mudança em seus itens.
Se ainda não ficou claro, recomendo a leitura do meu post sobre o Padrão Observer antes de continuar.

RxJs + Angular

O novo Angular foi construído em cima da programação reativa, o uso de Promises foi abandonado e fora adotado o uso de Observables, e ai que entra o RxJs.

Requisições HTTP

Vamos começar com o básico, lidando com respostas de requisições HTTP. Normalmente, fariamos usando Promises como acontece em React JS, porém em Angular vamos usar Observables do RxJS.

Criando nosso service
Ele que realiza a requisição e retorna um Observable do tipo HttpResponse<User>

import { Injectable } from "@angular/core";
import { HttpClient, HttpResponse } from '@angular/common/http';
import { Observable } from 'rxjs';


export interface IUser {
  name: string;
  id: string;
  imgUrl?: string;
}

@Injectable({
  providedIn: 'root'
})
export class UserService {
  constructor(private httpClient: HttpClient) {}

  getUser(id: string):  Observable<HttpResponse<IUser>> {
    return this.httpClient.get<HttpResponse<IUser>>(`/api/users/${id}`)
  }
}

Consumindo

Nosso componente irá chamar o UserService, e para receber a resposta da requisição precisamos realizar o subscribe no Observable retornado pelo método getUser(), passando como parâmetro para o método subscribe um objeto do tipo observer

@Component({
  selector: 'app-user',
  templateUrl: './user.component.html',
  styleUrls: ['./user.component.scss']
})
export class UserComponent implements OnInit {
  private user!: IUser;

  constructor(private userService: UserService) { }

  ngOnInit(): void {
    this.getUserData();
  }

  getUserData(){
    this.userService.getUser('1234').subscribe({
      next: (data) => {
        if(data.body) this.user = data.body
      },
      error: (err) => console.log(err)
    })
  }
}

Observer
O Observer é o consumidor dos valores emitidos pelo o Observable, ele nada mais é que um objeto que possui callbacks para cada evento do emissor. Exemplo:

const observer = {
  next: x => console.log('Observer recebeu o prox valor: ' + x),
  error: err => console.error('Observer recebeu um erro: ' + err),
  complete: () => console.log('Observer completou o recibimento'),
};

Dentro de cada um desses callbacks podemos realizar o necessário com o dado emitido.

Eventos Pai -> Filho

O segundo caso que irei demostrar é quando precisamos que um componente filho reaja a um evento do seu pai.

Exemplo: enquanto a requisição para buscar o usuário não finaliza, quero que um componente filho mostre a mensagem "carregando" e quando finalizar ele mostra os dados normalmente.

Entendo o conceito de Subject

Enquanto Observables são unicast, ou seja, cada subscriber possui uma execução única e indepente (seu próprio "canal") do Observable pois cada subscribe() invoca uma nova execução. Os Subjects são multicast, eles não invocam uma nova execução para cada subscribe(), eles simplemente adicionam na lista de Observers e avisa a todos pelo mesmo "canal" quando houver uma mudança.

Criando um Behavior Subject
Para emitir eventos do pai para o filho, vamos utilizar Behavior Subject, que consiste em um Subject que possui valor inicial e emite seu valor atual para cada Observer inscrito.

Criamos um atributo isLoading$ no componente pai

  isLoading$: BehaviorSubject<boolean> = new BehaviorSubject(true);

Ao completar a requisição, atualizamos o valor para false

  getUserData(){
    this.userService.getUser('1234').subscribe({
      next: (data) => {
        if(data.body) this.user = data.body
      },
      error: (err) => console.log(err),
      complete: () => {
        this.isLoading$.next(false);
      }
    })
  }

Passando para o filho

<child-component
  [name]="user.name"
  [isLoading$]="isLoading$"
>
</child-component>

Recebendo no filho

import { Component, OnInit } from '@angular/core';
import { BehaviorSubject } from 'rxjs';
import { UserService, IUser } from 'src/app/shared/services/user.service';

@Component({
  selector: 'child-component',
  templateUrl: './child.component.html',
  styleUrls: ['./child.component.scss']
})
export class ChildComponent implements OnInit {
  @Input() name?: string;
  @Input() isLoading$: BehaviorSubject<boolean>;

  constructor(private userService: UserService) { }
}

Utilizando o Behavior Subject
Agora no template do componente filho vamos usar um condicional para saber quando mostrar "carregando".

Quando o valor atual for true => ele deve mostrar
Quando o valor atual for false => ele deve esconder a div

<div *ngIf="isLoading$ | async">
  <p>carregando</p>
</div>

Note que utilizei o pipe async, um recurso fornecido pelo Angular, que automaticamente realiza o subscribe no Observable - nesse caso é nosso Behavior Subject isLoading$ - e retorna sempre o último valor emitido. Se quiser saber mais sobre esse operador, recomendo a leitura da documentação do Angular.

Para usar o pipe async não esqueca de importar o CommonModule no módulo do seu componente.

Quando iniciei meus estudos em Angular, dois anos atrás, RxJs era um assunto bem conturbado para mim e existiam poucos conteúdos em português, mesmo ele sendo uma peça fundamental para construirmos aplicações mais robustas com Angular.
Então, resolvi compartilhar um pouco do que aprendi nesses anos para ajudar quem esteja começando agora, espero que você tenha gostado do artigo 😊

Seu feedback é bem vindo!

Programação Orientada Objetos e Programação Procedural - entendendo a diferença

Fernanda Kipper — Sun, 30 Jan 2022 15:58:04 +0000

Em algum momento na nossa carreira de desenvolvedores topamos com uma discussão sobre paradigmas de linguagens de programação. E como é importante entendermos mais sobre as vantagens que uma linguagem pode nos trazer para fazermos a escolha mais vantajosa para nosso projeto, entender a diferença e as vantagens dos paradigmas de programação vai nos ajudar. Então, foi pensando nisso que resolvi escrever esse post explicando a diferença e trazendo alguns exemplos práticos de dois paradigmas de programação, o procedural e o orientado a objetos.

Programação orientada a objetos

A Programação orientada objetos (POO) se baseia na ideia de que tudo são classes e objetos, as classes são como agrupadores e objetos são os participantes desses grupos. Cada classe define atributos e métodos que são comuns a todos pertencentes a essa classe, nesse caso a cada objeto que seja uma instância da classe. Os objetos podem possuir um atributo que seja _IGUAL _ a todos pertencentes á classe, que são chamados de atributos da classe, ou atributos que apesar de definirem a mesma coisa não possuem o mesmo valor, chamados de atributos do objeto (como por exemplo o nome, toda pessoa possui um nome, mas não obrigatoriamente toda pessoa possui o mesmo nome). Os métodos são abstrações para esconder os detalhes dos objetos, expondo apenas as funções que operam seus dados.
Outro conceito muito importante no mundo de POO, é o de polimorfismo, que simplificando é o princípio de que classes derivadas de uma mesma superclasse (classe mãe) expõem métodos que possuiem a mesma identificação porém com implementações diferentes, pois cada classe possui sua singularidade e por isso comportamentos distintos para realizar a mesma ação. Exemplificando: imaginamos a superclasse VeiculoDeLomocoção, ela define que todas suas derividas devem possuir o método limpar, a classe derivada Carro implementa o método limpar que seria passar lava-jato e cera em todo carro, já a classe Bicicleta implementa limpar como apenas passar uma mangueira no veículo. Entrentanto, esse comportamento interno não importa pra quem vê a classe de fora.

Programação Procedural

Por outro lado, a Programação Procedural (PC) ou também chamada como Programação Estruturada se resume a modularizar instruções da execucação do programa em procedimentos. Os procedimentos contêm um conjunto de passos computacionais a serem executados. Um dado procedimento pode ser chamado a qualquer hora durante a execução de um programa, inclusive por outros procedimentos ou por si mesmo. Os procedimentos podem receber parâmetros para realizar manipulações e podem ou não retornar valores, e diferente do conceito da programação funcional, procedimentos também podem causar efeitos colaterais como os métodos de objetos.
Então simplificando a diferença de conceitos entre uma função e um procedimento é de que uma função sempre retornaria algum valor e não modificaria nenhum parâmetro fora de seu escopo, já os procedimentos podem modificar algo fora de seu escopo e não necessariamente retornam algum valor. Essa alteração de dados de fora de seu escopo que são os chamados de efeitos colaterais.

Na prática 💪

No livro Clean Code do Uncle Bob, no capítulo acerca de Estrutura de Dados e Objetos ele menciona um exemplo muito claro sobre a diferença desses dois paradigmas, então resolvi trazer o mesmo exemplo nesse post para analisarmos a implementação do mesmo programa nos dois paradigmas e compararmos suas diferenças.

Imagine o seguinte cenário, precisamos calcular a área de algumas formas geométricas, cada uma possui uma fórmula diferente para o cálculo de sua área.

Em POO a implementação aconteceria mais ou menos da seguinte forma

💡 Consideramos Shape como sendo uma interface que define o contrato para que uma forma seja uma forma geométrica

public class Square implements Shape {
    private double sideValue;

    //construtor

    public double area() {
        return sideValue*sideValue;
    }
}

public class Rectangle implements Shape {
    private double heigth;
    private double width;

    //construtor

    public double area() {
        return width* heigth;
    }
}

Se quissemos calcular a área de qualquer uma dessas formas, bastaria:

public double squareAreaValue = new Square(4);

Já em PC a implementação seria diferente:

public class Square {
    public double sideValue;
}

public class Rectangle {
    public double heigth;
    public double width;
}

public class Geometry{
    public double area(Object shape) throws NoSuchShapeException{
        if (shape instanceof Square) {
            Square s = (Square)shape;
            return s.sideValue* s.sideValue;
        }
        else if (shape instanceof Rectangle ) {
            Rectangle r = (Rectangle )shape;
            return r.width* r.heigth;
        }
        else
            throw new NoSuchShapeException();
    }
}

Se quissemos calcular a área de uma dessas formas no último exemplo fariamos o seguinte:

public Square square = new Square();
square.sideValue = 4;
public Geometry geometryCalc = new Geometry();
public double squareAreaValue = geometryCalc.area(square);

Comparando:

Uma das maiores diferenças na minha opnião é a forma em que os dados são tratados, note que no exemplo de POO nós manipulamos os objetos mas não temos acesso direto aos valores e nem mesmo sabemos como os valores são utilizados para o cálculo da área, pois os objetos expõem apenas o método necessário para obter a área da forma geométrica e abstraem seu funcionamento interno.
Já no exemplo de PC percebemos os valores como uma estrutura de dados, e segundo Uncle Bob

As estruturas de dados expõem seus dados e não possuem funções significativas para a sua manipulação.

Mas diferente do primeiro exemplo nós conseguimos manipular diretamente esses valores e realizar implementação que desejamos com eles.

Outra diferença, também citada em Clean Code é que a facilidade e a dificuldade de implementação são invertidas em cada um dos paradigmas. Como assim? Note que ao usar as estruturas de dados em PC, podemos adicionar novos procedimentos facilmente, por que precisamos alterar apenas um local, porém para adicionar uma nova estrutura de dados teriamos que alterar todos os procedimentos que as utilizam - imagine se tivessemos um procedimento para calculo da área, outro para perimetro, outro para mediatrix, todos teriam que ser alterados para prever essa nova forma geométrica.
Mas em POO temos o contrário, para adicionar um novo método seria mais trabalhoso por que teriamos que alterar todas as classes de formas geométrica para implementar esse novo método, já para adicionar uma nova classe (uma nova forma geométrica) precisariamos alterar apenas um local, que seria criando a nova classe seguindo a interface Shape.

Além disso, mesmo com os exemplos estando na mesma linguagem, notamos que cada um faz o uso dos recursos da linguagem de maneira diferente, mostrando que uma linguagem não é obrigatoriamente presa a um paradigma.

Testes unitários Frontend - Como Mockar Módulos e React Hooks usando apenas o Jest

Fernanda Kipper — Thu, 30 Dec 2021 16:25:17 +0000

Olá Pessoal! Nesse post eu vou explicar algumas maneiras que você pode adotar para realizar os mocks dos seus testes unitários.

Mockando imports de módulos

Caso as funções ou componentes que você deseja mockar nos seus testes venham de um módulo externo, existe uma maneira de utilizar apenas o objeto Jest para realizar o mock.
Exemplo, digamos que queremos testar se nosso componente está chamando corretamente a função push retornada pelo hook useHistorydo módulo react-router. Nós podemos mockar a função pushe usá-la no expect do nosso teste para ter certeza que ela foi chamada, para fazer isso nos devemos:

Criar uma função de mock usando o método do Jest jest.fn() que retorna uma função de simulação OU criar nossa própria implementação

   // OPÇÃO 1
   const mockPush = jest.fn()
  // OPÇÃO 2
  const mockPush = () => {
    // alguma funcionalidade...
    // return algo
  }

Mockar o import do módulo react-router no ínicio do arquivo antes de iniciar os testes, dessa forma toda vez que um componente renderizado pelo Jest durante o teste tentar importar esse módulo, o Jest substituirá o real conteúdo por aquele que nos mockamos

  jest.mock('react-router', () => ({
  ...jest.requireActual('react-router'),
  useHistory: () => ({
    push: mockPush
  })
}))

🎯 Note que usamos o método requireActual do objeto Jest que retorna o módulo real e com o spread operator copiamos tudo do módulo verdadeiro e apenas subsstituimos o que precisávamos testar, nesse caso o hook useHistory e seu retorno.

Caso queira saber mais sobre o objeto Jest e seus métodos, recomendo muito que você leia a documentação do Jest

Agora, ao escrever seu teste unitário você deve utilizar a função mockada mockPush para conferir o resultado com o expect, e pronto!

await waitFor(() => expect(mockPush).toHaveBeenCalledWith('sua-rota'))

Mockando React Hooks

Em testes unitários de componentes React, é muito comum precisarmos mockar Hooks para realizar verificações de comportamento em nossos componentes. Caso você deseja mockar apenas a implementação de um hook, também é possível utilizar apenas o objeto Jest para realizar nosso teste.

Primeiro você deve importar todo o arquivo que contém seu hook, o que retornará um objeto que contém todos os retornos desse arquivo

import * as MeuHook from 'path-para-seu-hook'

No ínicio do arquivo antes de iniciar os testes mockaremos UM dos retornos desse arquivo, nesse caso o hook, usando o método do Jest jest.spyOn que cria uma função de mock similar ao jest.fn mas também observa todas as chamadas pelo objectDoArquivo[nomeDoMétodo]
- O primeiro parâmetro que passamos ao jest.spyOn é justamente o objeto contendo todos os retornos do nosso arquivo
- E o segundo parâmetro é o nome do método (o nome do hook ou função) que é exportado desse arquivo e queremos observar (note, caso seu hook seja exportado através de um export default em vez de fornecermos o seu nome, passaremos 'default' como parâmetro)

  jest.spyOn(MeuHook, 'useNomeDoMeuHook')

Agora temos duas opções, podemos mockar a implementação do hook para todo o nosso arquivo de teste, ou seja, para cada test case ele retornará o mesmo valor, OU, podemos realizar uma implementação diferente para cada test case
2.1 Caso queiramos a mesma implementação para todo o arquivo, podemos realizar a declaração junto com método spyOn e todos os nossos tests cases terão acesso ao mesmo mock

  jest.spyOn(MeuHook, 'useNomeDoMeuHook').mockImplementation(() => 
  {
    //  implemente aqui
  })

2.2 Caso contrário, guardaremos o retorno do spyOn em uma constante

  const useNomeDoMeuHookMock = jest.spyOn(MeuHook, 'useNomeDoMeuHook')

E dentro de cada test case realizaremos a diferente implementação

test('It should ....', async () => {
  useNomeDoMeuHookMock.mockReturnValue(// valor retornado pelo hook)
})

E por fim, não podemos nos esquecer de depois de cada teste limpar o mock para não sujar as implementações dos próximos testes, por isso colocaremos no inicio do nosso suite de testes a função afterEach para resetar nosso mock

describe('...', () => {
  afterEach(() => {
      useNomeDoMeuHookMock.mockClear()
})

  test()....
})

Obrigada por ter lido até aqui e espero que eu tenha te ajudado! Qualquer dúvida ou sugestão fique a vontade para entrar em contato comigo 😀

Algorithm Time Complexity Simplified

Fernanda Kipper — Fri, 10 Sep 2021 01:22:12 +0000

Recently, I have been studying about algorithm complexity, and as I like to share and write about things that I am learning, I have decided to talk about this subject to help others by sharing what I learned so far.

How to measure Algorithm Complexity

First of all, lets talk about what counts when we are performing the time complexity measurement of an algorithm. And to do that, we need to understand what Asymptotic complexity stands for.
But remember, we can't measure the time complexity of a program, just an algorithm, and algorithms always end at some point.

Asymptotic complexity

If we compare the absolute time of executation of two algorithms, we would be comparing subjective values, since they are specific to particular hardware and context. For example, even if we run both algorithms on the same computer each program would have to run without sharing CPU with other programs or operating system service and even the order in which we run the programs can affect the result, due to the thermal characteristics of the CPU or the mere oscillation of the ambient temperature.
So, we need to compare their running time mathematically, here where the term Asymptotic complexity comes in, considering that the time complexity of an algorithm summarizes how the execution time of algorithm grows with the input size.

This growth is calculate based on how many steps (for example, how many times it enters in a for loop) an algorithm need to do ir order the solve a problem given an n number of elements to be counted.

But we cannot considerer just one value of n to measure a complexity of an algorithnm, because as we know, a program can be very efficient for big values but not the best choice for small values and the other way around.

Worst and Best Case

Since its almost impossible to consider all cases, we choose the worst and best scenario of an input to calculate the complexity of certain algorithm.

Worst case runtime means that you are feeding the worst possible input (of that size) into your algorithm. Best case runtime means that you are feeding the best possible input into your algorithm, which is the fastest scenario

Big O Notation

In short way, the big O notation is way to classify how scalable our algorithm is. This helps us determine how our algorithm will behave in the WORST case or how long it will take to complete based on its input values.

To get the final equation, there are some rules we need to follow, first is to drop constant values (such as variable declaration and other expressions that just happen once while your algorithm is running regardless of input size) and non-dominate terms (i will explain in the next section) since this one has minimal effect on the growth curve of time complexity when the input size are very large.

Being the horizontal line the growth of time complexity and the vertical line the input size, note that the equations that have exponential degree are the worst ones, because as the number of input size grow, the time complexity is more then duplicated and constants would have almost no effect on the growth of this curve.

Pratice

After all the theoretical explanation, let's dive into it and get our hands dirty.
Let's considerer the following algorithm, which print all possible pairs given a certain array, the order matters and a element cannot be a pair with it self.

void printPossiblePairs(int data[], int len){
  int cont, cont2;
  for(cont = 0; cont < len; cont++){
    for(cont2 = 0; cont2 < len; cont2++){
      if(cont != cont2){
        printf("%d - %d\n", data[cont], data[cont2]);
      }
    }
  }
}

This algorithm´s worst and best scenario are equal.

Checking step by step, we need to conclude how many times each step would repeat based on input size that we will call N - in this case the input size consists on the array length. So let's analyze the algorithm shown earlier:

First line, will execute only once

void printPossiblePairs(int data[], int len){
  int cont, cont2; // (1)

This line will execute (n + 1) times, in other words, will execute one time for every element on the array + one (when it checks that the loop is end)

  for(cont = 0; cont < len; cont++){ // N + 1

This line will execute (n + 1)(n + 1) times
Because it will run N + 1 times every time the outermost "for" executes (that is N + 1 as well)

    for(cont2 = 0; cont2 < len; cont2++){ // (N + 1)(N + 1)

Will run just one time on all the times the above for loop runs
Note that if statement has almost no effect in time complexity

     if(cont != cont2){ // (N + 1)(N + 1)(1)

To finish, this line will run only when the indexes cont are different, meaning all the times the for loop runs minus one, cause they will be igual just once

     printf("%d - %d\n", data[cont], data[cont2]); //// (N + 1)(N + 1)(1) - 1

Then, your final equation is (N + 1)(N + 1)(1) - 1
Notice that we reduce
Based on the rules we talked about before, we drop constant values such as (1) and - 1, cause this terms have no effect when we are dealing with big input numbers, so we leave only dominate terms
(N+1)(N+1)
Dropping costants
(N)(N)
(N²)
Our Big O is: O(N²)
When N increases, the running time increases by N * N.