Nesse artigo você vai:

- Aprender sobre NFTs
- Aprender sobre Near Protocol
- Aprender como criar uma conta Near na Mintbase Wallet
- Aprender como criar um Contrato na Near através da Mintbase
- Aprender como mintar e listar um NFT
- Aprender como criar sua própria Marketplace na Vercel usando Mintbase.js e Next.js

A idéia desse artigo é trazer uma forma de introduzir os NFTs para entusiastas dos assuntos e abordar as diferentes perspectivas e formas de iniciar no mundo desses ativos digitais.
Eu, sou o Ruben, Desenvolvedor Sênior na Mintbase a 1 ano e meio, e atualmente tenho uma coleção de 2119 tokens, e 449 tokens listados a venda ( muitos de graça ), e mais de 4824 transações.

O que são NFTs?

NFTs (Non-Fungible Tokens), é uma tecnologia que visa identificar ativos fisicos ou digitais , através de metadados registrados na blockchain. A ideia de tokenizar ativos digitais vem de encontro a possibilitar que artistas, ou colecionadores de itens digitais, não só artes, como skins de games, videos, e diversas diferentes midias, mas também bens fisicos (como roupas, tênis, itens de colecionadores e até casas), sejam autenticados e comercializados através dos NFTs.

Para quem são os NFTs?

Para todo mundo. Foi construida uma idéia e um pré-conceito de que os NFTs são mais um esquema de piramide, ou de golpes devido a casos famosos, e devido também a desconfiança de muitas pessoas, por generalizar os NFTs apenas como "jpegs de macaco".
Porém os NFTs são muito mais do que isso. Bens digitais e fisicos são transacionados todos os dias através dos NFTs.
Para o nosso caso de uso específico, podemos dizer que as chances de você enriquecer vendendo NFTs são bem baixas, porém você pode sim conseguir alguma compensação financeira vendendo artes,fotografias,mídias digitais que você produzir e enviar para a blockchain.
Uma das vantagens dos NFTs que após listado, você pode passar a ganhar royalties em cima de cada transação, sendo uma forma de renda contínua e indefinida para o criador ( minter ) do NFT.

Porque criar um Marketplace?

O marketplace seria basicamente o seu site com a galeria de NFTs disponiveis na sua loja de NFTs ou no seu perfil de usuário. Você pode atrair visitantes para o seu site, customizar o design, adicionar novas features, e caso seja um artista, ou alguém que quer obter financiamento de seus fãs ou fidelizar sua audiência, os NFTs é uma maneira de realizar isso.

Near Protocol

A Mintbase funciona em cima da Near Protocol. A Near é a blockchain com mais usuários ativos na web3 (com 3.7milhões de usuários ativos todos os dias), e é uma das mais rápidas e com os custos reduzidos. Para você ter uma noção o custo de mintar (subir um NFT) na Ethereum que é a blockchain com maior numero de smart contracts, pode chegar a mais de 20 dolares ou até mais só para custear os custos da transação. Enquanto na Near é comum ser muito menos que 1 dolar.

Testnet

Dentro da Blockchain existe uma 2 redes principais: Mainnet ( a rede pra valer onde você coloca seu saldo em cripto e faz transações na cripto ), e a "Testnet" que é uma rede com saldo fake, onde qualquer um pode fazer diversas transações sem custo algum. Porém como o próprio nome diz é "testnet", você não pode depois converter o cripto que você ganhou com vendas e royalties para outras criptos, ou pra moeda comum ( dólar, euros, reais ), o tutorial escrito nesse artigo tem a intenção de introduzir um marketplace em ambiente testnet, porém oferece alternativas para fazer também em Mainnet, com todos os custos agregados.

Mintbase.js

Mintbase.js é a biblioteca da Mintbase para interagir com os NFTs e o indexador da Mintbase na blockchain da Near. Tem diversos módulos como o @mintbase-js/data, @mintbase-js/sdk e o @mintbase-js/react, que são os packages que vamos utilizar nesse tutorial.

Fique a vontade para reportar bugs, adicionar sugestões e passar feedbacks no nosso canal do telegram ou no nosso repositório do Github.

Passo 1: Criar uma conta Near

- Criando uma conta Near na Mintbase Wallet

Caso você esteja usando um dispositivo Windows eu recomendo criar sua conta em https://app.mynearwallet.com

Acesse https://testnet.wallet.mintbase.xyz

Clique em Continue, ele vai perguntar a permissão de passkeys, (ainda sem suporte pro Windows, apenas dispositivos IOS e Android )

caso seu dispositivo tenha suporte a autenticação por digitais ele vai pedir a autorização:

ele vai criar sua conta e trazer a tela de sucesso:

Agora vamos criar sua Store ( Smart Contract ) na Near no site da Mintbase:

- Criando seu Contrato na Mintbase:

• vá a https://testnet.mintbase.xyz/
• no topo na direita clique em Connect Wallet
• clique em Mintbase Wallet
• ele vai te redirecionar para a Mintbase Wallet:

• Clique em Continue, ele vai logar e te redirecionar para a Home da Mintbase.
• Visite esse site e digite o address da sua conta ( vão te transferir 10 N )
• Dentro do site da Mintbase logado na Home vai ter esse widget:

• Clique em Deploy NFT Contract
• Ele vai pedir o nome do contrato ( vai ser o address dele ) e o symbol:

• Clique em Deploy, ele vai para a pagina de transação na Wallet, e debitar (3.7 N) :

• Você vai ver a tela de sucesso:

• Na página de Contract Settings, você consegue customizar toda a sua loja, colocando links, fotos de capa, foto de perfil, entre outras opções.
• Na página de Mint NFT você vai mintar o seu NFT.

Mintando seu primeiro NFT

Na página de Mint, vou mintar a foto do cachorro caramelo, meu cachorro favorito. Como esse é um contrato testnet, não existe o problema de direitos autorais, pois é só um teste, mas uma vez mintando em Mainnet, saiba que seu NFT e até o contrato pode ser derrubado caso infrinja direitos autorais.

• No N de Tokens, esse é o numero de tokens que esse NFT vai ter. É como se fosse o número de edições. Imagine que você tem um evento de música e o NFT é o ingresso. O Número de tokens é o numero de ingressos. É a mesma lógica aqui.

• Adicionando Royalties, na parte de Forever Royalties, você consegue adicionar até 25 contas que podem receber royalties de todas transações que esse NFT vai fazer indefinidamente.

• As outras opções dessa página são mais relativas a metadados extras do seu NFT.
• Clique no botão Mint NFT
• Ele vai abrir a página de transação na Wallet, clique Continue

• Pronto você Mintou seu primeiro NFT!
• Agora vamos Listar o NFT para venda, clique nesse botão:

• Preencha os campos e clique em Make Listing

• Ele vai redirecionar para a página de transação da Mintbase Wallet.
• Aprove a transação
• pronto seu NFT está listado para venda

Criando seu Marketplace

• Vamos primeiro acessar a página de Templates da Mintbase , clique em Deploy
• Ele vai abrir a página da Vercel para Deploy, primeiro crie o repositório:

• Sete as env vars e clique em Deploy:

• Sucesso sua Loja foi criada!

• Essa loja do cachorro caramelo pode ser acessada aqui
• Você pode customizar sua aplicação Next.js dentro do repositório que você criou na sua conta do Github. É uma aplicação Next.js 14, fique a vontade para customizar e caso criar mande pra gente para divulgarmos!
• Para fazer o mesmo processo em Mainnet você precisa criar uma conta em https://wallet.mintbase.xyz e fazer as mesmas etapas em https://www.mintbase.xyz, Porém por ser Mainnet você não consegue usar Near Faucets, você precisa comprar Near na sua exchange de preferencia como Binance, Coinbase etc, e transferir para sua conta Near.
• Quaisquer dúvidas,idéias, sugestões, basta entrar em contato pelo Telegram, Linkedin, ou até e-mail

Ser um desenvolvedor pode ser bem frustrante muitas vezes.
Digamos que as frustrações façam parte do dia-dia do trabalho.
Algumas dessas frustrações nunca vão mudar e você apenas tem que aprender a lidar com elas.
Aqui está uma lista que contém 9 frustrações que programadores passam com frequência com as quais você pode se identificar.

1. Requisitos que mudam constantemente

Você já esteve nesta situação mais de uma vez. Você está no meio da implementação de um novo recurso, quando recebe uma atualização do cliente.
Os requisitos para a tarefa que você está implementando mudaram.
Como resultado disso, é provável que você tenha que refazer ou reescrever partes do seu código.
Existem muitos motivos pelos quais os requisitos podem mudar inesperadamente.
Por exemplo, falta de comunicação, mudanças organizacionais, pressão externa ou mudanças nas leis e regulamentos.

Embora a razão para essas mudanças de requisitos, pode ser legítima, ainda é uma das maiores possibilidades para qualquer desenvolvedor se sentir desgastado e frustrado, especialmente se é recorrente.

2. Toda solução que você tentou não funciona.

Você pode estar trabalhando em uma tarefa complexa e tentando encontrar a melhor solução possível para a tarefa.
Se você é um desenvolvedor inexperiente, provavelmente se identifica com isso.
Você tem algumas soluções para resolver o problema em sua cabeça.
Você começa a digitar no teclado para implementar a solução.
A primeira solução não está funcionando. Não chega nem perto de uma solução funcional.
Ok, vamos para a segunda solução. Você começa alterando algumas linhas de código para tentar fazer o código funcionar. Que droga… sem sucesso também.
Você começa a ficar frustrado porque não tem mais muitas opções ou idéias para resolver esse problema.
É quando você chega a um ponto que todos os desenvolvedores já passaram. Você começa a olhar para a tela na esperança de uma solução que surja do nada.
Isso pode ser especialmente frustrante quando você tem um prazo curto de entrega, e se você passou horas, talvez o dia inteiro buscando uma solução.
Geralmente a solução costuma vir de um colega, ou em um momento em que sua cabeça não está quente e obcecada com o problema.

3. Reuniões sem sentido

Todos nós sabemos daquela reunião que poderia ter sido um e-mail.
O problema com as reuniões é que elas são o assassino número um da produtividade.
A maioria dos desenvolvedores participa de muitas reuniões.
O problema com as reuniões é que a maioria das reuniões é agendada para uma hora por padrão, mesmo que a agenda pudesse ser tratada em menos de meia hora.
Além disso, podemos dizer não a muitas reuniões. Ou talvez você deva começar a dizer não às reuniões antes do meio-dia, para que possa ser produtivo pela manhã.
E se você realmente tem que dizer sim a uma reunião, pelo menos diga não a reuniões longas.
Comparecer a muitas reuniões é um hábito de programadores ineficazes.

4. Andando em círculos

Você conhece esse sentimento? Acontece quando você começa a digitar um monte de código tentando resolver um problema. Você começa a cavar em busca de informações sobre como resolver o problema que está enfrentando.

A resposta que você encontrou no Stack Overflow não é à prova de balas, então você começa a procurar mais respostas sobre como fazer a resposta ideal para o seu problema.

Aquele tutorial com um caso de uso muito parecido com o seu, ajuda mas não funciona 100% como deveria.

De repente, você está se perguntando qual era o problema inicial ,que você estava tentando consertar ou por que você escolheu esse caminho em primeiro lugar.
Antes que você perceba, você está andando em círculos.

5. Requisitos mal definidos

Outro ponto de frustração para a maioria dos desenvolvedores é quando você se depara com requisitos mal definidos.

Você e sua equipe acabaram de concluir o planejamento do sprint e cada história de usuário parecia muito bem definida.
Não havia espaço para interpretações erradas.

Você começa escolhendo a história de usuário de maior prioridade e lê a descrição. Então você lê de novo. Um dos critérios de aceitação não é claro.

Pode ser interpretado de várias maneiras. A primeira coisa que você se pergunta é: como perdemos isso durante o refinamento e o planejamento da sprint?

Em vez de ser produtivo e trabalhar em uma história de usuário, agora você precisa verificar com o product owner para ter certeza de que vai construir algo que corresponda às expectativas do cliente — demorado e frustrante.

6. Problemas Cross-browser

Esta é uma frustração com a qual qualquer desenvolvedor front-end pode se identificar.

Você está trabalhando em um recurso que concluiu. O QA começa a testar a história do usuário e conclui que o recurso não funciona em seu navegador.

Acontece que sua solução só funciona em alguns dos navegadores que você deveria oferecer suporte.
Isso é especialmente frustrante quando você precisa oferecer suporte ao Internet Explorer. Ou como eu gostaria de chamá-lo: o navegador cujo único propósito é fazer o download de um navegador real.

Ou ao Safari.
Às vezes, alguns dos recursos mais recentes ainda não funcionam em todos os navegadores. Isso faz com que você reescreva a solução para que todos os navegadores sejam suportados.
Frustrante e demorado!

7. Sem documentação

A falta de documentação é uma grande frustração para todo desenvolvedor que é novo em uma equipe ou projeto.

Sem nenhum conhecimento prévio sobre um projeto, é difícil trabalhar nele. Provavelmente, é ainda mais difícil fazer o projeto rodar em sua máquina local.

Ter algum tipo de documentação que explique como colocar um projeto em execução em sua máquina e que explique alguns dos principais recursos é o mínimo.
Idealmente, você deseja ter uma documentação extensa para permitir que você tenha uma boa compreensão de um projeto.

Se você tiver a documentação do seu projeto, certifique-se de mantê-la atualizada.
Porque o que é ainda pior do que falta de documentação é a documentação errada e desatualizada.

8. Não ter reconhecimento da equipe ou empresa.

Você trabalha até mais tarde. Você entrega os projetos e suas tarefas antes do prazo. Na daily você fala no tempo reservado a você e sempre se mostra disposto a ajudar e ouvir seus colegas, sempre entra em calls pra ajudar quem tem dúvida, e mesmo assim a empresa ou seus colegas não o reconhecem.

Você muitas vezes trabalha feriado ou final de semana, por alguma exigência urgente do cliente, e depois ele diz que nada do que você fez vai ser usado, e que pode ser jogado fora.

Você vê outros desenvolvedores que produzem código ruim, mas que puxam o saco do chefe ou da empresa, terem promoções ou mais destaque na equipe, do que quem realmente entrega as tarefas. Pior ainda, eles (outros desenvolvedores, ou chefe) fica com todo crédito pelo seu trabalho, quando na verdade quem arrumou o código ruim dele foi você.
Quem palestra nas dailys ou reuniões e apresentações da empresa são eles e não você.

Isso frustra qualquer desenvolvedor motivado.

9. Nunca ser bom o suficiente ou síndrome do impostor

Por último, mas não menos importante, temos uma frustração que provavelmente nunca irá embora. Como desenvolvedor, uma coisa é certa, você nunca irá parar de estudar. A sensação de nunca ter domínio suficiente pode ser muito frustrante.
Se você tem alguma experiência como desenvolvedor, saberá que, depois de concluir um projeto, você passará para o próximo.
Você pode sentir que não há tempo para respirar. Você sempre se encontrará indo de um prazo para outro.

Você chegou ao final da lista. Você já passou por alguma frustração dessa lista? Ou não coloquei alguma coisa pelo qual você já passou? Fique à vontade para escrever nos comentários! 👇

Créditos

Frustrations That Every Developer Can Relate To escrito por Daan

Neste post, iremos explorar ReactRPC, uma biblioteca de integração do lado do cliente para React e gRPC-web para ajudar os desenvolvedores a ter mais facilidade na criação de uma arquitetura de serviço gRPC completa de ponta a ponta.

O que é gRPC-web?

Nos últimos anos, o gRPC tem sido o padrão ouro de estruturas escalonáveis ​​e de desempenho para interatividade de microsserviços.

Ao converter todos os dados em binários, o gRPC é capaz de enviar informações pela Internet em um ritmo muito mais rápido e ser facilmente compreensível por qualquer linguagem de programação popular.

Empresas como Google, Netflix e Spotify se uniram a ele, anunciando a migração total das atuais estruturas de comunicação interna para adotar totalmente o gRPC em sua arquitetura de servidor.

Para aproveitar o poder do gRPC no navegador, o Google e o Improbable desenvolveram duas implementações diferentes de uma biblioteca do lado do cliente chamada gRPC-web.

Embora seja um marco incrível, a criação de uma integração mais perfeita para back-ends escritos em qualquer linguagem popular para interagir diretamente com os clientes, o gRPC-web ainda tem alguns detalhes a serem resolvidos antes de encontrar um lugar confortável na maioria dos kits de ferramentas de desenvolvedores front-end.

Em particular, um ponto problemático foi adotar o gRPC-web em estruturas da web modernas que todos os desenvolvedores usam para construir aplicativos em grande escala.

Conheça o ReactRPC!

Antes do ReactRPC, os desenvolvedores de front-end que buscavam usar o gRPC-web teriam que configurar muitos bolerplates antes de cada solicitação ser enviada.

Felizmente, o gRPC-web abstrai todos esses problemas, reduzindo a curva de aprendizado da implementação, melhorando a implementação rápida e mantendo o código legível.

Em primeiro lugar, para que o gRPC possa criar canais de comunicação entre servidores de diferentes linguagens, ele cria um acordo sobre o que pode ser enviado e recebido entre o cliente e o servidor na forma de um arquivo .proto.

Para que o navegador entenda este contrato, ele deve converter o arquivo .proto em dois arquivos Javascript, exigindo que os desenvolvedores se aprofundem no código gerado automaticamente para descobrir quais chamadas gRPC-web foram nomeadas e, em seguida, nos documentos gRPC para determinar como usá-las .

Isso abre possíveis erros nas configurações iniciais e análises profundas e demoradas nas duas especificações diferentes do gRPC-web, o que pode superar quaisquer benefícios potenciais de abandonar sua arquitetura RESTful.

O ReactRPC tira todo o esforço das mãos do desenvolvedor, pegando os dois arquivos como argumentos (bem como o URL ao qual você está se conectando) e analisando esses arquivos para você no estilo do Google ou do Improbable.
É simples:

const messages = require("../../helloworld_pb.js");
const clients = require("../../helloworld_grpc_web_pb.js");
const {improbRPC,googleRPC} = require("reactRPC");

reactRPC = googleRPC  // ou reactRPC = improbRPC

reactRPC.build(
messages,
clients,
"http://" + window.location.hostname + ":8080"
);

A segunda abstração que o ReactRPC faz é manipular mensagens gRPC para você.
Por meio do gRPC-web, você só pode enviar mensagens predefinidas fornecidas pelo arquivo proto.
Cada dado que você deseja anexar a esta mensagem deve ser adicionado manualmente por métodos setter na classe da mensagem, o que torna difícil de manejar para mensagens grandes e complexas e resulta em código repetitivo ao enviar várias mensagens.
Com ReactRPC você pode usar objetos para representar suas mensagens.
Para permitir que o ReactRPC saiba que esta é uma mensagem, você define os pedaços de dados que precisam ser enviados usando pares de valores-chave correspondentes ao seu arquivo proto e, em seguida, define um campo msgType com o nome da mensagem.

//proto file

message fullName{
string firstName = 1;
string lastName = 2;}

//index.js

const msg = {
 firstName: "John", 
 lastName: "Doe", 
 msgType: "fullName" 
}

Por último, as chamadas da função estão disponíveis em todos os seus componentes, tornando tão fácil enviar um unário gRPC-web e chamadas de streaming quanto uma solicitação POST.

Ele modela seu arquivo proto de perto, portanto, enviar qualquer chamada é tão simples quanto ler o arquivo proto para o serviço e o nome da chamada e, em seguida, chamá-los em seus adereços com sua mensagem, headers e callbacks *.

*Callback não são necessários para chamada de streaming

//proto file

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}
//index.js

this.props.Greeter.sayHello(
  message,
      {},
      (err, response) => {
        console.log(response)
      }
    );

E você está pronto! ReactRPC fez todo o trabalho pesado para você na configuração de seu front-end. Esperamos que esta postagem tenha encorajado você a começar a implementar gRPC-web em seu aplicativo React.

Links

oslabs-beta/ReactRPC

Créditos

• gRPC-web and React: A match made in Heaven por Karandeep Ahluwalia

Você vai ouvir muitas pessoas reclamando que JavaScript é estranho e às vezes inútil. As pessoas reclamam assim porque não entendem como as coisas funcionam nos bastidores. Embora eu concorde que alguns cenários em JavaScript sejam tratados de maneira diferente, isso não o torna estranho, mas bonito à sua própria maneira.

Para começar a amar uma linguagem de programação, você deve começar examinando profundamente e dominando seus conceitos um por um.

Aqui está uma lista de 36 conceitos de JavaScript que você precisa dominar para se tornar um especialista em JavaScript completo.

Observação: A maioria dos títulos não foram traduzidos, para o leitor se familiarizar com os termos originais.

Aqui temos um repositório do Tiago Boeing explicando 33 conceitos de JavaScript

1. Execução de Call Stack.

Todo mundo já ouviu falar do site Stack Overflow.
Mas você sabe o que significa o verdadeiro stack overflow? Stack overflow ( ou Estouro de Pilha em português literal ) é um erro associado as operações de call stack.

Entendendo a Call stack, você vai entender como uma linguaguem de alto-nivel como JavaScript é executado.

Recomendo esse artigo do MDN , para entender melhor sobre Call Stack.
Esse artigo da Thais Ribeiro é ótimo para entender o assunto

2. Tipos de dados Primitivos

const foo = "bar";
foo.length; // 3
foo === "bar"; // true

Espere!

Quando você declara o valor de bar na constante foo, ela é do tipo primitivostring. Isso está ok para todo mundo. Mas como você consegue acessar a proprieadade length de uma string primitiva?

Estranho? Não.

Essa feature se chama autoboxing. No exemplo acima, o JavaScript envolve a constante em um objeto temporário e, em seguida, acessa a propriedade length desse objeto. Depois que essa etapa for concluída, o objeto é descartado com segurança.

Tendo conhecimento profundo dos tipos de dados primitivos, você saberá como eles são armazenados na memória até o ponto de sua representação binária. Você também saberá como essas situações “estranhas” ocorrem e a razão lógica por trás delas.

Leia aqui mais sobre Tipos de Dados Primitivos no MDN ou esse ótimo artigo do Guilherme Alves

3. Tipos de Valor e Valores por Referência (Value Types e Reference Types)

Recentemente, tive alguma confusão sobre como o conceito de “passagem por referência” (pass by reference) funciona no JavaScript.
Embora eu estivesse soubesse dos conceitos de “passagem por referência” e “passagem por valor” em linguagens como C e Java, não tinha certeza de como isso funcionava no JavaScript.

Você sabia que variáveis atribuídas a valores não primitivos em JavaScript recebem uma referência a esse valor?
A referência aponta para o local da memória onde o valor está armazenado.

var arr1 = [1,2,3];
var arr2 = arr1;
arr2.push(10);

console.log(arr2);
//[1, 2, 3, 10]

console.log(arr1);
//[1, 2, 3, 10]

No exemplo acima, qualquer mudança em arr2, vai refletir em arr1também. Isso porquê ele só atribui a referência ao valor, não o valor atual.

Ao compreender este conceito de tipos de valor e tipos de referência, você terá um melhor entendimento de como as variáveis são atribuídas com valores e referências de memória.

Leia mais Aqui:
Diferença entre valor e referência em JavaScript — Brazil JS
Objetos — Referências de valores em JavaScript — Blog DA2K

4. Coerção de Tipos

Esse conceito explica principalmente a diferença entre coerção de tipo implícita e explícita. Esta é uma das poucas áreas em JavaScript em que as pessoas erram.
Isso é especialmente verdadeiro com o conceito de coerção de tipo implícita, porque ele se comporta de maneiras diferentes com tipos de dados diferentes.

Esta é uma das áreas de JavaScript mais testadas em entrevistas.

Number('789')   // explicito
+'789'          // implicito
789 != '456'    // implicito
9 > '5'         // implicito
10/null          // implicito
true | 0        // implicito

Ao compreender a coerção de tipo de forma clara, você pode ficar feliz por ter um ótimo entendimento de um dos conceitos mais complicados do JavaScript.

Leia mais Aqui:

Explicando a coerção de tipos em Javascript por Allan Ramos
Air BNB JS Style Guide — Casting e Coerção de Tipos
Coerção de tipos em Javascript — por Cristiano Gonçalves

5. Comparação de Igualdades e o operador ‘typeof’

Este conceito explica basicamente o uso de duplos iguais e triplos iguais, e quando e por que você deve usá-los. Embora pareçam iguais na superfície e forneçam os mesmos resultados na maioria das vezes, eles podem gerar bugs inesperados se você usá-los sem saber.
Você também deve ser capaz de usar o operador typeof e conhecer as possibilidades das saídas. Pode ficar confuso quando os objetos entram em jogo.

typeof 3 // "number"
typeof "abc" // "string"
typeof {} // "object"
typeof true // "boolean"
typeof undefined // "undefined"
typeof function(){} // "function"typeof [] // "object"
typeof null // "object"

6. Escopo do JavaScript

Os escopos são um dos conceitos, acredito, que deve ser aperfeiçoado no início de sua jornada JS. De acordo com Wissam, a definição simples de escopo é que é onde o compilador procura variáveis e funções quando precisa delas.

Compreender os escopos permitirá que você use o JavaScript de forma mais eficiente e eficaz.
Você deve aprender sobre o escopo global e o escopo do bloco e da função, também conhecido como escopo léxico.
O escopo JS pode parecer um tanto confuso no início, mas depois que você entender como as coisas funcionam nos bastidores, será muito emocionante trabalhar com ele.

7. Declarações e Expressões

Essas são as duas principais categorias sintáticas em JavaScript. Você deve saber a diferença entre esses dois e como as declarações são avaliadas.
Isso permitirá que você obtenha uma compreensão geral de como seu código é estruturado como expressões e instruções.
Você notará que a maior parte do seu código é composta por expressões, embora tenha um número menor de instruções, comparativamente.
Você também poderá evitar bugs resultantes do uso indevido desses dois.

8. Immediately Invoked Function Expressions e Módulos

As Expressões de Função Imediatamente Invocadas (IIFEs) são funções executadas assim que são definidas.
Eles são usados principalmente para evitar poluir o escopo global.
Mais tarde, os módulos ES6 foram introduzidos, fornecendo uma maneira padrão de evitar a poluição de escopo global — embora algumas pessoas acreditem que não seja uma substituição direta dos IIFEs.
Ao compreender os IIFEs e os módulos, você pode criar aplicativos com menos bugs devido ao manuseio incorreto do espaço global.
Com os módulos, no entanto, você pode fazer várias coisas.

9. Message Queues e Loops de Eventos

Como diz o documento MDN, o JavaScript tem um modelo de simultaneidade baseado em um loop de eventos, que é responsável por executar o código, coletar e processar eventos e executar subtarefas enfileiradas.
Este modelo é bastante diferente dos modelos em outras linguagens, como C e Java.
As messages queues são usadas no modelo de simultaneidade acima para lidar com mensagens que começam pela mais antiga.
As mensagens são adicionadas sempre que ocorre um evento e há um ouvinte de evento anexado a ele.
Ao compreender esses conceitos, você obtém um melhor entendimento de como JS funciona nos bastidores e consegue interpretar seu código.

10. Intervalos de Tempo

Para agendar uma chamada ou função em JavaScript, você usa dois métodos.

• setTimeout nos permite executar uma função uma vez após um intervalo de tempo específico.
• setIntervalnos permite executar uma função repetidamente, começando após um intervalo de tempo específico e, em seguida, repetindo continuamente nesse intervalo.

De certa forma, eles estão relacionados ao conceito anterior de filas de mensagens e manipuladores de eventos. Portanto, ao compreender os métodos de intervalo de tempo, podemos entender como eles funcionam e como usá-los com eficiência em nossos casos de uso.

11.Engines de JavaScript

Estamos nos aprofundando no JavaScript agora. Um motor JavaScript é um programa de computador ou um interpretador que executa o código JavaScript. Um mecanismo JavaScript pode ser escrito em uma ampla variedade de linguagens. Por exemplo, o mecanismo V8 que aciona o navegador Chrome foi escrito em C ++, enquanto o mecanismo SpiderMonkey que aciona o navegador Firefox foi escrito em C e C ++. É essencial que você entenda em qual mecanismo JavaScript está trabalhando para escrever um código eficiente. Os desenvolvedores móveis que usam um webview devem estar especialmente cientes disso.

12. Operações Bitwise

Essas operações tratam os valores como bits (0s e 1s), em vez de números decimais, hexadecimais ou octais.
Operadores bit a bit realizam suas operações em tais representações binárias, mas eles retornam valores numéricos JavaScript padrão.
Geralmente, você não usaria essas operações em seu código, mas elas têm alguns casos de uso.
Você pode usá-los para encontrar valores pares e ímpares, conversões de cores, extração de cores e sinalizadores de configuração.
Conhecendo essas operações bit a bit completamente, você pode trabalhar com tecnologias como WebGL muito bem, pois inclui muita manipulação de pixels.

Leia mais: Operador Bitwise XOR

13. DOM e a Árvore de Layout

A maioria de nós já ouviu falar sobre o Document Object Model (DOM), mas apenas alguns de nós o conhecem em profundidade. Você sabia que o que você vê no navegador não é o DOM?
É mais a árvore de renderização, que na verdade é uma combinação de DOM e CSSOM.
Ao entender como o DOM funciona, como é estruturado e como uma página é renderizada, somos capazes de manipular nossa página da web dinamicamente com a ajuda de JavaScript.
Isso é especialmente necessário para garantir que o desempenho de nosso aplicativo seja de alto padrão.

14. Classes e Factories

JavaScript não é uma linguagem orientada a objetos.
No entanto, a fim de imitar as propriedades OOP, funções construtoras foram usadas.
De acordo com Tania, “Classes em JavaScript não oferecem realmente funcionalidade adicional e são frequentemente descritas como fornecendo açúcar sintático sobre protótipos e herança, pois oferecem uma sintaxe mais limpa e elegante. Como outras linguagens de programação usam classes, a sintaxe de classe em JavaScript torna mais fácil para os desenvolvedores se moverem entre os idiomas.
“ Uma factory function é uma função que não é uma classe ou um construtor que retorna um objeto. ”
De acordo com o guru do JS Eric Elliot,
“Em JavaScript, qualquer função pode retornar um novo objeto. Quando não é uma função construtora ou classe, é chamada de factory function.”

Você deve ter um bom entendimento desses dois conceitos, especialmente quando começar a desenvolver aplicativos que são maiores em tamanho e escala.

15. ’this’ e os métodos ‘apply’, ‘call’, e ‘bind’.

Pessoalmente, acho que é crucial para um desenvolvedor JS entender a palavra-chave ‘this’. Se você não entender corretamente, encontrará vários problemas com seu aplicativo mais tarde.

Se você tiver um bom conhecimento da palavra-chave this, poderá se compreender os métodos apply , call, ebind .

Esses métodos são necessários para invocar funções com o contexto apropriado. Você precisará especialmente do método bind ao passar um retorno de chamada que usa this.

16. Funções Construtoras e o operador ‘instanceOf’

As funções construtoras são como funções comuns.
Mas elas têm algumas diferenças.
Por convenção, o nome da função começa com uma letra maiúscula e só deve ser executada com o operador new.
A palavra-chave new será familiar para programadores com experiência em OOP.
Para identificar corretamente o tipo de um objeto, usamos o operador instanceof.
Em termos simples, ele verifica se um objeto é uma instância de outro. Isso ajudará você a entender como os objetos são herdados uns dos outros.
A herança é obtida por prototypes.

MDN: Construtores e instâncias de objeto

17. Prototypes

Este é um dos conceitos mais confusos em JavaScript, mesmo para alguém com dez anos de experiência.

Prototypes em JavaScript são o mecanismo para compartilhar funcionalidades comuns entre objetos. Quase todos os objetos em JavaScript são instâncias de Object. Um objeto típico herda todas as propriedades e métodos de Object.prototype. Em termos simples, um prototype é um objeto do qual os objetos JavaScript herdam métodos e propriedades. Ao compreender melhor os prototypes, você pode construir aplicativos que sejam eficientes e rápidos.

Dominando o uso de protype com Javascript

18. Criando objetos com ‘new’, ‘Object.create’, e ‘Object.assign’

Existem muitas maneiras de criar um objeto em JavaScript. Mas há um motivo pelo qual alguém escolheria o método Object.create em vez da palavra-chave new. Ao usar o método Object.create, você pode usar um objeto existente como protótipo do objeto recém-criado. Isso permitirá que você reutilize propriedades e funções de um objeto existente, de forma semelhante ao conceito de herança em OOP.

Ao usar o método Object.assign, você pode copiar propriedades próprias enumeráveis de um ou mais objetos de origem para um objeto de destino. Nessa situação, o protótipo do objeto de destino não contém as propriedades do objeto de origem. Essa é a principal diferença entre esses dois métodos.
Ao compreender essas três formas de criação de objeto, você pode usá-las apropriadamente em seus aplicativos, de acordo com seus casos de uso, para criar programas com uso eficiente de memória.

19. Os métodos ‘map’, ‘filter’, ‘forEach, e ‘reduce’

Esses quatro métodos são muito úteis quando se trata de manipulação de array. Eles são encontrados no protótipo do Array.

Se você precisa alterar os valores de cada elemento de um Array, sem gerar um novo array, apenas alterando o array original, utilize o método forEach.

Se você tem um array e quer fazer algo para / com cada elemento e retornar um novo array, então você deve usar o método map.

O métodoreduce executa uma função redutora em todos os elementos de uma array e, finalmente, retorna um valor no final. Um exemplo perfeito seria encontrar a soma de todos os elementos em um array.

Se você tiver uma array e quiser executar uma condição em cada elemento e obter os valores que passam na condição, você deve usar o métodofilter.

Observe que os três métodos acima não modificam / alteram os valores da Array original.

Leia mais: JavaScript: Entendendo a diferença entre map x forEach — por Thiago S.Adriano

Array — MDN

20. Funções Puras, Side Effects, e State Mutations

Esses três conceitos são muito importantes para um desenvolvedor JavaScript.
A mutação de estado é especialmente importante para desenvolvedores que trabalham com React.

Uma função pura é uma função que sempre retorna um valor consistente com a entrada fornecida, sem acessar / alterar nenhuma variável fora de seu escopo. Esse tipo de função é mais fácil de ler, depurar e testar.

Os Side Effects são um trecho de código por meio do qual uma variável é criada e disponibilizada em todo o escopo quando não é necessário. Se sua função estiver acessando uma variável que está fora do escopo, há um side effect.

A mutação de estado é onde você altera o valor de uma variável. Se você alterar uma variável, existe a possibilidade de que ela afete outras funções, dependendo do valor anterior à mutação. Em um ambiente React, é recomendável não alterar seu estado.

Leia mais: Porque Imutabilidade é tão importante?

21. Closures

As Closures são difíceis de entender. Mas, uma vez compreendido, você começará a ver a beleza do JavaScript.

Uma closure forneceria acesso ao escopo de uma função externa dentro do escopo interno. Closures JavaScript são criados sempre que uma função é criada, no momento da criação da função.

Descubra por que você deve usar closures para obter uma compreensão mais profunda deles.

Mais afinal o que são closures? por Stephano Wallace

22. Higher-Order Functions

Higher-Order Functions são funções que recebem outras funções como argumentos ou retornam funções como resultado.

Você pode criar funções menores que cuidam de apenas uma tarefa e, em seguida, construir funções complexas com a ajuda dessas funções menores. Isso também resultará em um aumento na capacidade de reutilização do código.

Isso também reduz bugs e torna nosso código mais fácil de ler e entender.

const double = n => n * 2

[1, 2, 3, 4].map(double) // [ 2, 4, 6, 8 ]

Exemplo: A função map do Array é uma High Order Function.

23. Recursão

Recursão, é um conceito comum em todas as linguagens de programação. Em termos simples, recursão é o conceito de dividir um problema maior em partes menores e depois resolver os problemas menores.

Colocado em prática, isso geralmente significa escrever uma função que chama a si mesma. Embora a recursão possa ser um conceito confuso para entender, você pode entendê-lo melhor com muita prática, começando com pequenos problemas.

Mas cuidado, você pode encontrar um erro de (Estouro de pilha) stack overflow se não for cuidadoso com sua recursão. Como exercício, faça pesquisas sobre esse erro.
Você precisará revisar seu conhecimento sobre o primeiro tópico, Callback stack, para compreender totalmente o contexto desse erro.

24. Collections e Generators

Collections e generators foram introduzidos recentemente no ES6. As collections recém-introduzidas foram Map, Set, WeakSet, eWeakMap.. Essas collectionsfornecem alguns casos de uso realmente bons para você trabalhar. É essencial que você os conheça, especialmente com o JavaScript moderno.

Generators, por outro lado, às vezes são um pouco difíceis de entender, especialmente para iniciantes.
Os generators permitem que você escreva funções de código que fornecem a capacidade de pausar e reiniciar uma função sem bloquear a execução de outro código, o que é algo incomum em JavaScript.

25. Promises

Jecelyn explica Promises da seguinte forma: “Imagine que você é uma criança. Sua mãe promete que ela vai lhe dar um novo telefone na próxima semana.”
Você não saberá se receberá esse telefone até a próxima semana. Sua mãe realmente compra um telefone novo para você — ou ela não compra porque ela não está feliz.

Isso é uma promise. Uma promise tem três estados. Eles são:
Pending: você não sabe se vai conseguir esse telefone.
Fulffiled: mamãe está feliz e ela compra um telefone novo para você.
Rejected: mamãe está infeliz e não compra um telefone para você.

Esta é de longe a explicação mais simples e clara que encontrei para Promises.

26. Programação Assíncrona

Para entender o que é programação assíncrona, devemos primeiro atualizar nosso conhecimento de programação síncrona. A programação síncrona bloqueia threads e, como o JavaScript é de thread único, seu código será executado linha por linha.

Mas, com o código assíncrono, você pode realizar longas solicitações de rede sem bloquear o thread principal. Isso é especialmente útil quando você precisa realizar várias tarefas que demoram muito para serem concluídas. Mas pode haver casos em que você precise bloquear o thread, mesmo para uma tarefa longa.

Você usaria o conceito de async/awaitnaquele momento.
Aprender bem esses conceitos permitirá que você escreva programas com desempenho eficiente, mesmo com muitas tarefas em execução.

27. Arrow Functions

As arrow functions foram adicionadas ao ES6 e são uma substituição sintática das funções regulares. A diferença é que as arrow functions não se vinculam às palavras-chave this, arguments, super, ou new.target. Isso torna as arrow functions uma ótima escolha em alguns cenários, mas muito ruim em outros.
Portanto, você nunca deve criar o hábito de usar as arrow functions o tempo todo. Implemente-os de acordo com seu caso de uso.

Vale a leitura: Quando não usar Arrow Functions

28. Estrutura de Dados

As estruturas de dados são uma das peças essenciais do conhecimento que um desenvolvedor deve ter, independentemente da linguagem de programação.
“Os programadores ruins se preocupam com o código. Os bons programadores se preocupam com as estruturas de dados e seus relacionamentos.”
-Linus Torvalds, criador do Linux e Git

Por ter um conhecimento profundo de diferentes estruturas de dados, você pode criar programas eficientes que funcionam bem em diferentes circunstâncias. Você deve saber sobre linked lists, queues, stacks, árvores, grafos e hash tables.

29. Complexidade de Tempo

A análise da complexidade do tempo também é outro fundamento da programação de computadores, independentemente da linguagem de programação. Para construir melhores aplicativos, você deve escrever melhores soluções. Para fazer isso, você deve entender o conceito de complexidade do tempo. Às vezes é chamado de Big O.
A notação Big O descreve o tempo de execução necessário ou o espaço usado por um algoritmo.
A notação Big O descreve especificamente o pior cenário.
Isso permitirá que você selecione e implemente o algoritmo que terá o melhor desempenho, mesmo no pior cenário.

30. Algoritmos

Esta é uma das primeiras coisas que você aprenderá em um curso de ciência da computação. Em palavras simples, um algoritmo é um processo passo a passo de como você consegue algo.
Um programador deve ser capaz de olhar para qualquer problema de uma perspectiva algorítmica. Eles devem ser capazes de estruturar o problema e sua solução em um processo passo a passo. Este algoritmo é o que você escreverá como um programa mais tarde.
Embora existam vários algoritmos por aí para milhares de casos de uso, dois dos casos de uso são bastante comuns:

• Search
• Sort

Esses dois casos de uso são muito comuns aos programadores e você deve ter pelo menos um conhecimento completo dos algoritmos conhecidos disponíveis para eles. Não existe uma regra fixa afirmando que você deve usar um desses algoritmos, mas esses algoritmos são bem conhecidos e bem documentados em termos de desempenho.

Você pode até criar seu próprio algoritmo e apresentá-lo ao mundo.
Se for melhor do que os algoritmos atualmente conhecidos, você pode se tornar a próxima estrela da programação!

31. Herança, Polimorfismo e Re-uso de código

A herança em JavaScript funciona com protótipos. Isso ocorre porque o JavaScript é uma linguagem não OOP.
Ainda assim, o JavaScript fornece alguns recursos de OOP ao fornecer herança prototípica.
O polimorfismo, por outro lado, é um conceito em que um objeto, variável ou função pode assumir várias formas.
Em JavaScript, é um pouco mais difícil ver os efeitos do polimorfismo porque os tipos mais clássicos de polimorfismo são mais evidentes em sistemas estaticamente tipados.
Os dois conceitos acima nos ajudam com a reutilização de código em JavaScript. Ter um entendimento sólido dos dois conceitos acima, especialmente com JavaScript, permitirá que você escreva um código de alta qualidade e praticidade.

32. Design Patterns

Na engenharia de software, um padrão de projeto é uma solução bem conhecida e replicavel para um problema comum.
Existem vários padrões de design por aí, cada um com seu próprio caso de uso.
Os 23 padrões da Gang of Four (GoF) são geralmente considerados a base para todos os outros padrões. É muito difícil conhecê-los todos, mas você pode pelo menos tentar entender seus casos de uso.

Aqui está um ótimo repositório de Felipe que tem implementações dos 23 padrões GoF em JavaScript. Percorra os recursos mencionados no final deste artigo para se familiarizar com alguns recursos fantásticos de Leonardo, uma inspiração para este artigo.

33. Programação Funcional

De acordo com o Wiki, “a programação funcional é um paradigma de programação — um estilo de construção da estrutura e elementos de programas de computador — que trata a computação como a avaliação de funções matemáticas e evita a mudança de estado e dados mutáveis.”
Existem vários conceitos de programação funcional que você precisará dominar:

• Funções puras
• Imutabilidade
• Transparência referencial
• Higher-order functions

Compreender esses conceitos de programação funcional certamente dará a você uma vantagem.

Leia Mais: Entendendo Programação Funcional em JavaScript de uma vez

34. Clean Code

Esta é uma habilidade essencial que todo desenvolvedor deve dominar, independentemente da linguagem de programação.
Cada linguagem de programação possui um conjunto separado de boas práticas.
Embora essas “boas” práticas sejam subjetivas e difiram de local de trabalho para local de trabalho, há algumas práticas consideradas “boas”.

Seguindo esses princípios de código, você pode garantir que seu código possa ser lido e mantido por todos.
Isso ajudará você e sua equipe a trabalhar juntos sem problemas durante o desenvolvimento do aplicativo.

Leia Mais: Clean Code JavaScript em Português

35. Spread Operator

O operador de atribuição de desestruturação foi introduzido no ES6.
Ele tem vários casos de uso com os quais você definitivamente deve estar familiarizado.
Eles são mais fáceis e eficientes do que as implementações anteriores para os mesmos casos de uso.
Isso também é conhecido como o operador de propagação.

Leia Mais: MDN: Atribuição via desestruturação

36. Novas features do ES2020 e ES2021

A beleza da programação é que você nunca pode ser um especialista em uma linguagem de programação sem aprendizado contínuo. As linguagens de programação evoluem continuamente com o tempo, à medida que recursos adicionais são introduzidos em cada versão principal.

Isso significa que seu conhecimento especializado de um conceito ficará desatualizado ou obsoleto em outros dez anos, pois haveria uma alternativa melhor lançada com uma atualização de versão. Este é um cenário muito comum com qualquer linguagem de programação.

Dominar um idioma exigirá anos de experiência e tempo, mas saber o que dominar tornará as coisas mais fáceis para você.

Este repositório Github é um bom lugar para começar.

Obrigado por ler e ótima programação

Créditos

36 Concepts to become an JavaScript Expert por Mahdi Rezvi

O que é React Server Components?

React Server Components é uma feature experimental do React, anunciada no blog do React.js em 21 de Dezembro de 2020.
No momento (25/02/2021) ainda não está pronto para produção.

O maior apelo do React Server Components, é mover componentes que não tem interação com o usuário do client para o server.

Outro problema encontrado é o número alto de requests feitos, enquanto os usuários esperam para a página ou os dados, estarem prontos, quando eles abrem a página.

Por exemplo uma forma de fazer fetch de dados hoje, é chamar uma API usando o hook useEffect :

useEffect(() => {
  axios.get("ENDEREÇO AQUI")
  .then((response) => {
    // set data into state    
setData(response.data);
  })
  .catch((error) => {
    console.log(error);
  });
}, []);

Apesar de não ter nada de errado com isso, essa forma de pegar os dados sempre vai ter um custo de tempo para renderizar algo útil para o usuário.

O outro problema claro é sempre o tamanho do bundle. Minificação, code splitting, eliminação de código morto, são algumas técnicas utilizadas para reduzir o tamanho do bundle de uma aplicação React. Porque? Porque impacta diretamente na experiência do usuário, com carregamentos lentos.

Como funciona?

Como essa feature do React ainda está em fase de experimentação, recomendo assistir a live explicando o conceito do React Server Components, pois a implementação pode mudar com o tempo.

Pode também clonar o repositório demo para entender como funciona a feature

A primeira coisa que notamos são vários packages com versão experimental no arquivo package.json :

"react": "0.0.0-experimental-3310209d0",
"react-dom": "0.0.0-experimental-3310209d0",
"react-fetch": "0.0.0-experimental-3310209d0",
"react-fs": "0.0.0-experimental-3310209d0",
"react-pg": "0.0.0-experimental-3310209d0",
"react-server-dom-webpack": "0.0.0-experimental-3310209d0",

Os pacotes react , react-dom e, react-server-dom-webpack estão usando uma versão experimental que funcionam com o React Server Component, enquanto oreact-fetch , react-fs e react-pg é um grupo de packages usado pela interação com o sistema de input/output ( chamado de libs do React IO)

Outro ponto importante é que o demo funciona em cima do Express.js, o que faz sentido, porque você precisa de um servidor para renderizar os componentes.Mas isso levanta a questão, Server Components apenas em ambientes Java Script? Nada de Go, Java, C# .NET, PHP?

Dentro da pasta src/ você tem três tipos de extensões nos arquivos:

• .server.js indica um Server Components
• .client.js indica um React Client Components
• O habitual .js , pode ser rodado no client ou no server. Dependendo de quem o importa. Também serve para Shared Components. Por exemplo se você importa um Shared Component no server, ele atuará como Server Component, se você importa ele no Client, Será um Client Component.

Quando você inicia sua aplicação com o comando npm start, duas tarefas vão ser executadas simultaneamente:

• O servidor Node, rodando o scriptserver/api.server.js
• O build do Webpack rodando o bundle client-side do React, usando o script scripts/build.js

Olhando o script do server podemos ver que o app.server.js está sendo importado para o arquivo:

const ReactApp = require('../src/App.server').default;

e depois é processado com um Node Writable stream:

const {pipeToNodeWritable} = 
require('react-server-dom-webpack/writer');

async function renderReactTree(res, props) {
  await waitForWebpack();
  const manifest = readFileSync(
    path.resolve(__dirname, '../build/react-client-manifest.json'),
    'utf8'
  );

  const moduleMap = JSON.parse(manifest);
  pipeToNodeWritable(React.createElement(ReactApp, props), res, moduleMap);
}

Bundle de tamanho Zero

O código dentro da extensão .server.js incluindo suas dependências , não é incluindo no bundle do client. Isso significa que tem zero efeito no tamanho do bundle.

As bibliotecas que importamos no código atualmente, serão lidas do lado do servidor, economizando no tamanho do bundle do client.

Client Component:

//markdown.js

import marked from 'marked'; // 37.38KB

import sanitizeHtml from 'sanitize-html'; // 208 KB

export default function TextwithMarkdown({Text}) {
 return(
 <div className="text-markdown"
      dangerousSetInnerHTML={{
      __html: sanitizeHtml(marked(text)),
      }}
         />
 );
}

Server Component:

// markdown.server.js

import marked from 'marked'; // 0KB

import sanitizeHtml from 'sanitize-html'; // 0KB

export default function TextwithMarkdown({Text}) {
 return(
 <div className="text-markdown"
      dangerousSetInnerHTML={{
      __html: sanitizeHtml(marked(text)),
      }}
         />
 );
}

Acesso do backend ao banco de dados:

Server Components tem acesso direto ao banco de dados ou ao filesystem no servidor. Você pode pegar qualquer dado que você quiser e mandar para o client, no primeiro render:

como você pode ver no exemplo do arquivo NoteList.server.js :

export default function NoteList({searchText}) {
const notes = db.query(
    `select * from notes where title ilike $1 order by id desc`,
    ['%' + searchText + '%']
  ).rows;
  
  return notes.length > 0 ? (
    <ul className="notes-list">
      {notes.map((note) => (
        <li key={note.id}>
          <SidebarNote note={note} />
        </li>
      ))}
    </ul>
  ) : (
    <div className="notes-empty">
      {searchText
        ? `Couldn't find any notes titled "${searchText}".`
        : 'No notes created yet!'}{' '}
    </div>
  );
}

Restrições

Assim como os Server Components são estáticos e renderizados no backend, eles tem algumas restrições de como podem ser usados.

• Primeiro, um Server Component não tem nenhuma interatividade (sem useState(),nem useEffect()).
  Uma resolução para esse problema, seria importar Client Components, ( que podem ser interativos) , dentro de um Server Component, por exemplo você pode ter o melhor dos dois mundos:

//Page.server.js

// import de componente interativo do client
import Button from '.Button.client.js';

export default Page() {
 // data fetch, processamento, outras coisas..

return(
  // use o <Button /> e outros componentes interativos aqui
  );

}

• Segundo,props de um Server Component para um Client Component tem que ser serializada na rede ( ex: passar dados como strings, JSON e JSX mas não podem passar em funções JavaScript) . Isso é porque os Server Components renderizados tem que ser enviados pela rede.

Rotas

Analizando o projeto no demo no github, as rotas são setadas direto no arquivo api.server.js, onde literalmente, você constroi uma api como quiser, algo que o Next.js também tem como feature, seja fazendo sua própria Api server-side, ou refletindo na pasta /api

Quais as vantagens?

No começo parece muito com Server-Side Rendering (SSR). Na verdade oferece vantagens muito similares:

• Desenvolvimento mais fácil, por ter acesso a recursos de servidor como : banco de dados,filesystem, micro serviços, etc.).
• Melhor performance, pois evitamos a latência de rede entre servidor e cliente.
• Menor tamanho do bundle. Libs que forem usados só no servidor não precisam ser usados no client : (como loadash, rambda, moment,e etc.), além dos Server Components nunca serem incluidos no bundle, e lidos pelo client.
• Segurança: Fazer queries no lado do servidor sempre é mais seguro que no client. Além de não expor as requisições
• Pode fazer queries GraphQL
• Pode acessar diretamente bancos de dados PostgreSQL com o package react-pg

Também oferece algumas vantagens para desenvolvedores React:

• Code splitting automático. (A técnica de dividir o código em bundles menores, para o cliente ler apenas o que é necessário) Atualmente, Desenvolvedores React tem que fazer um esforço para poder implementar o code splitting algo como:

const MyComponent = React.lazy(() => import('./MyComponent.js'));

no futuro os Server Components vai lidar com isso automaticamente. Isso significa que poderemos importar diretamente como já fazemos:

import MyComponent from './MyComponent.client.js';

Como os Server Components são diferentes de SSR (ex: Next.js)?

Utilizamos SSR hoje no React, apenas para que os componentes sejam renderizados como HTML no client, para que sua aplicação pareça ter uma resposta muito rápida. Seu usuário não consegue fazer nada na sua aplicação até que o JavaScript seja baixado.

React Server Components é diferente.Como mostrado no demo, Server Components não é renderizado como HTML mas como um stream de formato especial enviado ao client. O stream não tem um padrão de protocolo, mas se parece muito com json. Aqui um exemplo:

M1:{"id":"./src/SearchField.client.js","chunks":["client5"],"name":""}

No SSR , usamos apenas para o render inicial, Server Components podem puxar os dados multiplas vezes para fazer re-render ( no exemplo do demo, os posts de markdown)

Server Component x Client Components

Vamos considerar o exemplo de uma aplicação que tem uma barra de busca para filmes, linkada a um banco de dados do seu backend. Vamos considerar que os resultados são um React Server Component, não um component comum (client), no caso do client component isso iria ocorrer:

1. Assim que você ,uma requisição fetch é feita para uma API para um payload JSON.
2. Assim que você recebe a resposta, você parseia o JSON, e manda pro React.
3. O React renderiza os dados, e mostra as informações do filme na tela.

Simples , não? Com React Server Components acontece o seguinte:

1. Uma requisição é feita para um backend que você é dono e é capaz de fazer um render RSC ( React Server Component)
2. O componente é renderizado no próprio servidor, e você recebe um build do markup estático, sem ser JSON ou HTML , como abaixo: M1:{“id”:”./src/SearchField.client.js”,”chunks”:[“client5”],”name”:””}
3. O frontend (client), renderiza esse markup, como um UI estático ( importante: não um componente React), isso salva processamento adicional do componente no front-end.

Conclusão

React Server Components é uma nova abordagem de como construímos nossas aplicações React.
Pode mudar toda forma como o mercado utiliza o framework, e abre um leque de possibilidades em questão de performance, segurança e organização de código.
Por enquanto, podemos apenas brincar e testar, não sendo recomendado usar em produção.
A thread oficial no github tem a discussão da feature e do conceito, e muitas pessoas estão participando dando sugestões, críticas e idéias, e você também pode participar. Sugiro caso conheça inglês também ler os artigos linkados abaixo.

Com conteúdo traduzido de:

Bits and Pieces — React Server Components por Nathan Sebhastian
An Introduction to React Server Components por Nilanth
React Server Components Explained por Mehul Mohan

Links Úteis:

React Server Components — Addy Osmani
React Server Components Github Demo
React Server Components Video Explicação
Post no Blog do React sobre React Server Components

bind() e Funções em Componentes

Quando chamamos bind nos componentes de classe React, não devemos chamá-los repetidamente em nossos adereços.

Em vez disso, devemos chamar bind no construtor para que não tenhamos que chamar bind imediatamente quando passarmos em nossos métodos de componente de classe como adereços.

Por exemplo, podemos escrever o seguinte código para fazer isso:

import React from "react";

export default class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      name: ""
    };
    this.updateValue = this.updateValue.bind(this);
  }
  updateValue(e) {
    this.setState({
      name: e.target.value
    });
  }
  render() {
    return (
      <>
        <form>
          <input onChange={this.updateValue} value={this.state.name} />
        </form>
        <p>{this.state.name}</p>
      </>
    );
  }
}

No código abaixo, temos um input que chama o método updateValue , quando o valor do input muda.

Temos:

this.updateValue = this.updateValue.bind(this);

com o construtor, pois então sempre vai dar bind no componente com o valor de this

Agora não precisamos criar repetidamente em todos os lugares. Também não precisaremos criar uma nova função todas as vezes que o evento onChange for emitido porque não chamamos o bind, que retorna uma nova função.

O impacto no desempenho da criação de métodos em tempo real quando nosso aplicativo ficar grande será perceptível em algumas situações.

Ao invés de escrever:

<input onChange={this.updateValue.bind(this)} value={this.state.name} />

nós escrevemos como está acima, no primeiro exemplo.

Extra: bind em Arrow Functions x bind no construtor

Um colega de trabalho, Rodrigo Mello, Tech Lead da Zup, levantou uma questão importante, qual a melhor forma de darmos bind, via arrow function dentro da classe, ou dar bind dentro do construtor, qual seria a forma mais correta ?

Segundo uma discussão no repositório oficial do React, fazer o bind dentro do construtor é a forma como o time do Facebook, por razões de performance e porque em um exemplo com Arrow Functions, recriamos a função a cada renderização , e via construtor vinculamos ela apenas uma vez.

Exemplo Construtor:

Class Click extends react.Component {
  constructor(props) {
   super(props)
   this.clickEvent = this.clickEvent.bind(this);
  }

  render = () => (
    <button onClick={this.clickEvent}>Click Me</button>
  )

  clickEvent() {console.log(this)} // 'this' refers to the class
}

Exemplo Arrow Function:

import React from 'react';
class MyComponent extends React.Component {
  constructor(props) {
    super(props)
  }

  clickHandler = () => {
    console.log( this )
  }

  render() {
    return <button onClick={this.clickHandler}>Click Me</button>
  }
}

Tem também o problema dos testes unitários, com o construtor, conseguimos chamar nosso bind, através do prototype da classe, o que não ocorre com a Arrow Function:

const spy = jest.spyOn(MyComponent.prototype, 'clickHandler');
// ...
expect(spy).toHaveBeenCalled();

Esquecendo a prop key ou usando indexes na prop key

A propkey é importante quando renderizamos listas, mesmo que às pareça que não tem nenhuma função.

O valor único da prop key permite que o React identifique os itens da lista corretamente.

os valores da prop key são usados para combinar os filhos na árvore original com os filhos na árvore subsequente

Portanto, usar o index do array também é ruim porque pode levar o React a renderizar os dados errados.

É melhor usar IDs exclusivos como o valor da prop key. Podemos criar um array com IDs exclusivos que podemos usar como keys da seguinte maneira:

import React from "react";
import { v4 as uuidv4 } from "uuid";

const arr = [
  {
    fruit: "apple",
    id: uuidv4()
  },
  {
    fruit: "orange",
    id: uuidv4()
  },
  {
    fruit: "grape",
    id: uuidv4()
  }
];

export default function App() {
  return (
    <div className="App">
      {arr.map(a => (
        <p key={arr.id}>{a.fruit}</p>
      ))}
    </div>
  );
}

No código acima usamos o pacote uuid para criar um valor UUID único para a prop key . Assim não existe chance de colisão entre IDS.

Dessa forma, os IDs são únicos e previsíveis, e não precisamos pensar em uma maneira de gerar o ID exclusivo para cada item.

Nomes de Componentes

Os nomes dos componentes devem começar com letra maiúscula. Por exemplo, se escrevermos o código a seguir, obteremos um erro do React:

import React from "react";

const foo = () => <p>foo</p>;

export default function App() {
  return (
    <div className="App">
      <foo />
    </div>
  );
}

Se rodarmos o código acima, o React vai mostrar erro para ‘<foo> não é reconhecido pelo browser. Se você quer renderizar um componente React, comece seu nome com uma letra maiúscula .

Sempre precisamos começar nosso componente com uma letra maiúscula:

import React from "react";

const Foo = () => <p>foo</p>;

export default function App() {
  return (
    <div className="App">
      <Foo />
    </div>
  );
}

Então veremos o ‘foo’ renderizado na tela como esperamos.

Fechar cada elemento

Todas as tags de componentes devem ter uma tag de fechamento ou uma barra no final para componentes de fechamento automático. Por exemplo, se tivermos:

import React from "react";const Foo = () => <p>foo</p>

export default function App() {
  return (
    <div className="App">
      <Foo>
    </div>
  );
}

Obteremos um erro de sintaxe porque falta uma barra ou tag de fechamento em:

<Foo>

Para fazermos nosso App rodar escrevemos:

import React from "react";const Foo = () => <p>foo</p>;

export default function App() {
  return (
    <div className="App">
      <Foo />
    </div>
  );
}

<Foo></Foo> também funciona.

Conclusão

É fácil cometer erros ao escrever componentes React. Temos que lembrar de começar nossos componentes sempre com letra maiúscula.

Além disso, temos que fechar as tags do nosso componente, ou usar uma barra para fecha-los.

Também devemos chamar bind primeiro para que não tenhamos que chamá-lo repetidamente para vincular ao valor correto disso em componentes
baseados em classe.

Referências

Use arrow functions or bind manually in es6 classes? Any performance difference? @ React GitHub
Binding vs arrow-function (for react onClick event) @ StackOverflow

Créditos

React Antipatterns to Avoid escrito por John Au-Yeung

PNL, abreviação de Processamento de Linguagem Natural, é um campo da Inteligência Artificial amplamente usado para interpretar, compreender e processar a linguagem humana / natural. É comumente usado para reconhecimento de fala e NLG (Natural Language Generation).

Os recursos mais comuns da PNL são os seguintes:
1. Categorização de conteúdo
2. Extração contextual
3. Análise sentimental
4. Speech-to-text e text-to-speech
5. Sumarização de documentos

Hoje, nesse post, estou explorando a PNL usando Javascript.
Temos muitas libs de PNL disponíveis em JS, onde temos a maioria dos recursos / tarefas de PNL.
Neste post, estaremos mais concentrados na lib natural, mas você pode verificar com outra biblioteca como compromise, node-npl.

Aqui, veremos algumas de suas principais funcionalidades, como tokenização, operações de string e classificador.

Primeiro, temos que instalar a lib do natural:

npm install natural

e depois importa-la:

const natural = require('natural')

1. O termo Tokenização significa quebrar um string em um array como:

tokenizer.tokenize("Isso é um exemplo de tokenização")

["Isso", "é", "um", "exemplo", "de", "tokenização"]

Podemos conseguir isso usando o método String do JS, mas a diferença está além dessa simples tokenização, ela também nos dá a tokenização baseada em maiúsculas e minúsculas, regex, frase e pontuação para qualquer idioma.

2. Uma distância de string conta o número de caracteres diferentes.

console.log('Diferença de String entre Amol e Amol: ', natural.HammingDistance("Amol","Amol" , false));

console.log('Diferença de String entre Amol e Anmol: ', natural.HammingDistance("Amol","Anmol" , false));

console.log('Diferença de String entre Amol e ABCD: ', natural.HammingDistance("Amol","ABCD" , false));

No exemplo acima, ele simplesmente retorna o número de caracteres não correspondentes.

Ele está ignorando o case, pois definimos o sinalizador como falso, também retornamos -1 se o comprimento da string não for o mesmo.

Ele também oferece suporte para correspondência de String.

3. Um Infletor, para forma de palavra singularizada ou pluralizada,

var nounInflector = new.natural.NounInflector();
console.log('Pluralize: ', nounInflector.pluralize('Programmer'));
console.log('Singular:' , nounInflector.singularize('Developers'));

4. Agora, veremos a parte mais fascinante, Classificadores, treinaremos o classificador com os dados de amostra e obteremos o resultado deles. (Aqui, estamos apenas demonstrando como o classificador funciona em nosso caso, em vez de sua implementação.)

const natural = require('natural');

var classifier = new natural.BayesClassifier();

// Dados de exemplo
classifier.addDocument('buy stock', 'buy');
classifier.addDocument('buy more', 'buy');
classifier.addDocument('short sell', 'sell');
classifier.addDocument('sell stock', 'sell');

// Dados para Treino

classifier.train();

// Testando com novos dados
console.log('Result for `Today, I buy my first stock`: ', classifier.classify('Today, I buy my first stock'));
console.log('Result for `Yesterday, I brought my first stock`: ', classifier.classify('Today, I brought my first stock'));
console.log('Result for `Tomorrow, I will sell all my stocks`: ', classifier.classify('Tomorrow, I will sell all my stocks'));

E o output:

No exemplo 1, em palavras simples, treinamos o classificador com dados de amostra, fornecemos entrada e saída, portanto, no futuro, se o classificador obtiver um contexto semelhante, ele retornará a saída desejada.

No exemplo acima, definimos a compra / venda de saída em alguns dados de amostra de entrada para que, após o treinamento, quando verificamos com dados diferentes, ela produza compra / venda de acordo com os dados do treino.

A lib natural nos dá mais muita facilidade para trabalhar com PNL.
Da mesma forma, a compromise também é boa, com facilidade quase semelhante, você pode executar o a compromise no NodeJS ou no próprio navegador.

Créditos

Exploring NLP in JavaScript escrito por Amol Kedari

Olá pessoal. Resolvi escrever esse artigo, para contar um pouco da minha visão sobre minha experiência com entrevistas e vagas em TI.
Sou Software Engineer com especialidade em desenvolvimento front-end, e já trabalhei em mais de 53 projetos em 8 anos de carreira.
Nesses 8 anos, passei por inúmeros processos seletivos, dos mais variados níveis, desde empresas no exterior, até startups unicórnios, o objetivo desse artigo é servir como ferramenta para recrutadores conseguirem ter uma melhor experiência com os candidatos que procuram, e os candidatos conseguirem a tão sonhada vaga, mas tenha a consideração que esse artigo foi construído em cima de relatos e experiências pessoais, que nem sempre podem refletir a sua idéia de processos seletivos de mercado, mas que serve como base para reflexões e aprendizados, vamos direto aos pontos:

1.Leia o perfil do candidato

Sabemos que existem diversos perfis de empresas e vagas no mercado. Existem as empresas em que tecnologia não é só o core da empresa, como é uma questão de sobrevivência e produto. Essas empresas, geralmente são muito difíceis de um candidato entrar.
Analisar a empresa que o candidato está trabalhando é o primeiro ponto.
Analisar mesmo, olhar em ferramentas como Glassdoor, ReclameAqui etc.
Analisar quanto tempo o candidato está na empresa. Se está a pouco tempo porque iria sair da empresa tão cedo?
Se está a muito tempo, não estará trilhando uma carreira dentro da empresa?
Quais tecnologias e metodologias o candidato domina, e demonstra isso no seu perfil?
Qual a disponibilidade do candidato, ele se mostra disponível, ou coloca que não está interessado em vagas?
As atividades do candidato, e opiniões tem fit com a cultura da empresa?
O candidato é bom tecnicamente, mas péssimo em trabalhar em equipe?
Ter um perfil extenso e explicativo, ou um perfil em que omite informações, demostra o que no candidato?
O fato de o candidato ter citado um dos requisitos da vaga em 1 experiência profissional, ou em várias faz alguma diferença? Ele ser referenciado nisso também faz?
Como medir a capacidade de aprendizagem e crescimento do candidato: ser ativo na comunidade, participar de eventos, projetos e prêmios publicados, referencias?

Uma das minhas maiores frustrações depois que me tornei pleno, era receber vagas que eu via na hora que o recrutador não tinha se perguntado pelo menos uma ou duas dessas questões antes de me enviar a vaga.
Não vejo problema em receber vagas de posições que não são fit pra mim, em questão técnica ou até cultural, mas a atitude de mandar vagas em formato SPAM, ou como se o candidato estivesse desesperado por um novo emprego, quando muitas vezes a chance de um desenvolvedor pleno, sênior, especialista estar bem no emprego são GRANDES, irrita muitos desenvolvedores.

2.Tenha empatia

Quantos candidatos deixam de ganhar a oportunidade que tem capacidade para enfrentar e trabalhar, por processos mal feitos? Por julgamentos errados?
Quantos candidatos, muitas vezes não tiveram acesso a informação precocemente (Eu sou um privilegiado, meu pai é programador desde o começo da década de 90, e eu tenho contato com Informatica e TI desde meus 6 anos de idade) , muitos mal tinham celular, ou um computador a poucos anos atrás, mas apresentam resultados e um esforço descomunal, diferente de muitas pessoas que tem certificados e até faculdade, que desdenham da oportunidade.

Assim como você espera que os candidatos não trate você como um número, e que tudo ocorra bem durante o processo, seja para o SIM ou para o NÃO, nenhuma das partes quer ter uma experiência negativa e mal feita, muitas vezes traumática.

Muitas vezes conhecimentos técnicos não dizem nada. Não dizem nada sobre a história do candidato, do esforço para estar ali. Não precisa ser a babá ou o psicólogo do candidato, mas se esse demonstrou interesse pela vaga, ou se foi você quem foi atrás dele, caso o candidato tenha respondido alguma pergunta, em que a chance dele ser contratado diminuiu muito ou se extinguiu, o mínimo que ele espera é um feedback e alguma consideração (não pensando em candidatos que desrespeitam o profissional de RH, ou que são grosseiros e arrogantes)

3.Sua empresa não é o mercado

Assim como existem candidatos picaretas, que dizem ser sênior, sem ter o mínimo de experiência e conhecimento técnico ( Ser sênior não é apenas isso, mas saber trabalhar em equipe, ter resiliência, saber lidar com pressão), existem empresas que vendem uma imagem excelente, vídeos bem produzidos, gestores super eficientes, colaboradores sempre contentes, benefícios extraordinários, processos seletivos engrandecedores…

E aí na prática.. Bem na prática, exigem testes cansativos. Pedem horários absurdos para entrevista. Pedem um, dois ,três projetos para avaliar o candidato, falam que a oportunidade é a oportunidade da vida do candidato, que vai coloca-lo em outro patamar, que ele vai ser mais feliz do que nunca, mas que para atingir esse tão esperado prêmio, a tarefa é árdua e complicada..

Bem falando de um relato pessoal:

Recentemente, a um ano atrás uma empresa famosa, unicórnio da moda e da mídia me abordou para uma vaga. Sem ideia de salário, apenas benefícios, e falando da cultura da empresa.
Como no momento eu queria me avaliar profissionalmente e ver minha régua técnica, e como tinha contatos que falavam bem da empresa, e do seu processo seletivo, eu fui e arrisquei.

O recrutador na época, ficava me bajulando, falando que eu era o candidato ideal para vaga, que queria me ver na empresa e ia se esforçar ao máximo pra me auxiliar a entrar na empresa.

Começamos o processo. Virtualmente, primeiro mandaram perguntas sobre minhas expectativas. Mandei tudo, salário, rotinas, ambiente de trabalho, expectativa de plano de carreira e crescimento, expectativas técnicas e fit pessoais e culturais.
Até ai não me falaram nada mais, só que estava OK.
Me passaram um teste psicológico super chato de 20 minutos, com mais de 300 questões, muitas repetidas, me senti um idiota respondendo, como se eles colocassem a mesma pergunta 5x pra testar se eu respondia a mesma coisa em todas as vezes. Ok, feito.

Próxima etapa entrevista técnica: Aqui as coisas empacaram.
Pediram para fazer um live-coding de uma hora, com um Tech Lead da minha área, um aplicativo simples em algum framework JavaScript, nada demais, mas o Tech Lead nunca tinha horário disponível.

Após duas semanas tentando marcar a tal da entrevista técnica, me avisaram que não poderia ser feito por questão de agenda, e ai me passaram o projeto.
Projeto especificado mais ou menos, mas pedia pra ser feito em 3 dias, um projeto grande até um fluxo de telas de pagamento, com interações, responsividade, qualidade de código.
Não é impossível fazer esse teste em 3 dias, se você não tiver empregado.
Se você trabalha de 8 a 10 horas num cliente, gasta 2 horas pra se locomover pra casa, tem faculdade, ás vezes freelas, como vai arrumar tempo pra fazer um projeto desses em 3 dias?

A empresa não tem culpa dos seus problemas, mas poderia ser flexível em alguns casos…
Pedi uma semana, e fiz no fim de semana, mas a falta de resposta do recrutador, apenas exigindo que eu fizesse o teste logo e entregasse me desmotivou um pouco, e entreguei como consegui fazer, sabia que dava pra melhorar muita coisa, mas como vi que o esforço pra me recrutar estava mais no falar do que no fazer, também não dei 100%.

O recrutador sumiu. Aquela empatia e solicitude do começo do processo desapareceram. Após duas semanas que entreguei o projeto enchi o saco do cara por Linkedin. Ele viu e não respondeu.
Fiquei puto! Perdi meu fim de semana pra nada.. Promessas e promessas…

Depois de 1 mês ele me retorna: Ruben desculpa a demora, mas você não foi avaliado como Sênior e sim como pleno. Mas quero você muito aqui na empresa, acredito que o processo foi falho e vamos dar mais uma oportunidade pra você provar sua senioridade. Preciso só alinhar com o time técnico para você fazer outro teste.

Eu já tinha desistido da vaga. Não tinha interesse em estar na empresa. Não me interessava se ela ia me pagar 5 mil a mais (não ia), se ia me dar benefícios de morar na lua, de pagar plano de saúde pra família inteira, estava nem ai mais. o destrato e a forma como tudo correu só me causaram uma péssima impressão. No final eu não estava desesperado pra trocar de emprego, e na verdade eu até gostava bastante da empresa que estava. Todo esse encantamento no começo e desleixo com o resto, fez eu desistir da empresa, mesmo que eu não fosse fit técnico pra vaga, eu preferia ter o não de cara, do que toda essa enrolação.

Dois meses depois da entrega do projeto, vem o mesmo recrutador:
-Ruben abrimos uma vaga com seu perfil, quer tentar de novo?
- Não sei, mas obrigado pelo interesse.

Uma semana depois o recrutador saiu da empresa maravilhosa e mágica.

O que penso disso tudo?

1. Eu realmente não tinha fit pra vaga, e não era competente para tal

2. O processo foi muito mal coordenado, e fui mal avaliado, sem feedback nenhum do código ou de como eu estava indo nos processos da entrevista

3. A minha vaga não era essencial para a empresa. Sei da politica da empresa de contratar pessoas indicadas internamente muito mais do que pessoas abordadas por recrutadores. Sei disso porque diversas colegas que trabalham com mobile, saíram da empresa que trabalho para trabalhar nessa empresa e em menos de 1 semana estavam contratados, em um processo muito enxuto e rápido. Inclusive desenvolvedores com muito menos experiência do que eu, que dentro da empresa que eu trabalhava eram considerados Juniors, e foram contratados como Pleno e Seniors nessa nova empresa.

4.Por mais que eu use o produto dessa empresa, e acompanhe suas redes sociais e as atividades de ex colegas de trabalho nessa empresa, inclusive eventos, eu jamais trabalharia nela. Essa primeira experiência já me traumatizou num nível, que nenhum papo mole de recrutador, ou de Tech Lead que venha me falar das tecnologias mais legais, ou da experiência de trabalho mais engrandecedora possível vão me fazer querer passar de novo por um processo desses.

5.Atualmente estou bem na empresa que estou. Tenho feedbacks constantes, a evolução não só técnica, como pessoal é evidente. Tenho colegas com quem aprendo diariamente e o projeto que trabalho é um projeto bom e de destaque. Porque trocaria isso, por promessas sem comprovação e por complicações que uma “nova empresa mágica” me prometem, mas não entregam? Nem feedback dão? Se vivo num ambiente em que a cada semana, a cada mês, a cada dia descubro novas tecnologias, ferramentas e processos porque vou esperar meses por uma oportunidade que só é real pros outros?

4.Saiba o que você quer

Não adianta você mandar uma vaga de DBA esperando que um Front-end vá responder ela como candidato.

Não adianta você pegar o e-mail de um desenvolvedor e jogar no mailing da sua empresa de RH e enche-lo de SPAM.

Não adianta você não pré-selecionar os candidatos que você vai enviar a oportunidade, e fazer bizarrices: como mandar uma vaga pro candidato , na mesma posição e empresa que ele já está (eu já passei por isso)

Se você for a pessoa responsável pela vaga e as exigências, tente levantar as necessidades do projeto e empresa com o gerente do projeto, ver quais exigências são cabíveis para a vaga, quais são essenciais, quais são desejáveis, quais podem ser aprendidas com o tempo, qual background e experiência de candidato você quer. Ser assertivo pode poupar muito tempo dos dois lados.

Seu processo não tem candidaturas? Os candidatos não passam no seu processo? Será que a régua está muito alta? Muito baixa? As especificações e exigências são compatíveis com salários e benefícios?

Existe mercado de trabalho para a vaga? Como tem sido o feedback e processo da vaga? Como está a avaliação da empresa em ferramentas de opinião?

Como estão processos e oportunidades parecidas em concorrentes? Qual a abordagem dos concorrentes? Como é o ambiente e situação atual do candidato? Minha empresa e vaga oferecem atrativos que podem atrair a atenção, dedicação e reter esse candidato numa possível contratação?

Eu estou dando o melhor e sendo empático e dando atenção e feedback ao candidato, ou só estou enchendo a caixa de SPAM do candidato, sendo irônico e menosprezando sua experiência profissional?

Por menosprezar eu não quero dizer apenas ignorar, mas muitas vezes vir com textos bonitos como “ Parabéns pela sua experiência e trajetória profissional, gostamos do seu perfil” e na menor das questões do candidato, simplesmente abandona-lo.

Outros recrutadores da mesma empresa já abordaram o candidato? Qual foi a experiência que tiveram?

Se um candidato já recusou o contato, ou oportunidade da empresa, o que contatá-lo todo mês pode significar pra mim como recrutador e como empresa?

Essa são algumas questões a se levantar.

5.Seja transparente e objetivo, mas não com descaso

É muito importante alinhar expectativas logo de começo. Nas primeiras conversas já falar de salário, experiências, rotinas, projeto, expectativas de ambas as partes, valores, cultura, projeção conforme o tempo, casos de sucesso de ambas as partes, momentos profissionais e pessoais.

Quanto mais rasa a conversa e menor interesse de alguma das partes, menor chance de sucesso do recrutamento.

Caso nenhuma das partes se entenda em questão de exigências ou expectativas, sempre pode ser educado, e deixar portas abertas para futuras oportunidades. Nunca se sabe o dia de amanhã. O profissional recusado de hoje pode ser a referência de amanhã. A empresa referência hoje pode ser a falência de amanhã, ou a empresa desacreditada hoje pode ser o novo unicórnio amanhã.

Mas sempre trate com cordialidade. Nunca perca a postura. Não trate ninguém com descaso, seja o nível profissional que a pessoa estiver.

Claro que tudo dentro de seus limites. Candidatos que assediam recrutadoras, são mal educados e grosseiros, machistas e misóginos, racistas, merecem e devem ser denunciados e colocados em seus lugares.

Muitas empresas omitem feedbacks, por problemas de gestão ou até de cultura, outras tantas fazem candidatos gastarem recursos que não tem, outras perdem oportunidades de recrutar talentos por processos antiquados, preconceitos antigos e pré-estabelecidos, por exemplo : A Localiza que força seus funcionários a esconder tatuagens , eu jamais trabalharia numa empresa assim. Primeiro porque sou todo tatuado. Segundo pela politica da empresa ser draconiana. Terceiro porque essas empresas estão fadadas ao esquecimento e vão ser engolidas por novas gerações e mentalidades.

Se adapte ou morra.Acredito muito nisso. Falta de empatia, falta de transparência, processos extremamente cansativos, extremamente verticais, hierarquia exagerada, falta de visão, falta de representatividade, falta de solicitude, gestores com mentalidade de aristocracia, gestores que exigem mundos e fundos e não dão exemplos, todas empresas que tem essa cultura estão fadada aos fracasso.

Empresas, recrutadores, influencers que se baseiam em pessoas com opiniões não-empáticas, vão ser cada vez mais mal vistas pelo mercado.

Opiniões como essa :

ou essa:

Vão ter um feedback muito ruim, e não só de quem opina, mas quem compartilha da mesma opinião.

6.Dê feedbacks!!!

Quanto mais atenção, processos e exigências você exige de um candidato, mais ele espera que o retorno, seja em feedback, em contratação ou condições da vaga aconteça.
Desprezar o candidato, e fazer perder seu tempo e dinheiro, só vai causar uma péssima impressão sobre a empresa, e sobre o profissional de recrutamento.
A chance de um candidato recusar o contato com você e até bloqueá-lo é praticamente certa.

Vou contar uma experiência pessoal que reflete isso:
Em 2015, após trabalhar mais de 3 anos em startups pequenas e agências, eu resolvi que ia entrar numa empresa grande.
Vi uma vaga para desenvolvedor front-end na Centauro.
Resolvi aplicar. Não lembro a plataforma que encontrei, se foi no Trampos ou Linkedin.
Lembro que acabei me candidatando por duas empresas, duas consultorias, uma multinacional de RH e Recrutamento com foco em TI, outra uma consultoria de TI que foi fundada por profissionais de tecnologia.

Na primeira fui no escritório na Paulista, fiz um processo demorado, escrevi redação, fiz testes psicológicos no papel, escrevi contatos de 3 últimos empregos, fiz bateria de perguntas com o recrutador, fui entrevistado em grupo, esperei por duas horas antes de ser entrevistado, enfim um processo cansativo, mas como na época eu estava em busca de novos ares e formas de trabalho, levei numa boa, apesar de internamente odiar esses processos.

Na segunda, foi pedido um projeto básico, uma tela simples, tinha que replica-la responsiva, fiz em menos de 2 horas e enviei no mesmo dia, tendo a resposta dois dias depois:
 — Queriam me entrevistar pessoalmente no cliente final.
Marcamos a entrevista pra próxima semana, nessa entrevista fui no horário marcado, conheci o lugar de trabalho, fui recebido pelo entrevistador técnico, junto com mais 3 membros da equipe que iria trabalhar, um deles outro desenvolvedor front-end ( salve Lucas! ), que primeiro me deram as boas vindas, e depois apresentaram a empresa e o projeto, e depois começaram a entrevista:
(Lembro da famigerada pergunta que nunca me sai da cabeça até hoje,em pleno 2015):
- Mas e o Angular? Como tá o conhecimento de Angular?
- Respondi que tinha pouco conhecimento, mas o suficiente para trabalhar com a tecnologia, inclusive tinha feito meu portfolio com a tecnologia, mas ainda era recente esse conhecimento, expliquei como fiz o portfolio e como entendia o funcionamento da tecnologia.

Depois dessa resposta, e de várias outras, o time compartilhou risadas comigo, falando que muitos candidatos falavam que tinham conhecimento avançado na tecnologia, mas na hora de explicar como trabalhar com ela, se enrolavam e não sabiam como explicar.

No final me deram um feedback rápido, que eu tinha saído bem na entrevista ( isso é muito importante pro candidato, você dar um feedback mesmo que não seja assertivo em questão de contratação ou não, mas pra ele ter um direcionamento nas próximas etapas, ou até oportunidades que concorrer) e se dispuseram para perguntas sobre a vaga ou projeto ( isso também e muito bom pois mostra que a empresa esta aberta a opiniões e duvidas do candidato e que o processo é horizontal e não debaixo pra cima )

E dois dias depois me ligaram pedindo pra marcar um papo final sobre a contratação e que eu tinha passado na vaga.
Na semana que vem eu estava sentado com o Gerente do Projeto, acertando detalhes como horário, remuneração, ambientação no trabalho. Foi uma experiência muito boa pra mim, e guardo muito carinho e boas lembranças dessa experiência profissional, inclusive de nos primeiros meses, ter almoçado com o CEO da empresa no mesmo restaurante, o cara na mesma fila que eu e meus colegas. Diretores e gerentes serem super acessíveis, e olharem pra você como parceiros e não subordinados. Colegas de trabalho excepcionais, desde os QAS até desenvolvedores, designers, time de marketing todo mundo sempre muito solicito.

Enfim. Dois meses depois de ser contratado, recebi o feedback por e-mail da outra consultoria:
- Nos desculpe, Ruben, mas seu perfil para a vaga na Centauro não foi selecionado e a vaga já foi preenchida por outro candidato.

O outro candidato: Eu mesmo. Só que por outra empresa.
Sei disso porque na época em que fui contratado, só eu tinha sido contratado como front-end. Por essa outra consultoria que demorou dois meses para dar feedback, apesar de ter exigido um monte de coisas no processo, ninguém havia sido contratado.

Aí fica o questionamento: É mérito do candidato, ou da empresa que recruta e seus processos?

7. Exigências são importantes mas nem sempre

Li uma vez no Linkedin um post do Zeno Rocha, que na empresa que ele trabalha nos EUA, um candidato sem experiência prévia em programação, sem faculdade, estava trabalhando a poucos meses na empresa, tendo mentoria e todo suporte para trabalhar, e esse mesmo candidato estava produzindo muito em poucos meses e ajudando no crescimento da empresa.

Achei fantástico. Pensei, será que isso existe no Brasil ? Depende que Brasil estamos falando. Existem sites e páginas como o Vagas Arrombadas, ou o TIdiota, que mostram que uma boa parcela do mercado, se exige conhecimentos muito altos, alguns até impossíveis (como domínio de 5 anos em tecnologias que existem a menos de 2), que exigiriam uma década de experiência, muito dinheiro investido em cursos, para aí pagar algo como 2000 reais PJ. Vagas que pedem senioridade em vagas de estágio. “Estágio FullStack”, “Fullstack Junior”, pra mim soam como uma enganação sem tamanho, uma armadilha.

Vejo nos grupos de vaga de Facebook, recrutadores e muito candidatos falarem que isso é uma oportunidade, aprender de tudo, ser exigido ao máximo pra em poucos anos ser um profissional super experiente e referência de mercado.
Bom o que penso disso, é que empresas querem profissionais faz tudo, multifuncionais, uma equipe inteira que custaria ai por baixo uns 40–50 mil reais no minimo, em um profissional só pagando 2 mil reais. Geralmente a empresa tem pouco capital pra investir ou quer lucrar a todo custo vender um projeto e se aproveitar do profissional.
Não tem nada de errado em ter pouco capital pra investir, mas as exigências tem que ser do mesmo nível do investimento.

Certa vez vi na capa da Veja São Paulo um “empresário” do ramo digital, sendo celebrado, faz muito tempo em 2014 isso, ele tinha uma agência de blogs e sites, basicamente em WordPress, tinha altos contatos na elite paulistana, vendia os blogs por mais de 20 mil reais, manutenção de 15 mil por mês, para socialites, políticos, celebridades, tendo um faturamento ai por baixo de 300 mil por mês. Claro existe o custo de operação da agência. Exige os contatos que são dele. Custos de infra-estrutura.
Mas ai vi uma vaga de desenvolvedor WordPress na agência dele.
Salário de 2 mil reais. Sem benefícios. Trabalho exaustivo e aos fim de semana, sempre disponível.

Cara complicado. O desenvolvedor entrega um projeto com valor de venda de 35 mil e recebe apenas 2. Muitas vezes faz mais de um projeto por mês então essa entrega é até maior.

Mas o que quero dizer com isso tudo?

Ser exigente muitas vezes é bom, e muitas vezes não é. Existe uma diferença entre ser exigente, e ser explorador.

Existem pessoas como a Aline Bastos que criou uma lista de vagas para estágio e desenvolvedores júniors.

Existem fóruns de mentoria e que ajudam candidatos com vagas como o Front-end Brasil

Existem programas como o da Zup de capacitação profissional para jovens de periferia como o Estrelas fora da Caixa

Mentoria e formação como o Educafro,

Programas de formação como o Gerando Falcões

Autismo Tech, levantando debates importantes sobre a oportunidade de pessoas com Autismo no mercado de trabalho

Dentre outros ( cite nos comentários e coloco aqui depois)

Mas se sua empresa exige mais do que entrega ao colaborador, pode ter certeza que o resultado dela vai ser: Rotatividade grande, possíveis processos trabalhistas, e muitos desafetos no mercado. A empresa antes de ter apenas o foco só em lucro, tem uma função social, e não tem nada de errado você contratar conforme seu orçamento, mas saiba o que esperar conforme o que se tem.

8.Compartilhe riscos

Se a empresa que você trabalhar quer os melhores colaboradores, quer ter um ambiente saudável e sólido, quer ter um crescimento sustentável, não tem jeito, tem que assumir riscos junto com os funcionários.

Tem que pensar em plano de carreira, tem que ser claro com os colaboradores, tem que demonstrar os valores, tem que estar presente em momentos importantes, como numa doença, numa gravidez, num eventual problema psicológico.

Se a empresa quer ser um motor do desenvolvimento pessoal e profissional desse colaborador, onde ele vai conseguir realizar seus sonhos e projetos, ela tem que estar atenta as necessidades desse colaborador.

Por exemplo, em tempos de pandemia e pós pandemia, oferecer uma vaga para um candidato de TI que não seja remota, e esse candidato já trabalhar remotamente e que provavelmente gosta, não só é um tiro no pé, mas como é praticamente quase 100% chance de sua oportunidade ser recusada.

Alocar o candidato em tempos normais em um cliente sem dar o devido suporte, é muitas vezes visto por gestores como uma medida, que tanto faz, já que muitas empresas e consultorias tem contratos milionários, e de qualquer jeito vão ser pagos, caso o candidato seja desalocado, seja demitido ou não consiga se adequar a cultura do cliente.

Nesses dois casos teve falhas de estudo de perfil do candidato, com perfil do cliente, ou perfil de trabalho do candidato. O resultado é o candidato rejeitar a empresa em novas oportunidades, alta rotatividade, péssimas avaliações em ferramentas como Glassdoor, péssima imagem e referências da empresa e seus recrutadores no mercado.

Investir nas pessoas e no desenvolvimento delas é um legado incrível para uma empresa. É um risco,especialmente em um mercado volátil, incerto e aquecido. Mas é o melhor mecanismo a longo prazo, que mesmo que não retenha alguns talentos, com certeza o marketing boca-boca, as experiências aprendidas e a cultura legada, acabam atraindo novos candidatos com cultura parecida. Afinal se trata de pessoas e os valores entregues por colaboradores e empresas simultaneamente.

9.Antes de tudo a cultura

Cultura é algo muito difícil de definir, e ainda mais de praticar.
Pegando uma definição do google:

O conceito de cultura organizacional é tudo que envolve a rotina de uma empresa e funciona como diretriz para guiar o comportamento e mentalidade de seus membros.

Basicamente os colaboradores de uma empresa, seus gestores e fundadores tem que compartilhar uma cultura semelhante. Posições politicas, pessoais, religiosas podem ser diferentes, dentro do limite do responsável.

Se a empresa, profissional, seja ele o candidato ou o recrutador, seja ele a gerência ou fundadores, não defendem uma cultura forte e humana, participativa, colaborativa , pró-ativa, existem grandes chances de esse individuo ou empresa se auto-sabotar no mercado.

Nada adianta videos maravilhosos, processos bem feitos, recepções calorosas, candidatos que sabem todas as respostas, se apresentam a bala de prata da vez, se no dia dia, é tudo ao contrario.

Já vi muitos juniors com postura de Seniors. Muito senior com postura de junior.

Muito recrutador que não só te entrevista e defende os interesses dele e da empresa, mas auxilia o profissional em sua trajetória macro.

Muita gerência que se mostra realmente preocupada com o desempenho pessoal e profissional do colaborador. Com a saúde mental e física. Com a evolução técnica. Que isso não é só papo de marketing de Linkedin isso é pratica.

A isso tenho que agradecer muitas pessoas que encontrei na minha trajetória. Recentemente seis pessoas em especial. Quando entrei na Zup, um dos motivos foi entrar num projeto grande, de um banco, um desafio novo para mim.
O segundo foi os valores e cultura da empresa. Algo que eu avalio muito antes de salário ou benefícios. No meu primeiro projeto na empresa tive alguns problemas em que sempre fui auxiliado pela minha recrutadora Quésia Nogueira, quando já no cliente tive todo o auxilio e confiança do meu DSM, Fernando Queiroz, toda mentoria do meu BP, Eliseu Conz, e quando surgiu a oportunidade de trabalhar em um projeto do zero, tive todo o auxilio da Kenia Moura minha DSM atual para me ambientar e chegar junto no projeto, direcionamento preciso do meu TechLead Bruno Carvalho, e atenção da BP Isabella Fernandes.

Cara isso faz uma PUTA duma diferença!! Desculpa o palavreado, mas ter essas pessoas cuidando de você,olhando pra sua evolução dentro da empresa, discutindo suas necessidades e apontando caminhos, jogando junto do seu lado, é um diferencial que deveria ser a regra em todas as empresas e eu sei que não é.

A cultura não é sobre ter mesa de pebolim e chopp nas sextas feiras. Não é sobre artigos na mídia, e cases de sucesso. Não é a marca da empresa e sua impressão no mercado. É os funcionários. Como são tratados? Mero recursos? Pessoas? Como sua empresa tratou os funcionários na pandemia? Como auxilia em caso do funcionário ter algum problema pessoal que interfira em algo do trabalho? Trata o funcionário como uma ficha ou número, ou trata ele como alguém que tem melhorias a serem trabalhadas, mas tem muito valor a ser entregue?

Isso se trata a cultura!!

10.Pesquisa, Perfis e Resultados

Pesquisar perfil de candidato é algo chato imagino, algo difícil, lidar com diversos perfis e egos de candidatos também. TI é um ramo onde tem muito cacique pra pouco índio, muita capacidade mal aproveitada, muita gente se achando a ultima bolacha do pacote, muito gênio escondido em oportunidades mal pensadas.

Lidar tudo isso no dia-dia deve ser bem complicado. Ainda mais complicado o desafio de uma área que acredito ser muito mais instável que a nossa. Ser recrutador não é fácil.

De TI especialmente, que acredito existirem diversos perfis, Perfis que ignoram, perfis que exigem demais e entregam de menos, perfis que entregam demais e exigem de menos, perfis que se adequam a empresas como agências, outros como freelancers, outros como consultoria, outros como empresa de tecnologia, fintechs, bancos, e-commerces, startups, cada empresa, cada ramo tem seu ritmo, preocupações, cultura, nível de desenvolvimento organizacional, nível de maturidade no trabalho.

Cada perfil tem valores a agregar, e as vezes ter trabalhado numa empresa famosa não quer dizer muita coisa, ter um cargo de Sênior também não, ter cargo de gestor também não, ter relatórios e números impressionantes também não.

As pessoas sabem se mascarar. Sabem mentir, existem desenvolvedores que querem escalonar rápido no mercado, o que a anos atrás era impensável acontecer, como salários de mais de 6 mil reais em menos de 3 anos de experiência é uma realidade para muitos profissionais.

Assim como antes muitas vezes para algumas pessoas, apesar de menos recursos, menos cursos,videos no youtube, faculdades, empresas, startups ,tecnologias, o mercado parecia um pouco mais ‘orgânico’, Hoje parece que temos, um mercado farto para plenos e seniors, e um mercado bem limitado e extremamente concorrido para juniors e estagiários. Grande parte a cultura ou falta de cultura de alta lucratividade e falta de planejamento a médio e longo prazo de muitas empresas.

Muitos profissionais são mais habilidosos em empresas com um perfil semelhante ao seu. Muitos colegas reclamavam da empresa que trabalho, outros construíram a carreira e eram referência no mercado e na empresa, outros assim como eu estavam satisfeitos e felizes com o trabalho.
Se veem mais felizes em outra oportunidade ou cenário. Muitos não tem filho e responsabilidades, Muitos tem, e buscam um lugar mais controlado e sossegado, ou buscam o equilíbrio entre desafios e pressão e também estabilidade.

Existem empresas pagando duas vezes mais que a média do mercado, mas com exigência psicológica e pesada em questão de rotina de trabalho.

Existem profissionais ótimos em entrega de projetos e resultados, mas péssimos em entrevistas e processos seletivos. E isso é uma boa parte do mercado, especialmente profissionais tímidos, ou que não tem soft-skills como comunicação bem desenvolvidos. Muitos profissionais só querem programar, não se preocupam com habilidades que muitas vezes acabam sendo decisivas em contratações ou oportunidades.

Considerações Finais

Eu já estive nas duas pontas. Já assessorei recrutadores técnicos e também com perfil mais de RH e psicologia a encontrar candidatos e também já observei entrevistas de HeadHunters e Gerentes de Projeto. Já entrevistei pra empresa que trabalho atualmente, candidatos para projetos urgentes, de mais variados níveis, desde pessoas que se declaravam CTOS, até juniors recém chegados a menos de 6 meses de mercado.

O mercado está inflado. É difícil saber o que um candidato fala se é verdade ou não. Algumas coisas nos dão muitas pistas, outras nem tanto.

Acho que não existe a contratação ou o método perfeito para isso.
Existe um corpo de profissionais que se formam com o tempo em volta de valores e experiência, que compartilham visões parecidas apesar de diferentes backgrounds, e que trabalhando em conjunto conseguem trazer gradualmente cada vez mais valor para a empresa.

Acredito que o mercado de TI vai continuar evoluindo e crescendo cada vez mais, a inclusão de mais e mais pessoas no mundo digital, a extrema digitalização da economia, a chegada de gerações já digitais desde o berço vão gerar uma demanda cada vez maior, junto com tecnologias como 5G,IPV6, Machine Learning, Data Science pelo profissional de TI.

Já os profissionais de recrutamento, vão sofrer um desafio gigante, em que quem não se adapta e conhece pelo menos o básico da área em que atuam, quem não se atenta algumas questões que coloquei aqui nesse texto, quem não tem o mínimo de empatia, entendimento de mercado e valores de empresa e clientes está fadado ao fracasso. Mas isso não é só na área de recrutamento como em todas as áreas profissionais.

Especialmente TI por ser uma das áreas mais mentalmente estressantes, com maior número de casos de depressão e burnouts.

Obrigado, a você que leu todo esse texto, qualquer sugestão ou dúvidas, só comentar abaixo!

Segurança pra quê?

Antes de começar a ver sobre os Content-Types do Strapi, antes de ver a estrutura de arquivos e rotas do Next.js, é bom discutirmos sobre Segurança.
Uma preocupação que costuma não ser acompanhada com a devida atenção em certos times, e que pode acarretar um custo bem alto, quando um projeto for colocado em produção.
Esse artigo é mais um artigo introdutório a stack Next.js +Strapi , vamos ainda abordar TypeScript, Fetch de Dados, Layouts, CI/CD e Deploy, mas antes de tudo vamos abordar segurança.

Abaixo vamos discutir, os erros mais comuns de segurança em aplicações web e como mitiga-los ou corrigi-los em nossa aplicação Strapi + Next.js:

XSS/CRSF:

XSS ou Cross Site Scripting, é uma técnica maliciosa pra injetar código na nossa aplicação e burlar a segurança para sequestrar dados ou manipular uma sessão do usuário por exemplo. Esse é um artigo muito bom para se aprofundar no assunto.

CRSF ou Cross-site request forgery, é quando alguém utiliza de uma técnica maliciosa para conseguir através de um request seja via Postman ou browser conseguir atingir nossa base de dados, apagar dados de usuários por exemplo, roubar dados de sessão ( como cartão de crédito, endereços etc) entre outras coisas.

Click Jacking:

Sabe quando você abre páginas que tendem a enganar o usuário, para digitar dados e no final acabam enviando esses dados para pessoas que querem usar de forma maliciosa? Ou que podem ter malware ou exploits e instalá-los na maquina do usuário?

Vulnerabilidades comuns em Rest APIS:

• DOS & DDOS (Denial of Service) : Quando um hacker quer derrubar uma API , aplicativo ou site , ele pode disparar requisições em massa para aquele API ou endpoint.
• Exposição de Informações Sensitivas: Quando expomos dados sensitivos do usuário, especialmente sem criptografia em nossa API. Ids, e-mails, endereços, informações de pagamento etc.
• Ataques MIM (Man in the Middle) : Quando um hacker tenta interceptar a comunicação de client e servidor , com a intenção de roubar dados.
• SQL Injection: Injeção de código que altere o comportamento esperado da API e do Banco de Dados. Através de uma injection um hacker consegue roubar informações, quebrar a API, alterar seu funcionamento.
• Insecure Direct Object References: Quando você expõe uma API com endpoints como /user/id/30, e um usuário tenta acessar um ID que não compete a ele, e consegue, você está expondo Referências diretas de objetos inseguros.

Vulnerabilidades comuns em APIS GraphQL:

• /graphql?query={__schema{types{name,fields{name}}}} :
  Se seu API GraphQL estiver público, apenas com uma query dessa, o usuário que a usa-la, consegue ver todo o esquema da sua API
• Queries Maliciosas: Hackers podem montar queries maliciosas, sejam para roubar dados, corromper seu banco de dados, ou derrubar sua API/servidor
• Brute-Force: Para evitar problemas com hackers tentando quebrar os dados da sua API GraphQL , você pode usar plugins como o GraphQL Rate Limit, que vai limitar quantas vezes os campos vulneráveis da sua query podem ser executados em um intervalo de tempo.

Como evitar tudo isso?

No Strapi:

• Entendendo o arquivo de Configuração do Strapi & sua segurança:
  O Strapi possui uma documentação rica que nos mostra como garantir a segurança do CMS :
  Possui configurações para XSS, P3P, Hsts , X-Frame-Options (Clickjacking), CORS (muito útil para setar que domínios podem acessar sua aplicação, que headers podem ser expostos),
  IP (Consegue configurar que IPS enxergam ou não sua aplicação)
• Injeção de Credenciais: Use um arquivo .env, para não ficar injetando credenciais no meio do seu código
• Validação: Você pode criar um middleware para validar se os dados da sua aplicação já existem e não vão ser duplicados, ou você também pode usar uma lib como o Joi , para fazer validação dos campos da sua API, mas o Strapi já possui algumas validações nativas que você pode definir nos models da sua API, apenas se você usa MongoDB
• Roles & Permissions: O ideal é você criar uma documentação pra sua API em quais permissões e quais endpoints você vai habilitar, para não acabar caindo no erro de permitir tudo e oferecendo risco aos dados da sua API
• Policies: Você pode setar as policies da sua API direto no código do Strapi através do ./config/policies para Policies globais e ./api/**/config/policies para endpoints locais. É uma camada extra de segurança para sua aplicação Strapi. Para setar policies com GraphQL , a documentação do Strapi tem uma página exclusiva a isso.
• Data-Leak: Você pode passar um paramêtro private:true, dentro do parametro no model da sua API, para tirar o valor de ser acessado por qualquer pessoa. Clique aqui para saber mais
• JWT: você pode exigir que para o usuário acessar endpoints sensíveis da sua aplicação ele esteja logado e utilize JWT.
• Exposição de Informações Sensitivas: O Strapi permite com a edição dos controllers, quais informações podem ser acessadas nas chamadas dos endpoints. Você pode apagar certos campos e paramêtros dos resultados.

No GraphQL:

• DOS (Denial of Service): Você precisa limitar suas queries. Um hacker mal intencionado, se descoberto sua API GraphQL, pode montar uma série de queries que podem sobrecarregar seu servidor. Esse é um ótimo artigo no blog do Apollo que ensina alguns casos de queries maliciosas e como evitá-las.
• Setando Policies para as Queries: Você tem que customizar o Schema da sua API GraphQL, setando as policies desejadas para ter controle de quem ou como se acessa o quê na sua API
• Acesso não autorizado: Você precisa desabilitar o GraphQL Playground, que já vem desabilitado na versão produção do Strapi (você pode desabilitar para outros ambientes aqui) , depois seu endpoint GraphQL não é mantido por uma rota mas por um middleware.
  É necessario criar um novo middleware, que vai verificar se o endpoint que queremos é o /graphql e se o usuário autenticado é o que queremos:

module.exports = strapi => {
  return {
    initialize() {
      strapi.app.use(async (ctx, next) => {
        const handleErrors = (ctx, err = undefined, type) => {
          if (ctx.request.graphql === null) {
            return (ctx.request.graphql = strapi.errors[type](err));
          }

          return ctx[type](err);
        };

        // check if it's a graphql request
        if (ctx.request.url === '/graphql' && ctx.request.method === 'POST') {
          if (ctx.request && ctx.request.header && ctx.request.header.authorization) {
            try {
              // get token data
              const { id } = await strapi.plugins[
                'users-permissions'
              ].services.jwt.getToken(ctx);

              if (id === undefined) {
                throw new Error('Invalid token: Token did not contain required fields');
              }

              // check if the id match to the user you want
              if (id !== 'my-user-id') {
                return handleErrors(ctx, 'You are not authorized to access to the GraphQL API', 'unauthorized');
              }
            } catch (err) {
              return handleErrors(ctx, err, 'unauthorized');
            }
          } else {
            // if no authenticated, return an error
            return handleErrors(ctx, 'You need to be authenticated to request GraphQL API', 'unauthorized');
          }
        }

        await next();
      });
    }
  };
};

Para ser autenticado você precisa mandar um JWT no header. Veja aqui na documentação de autenticação do Strapi como fazer.

No Next.js:

• Validando os campos: A validação de campos de forms, não serve apenas para guiar seu usuários, mas também garantir a integridade das informações transmitidas do client para o server. Isso evita uma série de códigos maliciosos serem inputados em nossos Serviços. O usuário pode ainda tentar manipular os dados, editando o HTML no DevTools, mas isso é outro problema..
• CRSF: Passando o paramêtro Content-Type: application/JSON, nas nossas requisições, força nossa aplicação a não usar requisições simples, e protege contra ataques
• XSS: Esse guia é muito útil e mostra algumas regras que é bom seguir ao desenvolver nossa aplicação front-end para não ter dor de cabeça depois em questões de segurança e XSS. Esse plugin pro Next.js também ajuda a implementar XSS Protection, ajudando o browser a sanitizar áreas vulneraveis da sua aplicação.
• Security Headers & ClickJacking: Utilizando X-Frame-Options:DENY ou SAMEORIGIN, você evita que terceiros consigam rodar sua aplicação Next.js dentro de um frame.
  O plugin next-secure-headers, te ajuda com isso. Além de implementar o FrameGuard, ele também implementa XSS Protection, contentSecurityPolicy,nosniff,noopen,forceHTTPSRedirect, referrerPolicy, expectCT.
• JWT & Tokens Rolantes: Você pode implementar JWT, para a autenticação do seu App para garantir a integridade da sua API e ao acesso a ela, esse é um bom tutorial que ensina isso
• Mais:
  NextAuth.js : Um plugin para te ajudar com a segurança na autenticação do seu app Next.js

SSL:

Uma etapa antes de publicarmos nosso site para produção é ambientar nosso domínio e servidor ao protocolo HTTPS. HTTPS, protege nossas requisições de serem alvos de ataques Man In the Middle, e também são cruciais para SEO pois impactam no Ranking do Google.
Algumas formas de conseguir certificados SSL gratuitamente para seu site são utilizar o serviço de:

• Lets Encrypt
• SSL For Free
• AWS Certificate Manager
• ZeroSSL
• CloudFlare SSL

Cacheamento de APIS:

Apesar de não ser apenas uma preocupação com segurança mas também com performance, o cacheamento de APIS pode ser recomendado para que seu site consiga funcionar mesmo em ambientes offline, mas quando se trata de dados dinâmicos, acaba sendo não recomendado, apenas para dados que não mudam constantemente. Esse é um tópico que requere um artigo só pra ele, mas caso você sinta interessado em saber mais sobre isso recomendo ler os seguintes artigos:

• Web.dev : Cache API: Quick Guide
• Amazon Api Gateway: API Caching
• Using CloudFlare with your API
• GraphQL Caching

Roadmap de Segurança do Strapi:

O time do Strapi, está planejando algumas features que podem ajudar em futuras releases na questão de segurança:

Esse é o link do Product Board. Nele vemos que o time do Strapi planeja features como: 2FA( Autenticação de dois fatores) , Token Rolante ( JWT), SSO ( Google, Twitter, Facebook, GitHub), dentre outros que já estão sendo testados: como Permissões e Regras por usuário e Permissões a níveis de campo.

Ferramentas de checagem:

Existem na web alguns sites e ferramentas que testam quão seguro é nossa aplicação, Seguem abaixo alguns deles:

Sentry: Sentry é uma ferramenta para monitoramento de erros de webapps. Tem suporte a diversas tecnologias e plataformas. É facilmente integrável com GraphQL, Strapi ou Next.js. Possui uma versão free para desenvolvedores.

Sqreen: Sqreen é uma plataforma de monitoramento de segurança de webapps. Pode trazer dados em tempo real de exploits em potencial, te proteger de ataques e atividades maliciosas.

O Strapi tem suporte ao Sqreen.

• Primeiro: criar uma conta trial do Sqreen
• Segundo: configurar sua organização no painel do Sqreen
• Terceiro configurar o Sqreen no Strapi

No Next.js você também pode usar o Sqreen, mas a configuração é um pouco mais complicada

• Primeiro: criar uma conta trial do Sqreen
• Segundo: configurar sua organização no painel do Sqreen
• Terceiro configurar o Next.js para usar um Custom-Server
• Configurar o Sqreen para Node.js

LGTM: LGTM é uma ferramenta open-source utilizada por grandes players do mercado, como Google, Microsoft, Nasa e Dell, que verifica vulnerabilidades no seu código através de um repositório no Github ou BitBucket.
Tem uma ferramenta de code review automático e é bastante poderoso, possui alertas para te avisar sobre problemas no código e também comparativos e histórico.

SonarCloud: SonarQube é uma feramenta muito poderosa, que não só verifica Bugs e Vulnerabilidades no seu código, como alguns parâmetros como Mantenabilidade de código, Coverage de Testes, Codesmells, Duplicações de código, ele analisa seu código e pode barrar um P/R ou M/R no Github, GitLab, Azure DevOps ou BitBucket caso não atinja a qualidade de código esperada. O SonarCloud possui também um plugin para IDES que verifica em real time

Mozilla Observatory: Ferramenta da Mozilla que vai ajudar a trazer Insights sobre a segurança do seu website.

DigiCert SSL Tools: Vai checar dados do seu certificado SSL, mostrar possíveis vulnerabilidades, o Certificate Chain e a Configuração de servidor.

Qualys SSL Labs: Ferramenta um pouco mais completa que a da DigiCert.

Pen-test Tool: Website Vulnerability: Site que possui verificação de SQL Injection, XSS, Inclusão de arquivos, Execução de comandos remotos , porém é pago.

Sucuri SiteChecker: Sucuri é bem conhecido no mundo de segurança web. Detecta se seu site está blacklisted no Google, se tem links não seguros, entre outros parametros de segurança

Bom pessoal, obrigado se você chegou aqui e teve paciência, a intenção era ter dado uma idéia geral de como mitigar e solucionar diversos problemas de segurança e vulnerabilidade em aplicações web com Next.js e Strapi, antes de começarmos a usar a Stack, sendo que os conceitos aqui apontados podem ser utilizados e verificados em qualquer aplicação web não só com Node.js e JavaScript/TypeScript mas com outras linguagens e que utilizem Rest APis ou GraphQL Apis. Esse é um assunto muito extenso que poderia render vários artigos,mas tentei resumir nesse aqui.

Referências:

• Vulnerabilidades no Strapi
• Vulnerabilidades no Next.js
• Cross Site Scripting Prevention Cheat Sheet
• Clickjacking
• HTTPS e Resultados no Google
• O Certificado SSL , altera os resultados de busca?
• Securing your GraphQL API from Malicious Queries
• GraphQL NoSQL Injection through JSON Types
• GraphQL Injection