Já falamos sobre como o Flutter pode ser interessante e porque você deve aprender Flutter por aqui na devGo. Um dos pontos que chamamos a atenção foi você poder desenvolver um aplicativo mobile e web com o mesmo código, mudando apenas a forma como você irá realizar o build de cada um. Se você precisa, além do web, de uma aplicação mobile deveria estar considerando Flutter sem nem titubear.

No texto de hoje, com a experiência que tivemos aplicando Flutter na Devnology, vamos analisar cada aspecto do Flutter Web e analisar, se realmente seria uma boa escolha para a sua aplicação:

Em termos de desenvolvimento

Sim, vale a pena.

Os desenvolvedores web costumam, em um primeiro momento, estranhar muito o Flutter. Como assim vou desenvolver uma aplicação web sem nenhum HTML?

Mas o Flutter realmente tem uma adaptabilidade e curva de aprendizado muito boa. A estrutura em Dart é fácil de entender e bem fácil de aplicar. Apesar do estranhamento, em pouco tempo os desenvolvedores estarão bem familiarizados e conseguirão desenvolver bem.

Falando de performance

O Flutter é conhecido por ter uma boa perfomance e isso vale também para web, mas há algumas observações bem importantes para isso:

Há também um preço a se pagar por essa perfomance. O Flutter possui uma renderização um pouco diferente de outros frameworks web, e costuma ser um pouco mais pesado. Justamente por ser mais pesado, demora algum tempo a mais para ser carregado —até porque, não há um suporte para aplicações estáticas no Flutter, como o Next ou Gatsby no React, por exemplo. Mas uma vez carregado, é bem agradável e fluído.

O Flutter é bem sensível a perfomance no Web. No web, estamos falando de diferentes navegadores, diferentes sistemas operacionais e diferentes computadores —não é algo tão “padronizado” quanto um celular, por exemplo. Por isso, qualquer desvio no código, qualquer componente a mais, qualquer estrutura mal realizada pode ter um efeito bem grande na perfomance. Desde que você siga com cuidado, terá uma boa perfomance.

Flutter Web é realmente para Web?

O primeiro estranhamento é o Flutter não ter HTML, uma tecnologia presente desde sempre em qualquer aplicação web. E não são só os desenvolvedores que estranham a falta do HTML, mas também quaisquer outras ferramentas de aplicações web: algumas bibliotecas, comuns em outros frameworks não serão possiveis de trazer para o Flutter; ferramentas de SEO costumam sofrer para mapear o site, afinal, o mapeamento é feito em HTML e com Flutter não HTML.

Algo que considero bem importante e aguardo ansiosamente no Flutter é suporte a aplicações estáticas. Boa parte da web é estática e realmente não há necessidade de buildar a aplicação a cada acesso. Outros frameworks, como o React mesmo também sofreram com o mesmo em seus primeiros anos, e hoje, contam com ótimas ferramentas para construir aplicações estáticas.

Todos estes pontos tem suas soluções, ou ao menos terão suas soluções. A comunidade do Flutter tem crescido bastante e há pessoas dedicadas em resolver estes problemas. Já existem muitas outras bibliotecas e alternativas para estes casos, como, por exemplo, o SEO Renderer para resolver qualquer problema com SEO no Flutter.

E qual o veredito?

De fato, o Flutter Web ainda tem muito a evoluir. O Flutter ainda é um framework em evolução, e isso é bom. A cada nova versão, novas features e melhorias vem surgindo, deixando o Flutter cada vez mais interessante.

Mas apesar de falar que ainda tem muito a evoluir, o que temos presente hoje, no Flutter Web, vale muito a pena! Tudo tem funcionado muito bem e cumpre com as expectativas. É uma ótima alternativa para você que quer expandir um pouco mais os seus conhecimentos.

Ainda repito, se você quer que o seu projeto escale, que tenha aplicações em diferentes plataformas, do Web ao Mobile, do Smart Watchs ao ainda nem lançado Apple Vision, o Flutter é a solução ideal.

E você, o que acha de Flutter? Participe do nosso canal do Discord e conte pra gente!

Vamos primeiro entender, o que de fato aconteceu. Realmente tivemos uma época que o mercado de TI estava extremamente acontecido, e precisando de muitos desenvolvedores. Era pandemia, o mundo estava em lockdown. Para sobreviverem, muitas empresas precisaram passar por um processo de transformação digital e assim surgiu a necessidade de contratarem desenvolvedores para criarem seus sites e aplicativos. Ao mesmo tempo, muitas pessoas haviam perdido o emprego por não conseguirem mais trabalhar presencialmente e trabalho de desenvolvedor era muito atrativo, até porque, durante a pandemia, foi uma das poucas profissões que não entraram em crise por não conseguir trabalhar presencialmente e você poderia trabalhar tranquilamente de casa, ganhando consideravelmente bem ao comparar com outras profissões.

Foi a partir deste cenário que surgiram as promessas: “em 6 meses você estará ganhando R$5.000”. Você está precisando de um emprego e com 6 meses de curso já começar ganhando mais que a maioria dos brasileiros, sem precisar passar por uma faculdade, e ainda trabalhando confortavelmente de casa? É claro que isso vai chamar a atenção, e milhares de pessoas vão querer virar desenvolvedor. E foi isso que muitos fizeram: largaram todos seus anos de carreira, mudaram todo seu planejamento, pagaram por alguns cursos e esperavam serem contratados. Felizmente, as empresas também precisavam de programadores para construírem seus sites e aplicativos e enfim entrarem no mundo digital. Então por muito tempo houve uma demanda muito grande, uma oferta muito grande, e a promessa até se cumpria —claro que, com menos exagero de um marketing irresponsável, mas que ainda era muito vantajoso.

Hoje a situação mudou bastante. Não há mais pandemia e lockdown, a transformação digital consegue seguir sem tanta urgência, em um ritmo bom, mas já menos acelerado do que a alguns anos atrás, e os investimentos em TI são menores. Tivemos uma série de layoffs, em grandes empresas de TI, e várias pessoas acabaram por ficar sem conseguir mais nenhuma vaga de desenvolvimento. A demanda diminuiu, mas a oferta de desenvolvedores ainda continua grande. E ainda assim, o marketing dos cursos, e as promessas da carreira de desenvolvedor continuam. Então a pergunta, ainda vale a pena virar desenvolvedor?

Para responder, primeiro temos que desmistificar a carreira de desenvolvedor. Independente do mercado não estar mais tão aquecido, ainda há boas oportunidades? Sim. É uma carreira de fácil acesso? Sim. Consigo virar um desenvolvedor em 6 meses? Não.

A verdade sobre ser desenvolvedor é que não, não é para todo mundo. Diversos cursos se apresentaram assim, de forma bastante desonesta, como se qualquer pessoa pudesse se tornar um desenvolvedor, mas não é bem assim na realidade. Para ser um desenvolvedor precisa de muita dedicação, muito estudo e muita insistência, e isso qualquer um pode ter, mas o principal para se tornar desenvolvedor é gostar de ser desenvolvedor.

Desenvolver não é um trabalho fácil. São problemas extremamente complexos e cansativos de serem resolvidos, pressão para entregas rápidas, mas com qualidade, e uma constante necessidade de estudos não só para se destacar no mercado, mas até para se manter vivo no mercado. E não é um curso de 6 meses que vai te preparar isso. São anos de estudo e prática com código, é a sua afinidade com tecnologias, é sua curiosidade em não só descobrir o que há por trás de um aplicativo, mas de realmente aprender a construir outro até melhor.

O que aconteceu é que entraram muitas pessoas no mercado ao ver uma oportunidade tão boa quanto essa, mas que não conseguiram se adaptar ao que o mercado realmente precisa. Hoje, as vagas estão realmente diminuíram, mas o mercado ainda precisa de desenvolvedores. Há um enorme buraco nas empresas de TI onde ainda há muito o que ser feito, mas que faltam pessoas com a vontade de cair de cabeça na área. As empresas não querem mais se encher de desenvolvedores em números, mas com pouca qualidade em solução de problemas. Hoje, a real dificuldade é encontrar desenvolvedores que realmente gostam do que fazem e que estão preparados para encarar os desafios de trabalhar com desenvolvimento de software.

Entender que ser desenvolvedor não é um conto de fadas é o primeiro passo. E se você tiver disposto a seguir neste caminho, então, sim, ainda vale a pena ser desenvolvedor.

Desenvolvedor

Este é o caminho mais comum, e geralmente, pode onde todos nós começamos.

Um desenvolvedor é aquele que trabalha diretamente escrevendo os códigos e projetando as aplicações que irão para o consumidor final, seja essa aplicação uma API, um sistema interno, ou até mesmo um aplicativo, ou página na web. E é a partir dessas diferentes aplicações que surgem diferentes caminhos para alguém que quer ser desenvolvedor:

Desenvolvedor Backend

Este é o clássico desenvolvedor. Um trabalho que envolve muito código e muita lógica de programação.

No backend fica tudo o que “não é visto” no sistema. Você desenvolve tudo que está por trás do que acontece.

Um desenvolvedor backend trabalha com o próprio sistema, desenvolvendo funcionalidades e integrando serviços para a aplicação.

Desenvolvedor Frontend

É assim que é chamado os desenvolvedores especializados em trabalhar na interface de uma aplicação.

Trabalhar com frontend é bem diferente de trabalhar com backend, por exemplo. Muitas vezes, por mais que se trate até da mesma linguagem de programação, a sintaxe e o método de desenvolvimento podem ser bastante diferentes de um desenvolvimento backend.

É um trabalho que exige bastante atenção e cuidado com os detalhes e a experiência do usuário afinal, você estará cuidando da principal forma de contato do cliente com sua aplicação!

Desenvolvedor mobile

Da mesma forma que um desenvolvedor frontend, um desenvolvedor mobile também é especialista em criar a interface da aplicação. Mas neste caso, é com foco na interface para aplicativos no celular.

Desenvolver para mobile é tão diferente, utilizando até mesmo nas linguagens de programação ou na experiência que se deseja repassar ao usuário que é necessário uma área especial para desenvolvedores focados em desenvolvimento de aplicativos.

Desenvolvedor Fullstack

Ser um desenvolvedor fullstack é para quem gosta de estar envolvido em todas as etapas de um projeto. Backend, frontend, e até mobile um fullstack consegue dar conta de tudo.

Geralmente se trabalha dessa forma quando se há mais experiência e mais tempo de mercado, afinal, você vai precisar do conhecimento de diversas áreas diferentes

Devops e Infraestutura

Existe outro caminho para quem quer ser bastante técnico, mas trabalhar com algo um pouco diferente do código: devops e infraestutura.

São estes os profissionais que cuidam de manter toda a operação de pé, gerenciando os servidores e criando rotinas de desenvolvimento para facilitar a integração do código com a máquina propriamente dita.

São os responsáveis por toda a base de um projeto, afinal, sem um bom devops, sua aplicação pode ficar completamente fora do ar.

QAs

Conhece o trabalho de um QA? Sem eles, o seu projeto pode estar em total risco. Os QAs são os Qualitys Assurence, responsáveis pelo teste e pela garantia de qualidade da sua aplicação.

Eles geralmente tem conhecimento sobre código e sobre sistemas, afinal, precisa conhecer como tudo funciona para explorar as vulnerabilidades do sistema. E não só sobre código, também é importante conhecerem sobre experiência do usuário e desenvolvimento de interfaces para poderem avaliar se o produto final, o aplicativo que estará na mão do cliente, irá se portar bem, não só longe de bugs, mas que funcione de uma forma agradável e intuitiva para o cliente

Product Owners

Apesar de estar longe do código, ser PO é um ótimo caminho para quem quer entrar na TI. Os products owners são os responsáveis por cuidar e gerenciar o projeto.

Para ser um PO você precisa ser bastante organizado, saber lidar com pessoas, e ter sangue-frio para tomar decisões importantes para o projeto. São pessoas que também tem um conhecimento técnico, apesar de como disse, estarem longe do código, afinal, estão em constante contato com o time de desenvolvimento.

Lideres

Este é um caminho bem interessante para quem quer estar na TI. Trata-se até de uma evolução de todos os outros caminhos.

Um líder precisa de um pouco de conhecimento de cada etapa, mas até porque, cada área do desenvolvimento de um projeto precisa de um líder. E muito mais do que ter esse conhecimento, o líder deve conseguir espalhar este conhecimento e gerenciar e organizar cada etapa junto aos times específico para que se tenha um bom projeto entregue.

Estes são alguns dos caminhos que você pode seguir entrando na área de TI. Por onde você deseja entrar ou por qual caminho já está atuando? Participe do nosso canal do Discord e conte para gente!

Comunicação

Como desenvolvedor, você precisa conseguir expressar as suas ideias e soluções de forma compreensível e didática, até mesmo para seus colegas e principalmente para seus clientes e também entender bem a necessidade do seu cliente.

A comunicação é forma em que você apresenta o seu trabalho. Do que adianta ser bom em um trabalho se não conseguir se comunicar?

Organização

No dia a dia como desenvolvedor de software recebemos diversas demandas, de projetos ou serviços diferentes, e as informações seja sobre o código ou a regra de negócio são diversas, e isso, quando não há mais de uma demanda.

Aquele que consegue não só entender o que deve ser feito, mas documenta bem a sua entrega e organiza bem o seu tempo e entende seus prazos com certeza tem destaque no mercado.

Um bom desenvolvedor consegue gerenciar bem as suas demandas, saber definir suas metas e objetivos, e principalmente suas prioridades.

Trabalho em equipe

Você dificilmente irá trabalhar sozinho em um código. A colaboração em um projeto, a contribuição em discussões técnicas principalmente o ouvir e escutar um colega são habilidades essenciais para um desenvolvedor.

Um bom trabalho em equipe também fornece troca de experiências e agrega em conhecimento para você mesmo. É o famoso networking tão importante na construção de uma carreira.

Pense também que essa é sua equipe e você estará sempre em contato com eles. Nada melhor do que construir uma boa relação, não acha?

Resolução de problemas

Este é o seu verdadeiro trabalho. No dia a dia de um desenvolvedor diversos problemas irão surgir e você precisará resolvê-los.

Identificar um problema, analisá-lo de forma precisa e propor uma solução realmente eficiente é uma habilidade extremamente importante para qualquer desenvolvedor.

Saiba também como lidar com estes problemas. Evitar frustrações, saber quando pedir ajuda, e trabalhar mantendo sempre uma boa autoestima é fundamental até mesmo para conseguir resolver os problemas de fato.

Adaptação

Em desenvolvimento tudo está sempre mudando, e precisamos estar preparados para essas mudanças. Tecnologias estão sempre mudando, frameworks estão trazendo novos recursos. O que é bom hoje, amanhã, pode não mais ser.

É essencial para um desenvolvedor conseguir se adaptar bem a essas mudanças, e encará-las como novas oportunidades de crescimento. Um desenvolvedor nunca pode ficar parado.

Essas são algumas das softskills mais importantes para um desenvolvedor, mas com certeza, há diversas outras habilidades que você pode trabalhar para se destacar na sua carreira. O que mais você trabalha, além do técnico, para conseguir evoluir como desenvolvedor? Participe do nosso canal do Discord e conte pra gente.

O que é um boilerplate?

Sempre que você começa um novo projeto, você repete o mesmo processo, certo? Por exemplo: instala o React, configura o NextJS, adiciona alguma biblioteca UI, prepara o gerenciador de estados, prepara aqueles mesmos componentes que você sempre usa em todo o projeto. Você não precisa ficar sempre fazendo isso, basta ter um boilerplate.

Um boilerplate é um “pré-projeto”, um conjunto de código que você já deixa pronto para ser reutilizado em algum novo projeto. É como se fosse um template, que já está ali todo configurado para que você possa começar uma nova aplicação se preocupando apenas com as funcionalidades daquela nova aplicação.

Por que ter um boilerplate?

Pense na economia de tempo. Não precisa sempre reconstruir aquela mesma estrutura. Se você tem um novo projeto, recebeu uma nova demanda, basta utilizar o boilerplate e rapidamente o seu projeto estará de pé e pronto para desenvolvimento.

Para atualizar seus projetos, seja na correção de um bug ou na atualização de um pacote, é ótimo ter um boilerplate presente. Basta atualizar o próprio boilerplate, e os projetos seguirão na mesma linha.

Além disso, é ótimo para ter projetos bem padronizados. Em seu time, é importante que todos os projetos passem por um mesmo caminho, facilitando até mesmo a adaptação de um projeto para outro, afinal, a base do código é praticamente a mesma devido ao uso do boillerplate.

Mas o verdadeiro motivo, é porque você precisa aprender a construir um boilerplate.

O que posso aprender construindo um boilerplate?

Construir um boilerplate é um ótimo estudo. É literalmente, um exercício para trabalhar diferentes habilidades de desenvolvimento.

Pense bem: um boilerplate precisa ser consistente, ter um certo padrão de código que te acompanhe durante diferentes projetos. Para desenvolver algo assim, você precisa estar preparado para prever e planejar um código que consiga transitar em diferentes projetos e serviços, trabalhando bastante com reutilização de código e melhores práticas de programação com arquiteturas flexíveis para que o seu boilerplate seja realmente dinâmico. E claro, isso não é tão simples quanto parece.

Se você tem um bom boilerplate, já é um bom sinal de que é um bom programador.

E você? Já tem um boilerplate no seu portifólio? Utiliza nos seus projetos? Compartilhe com a gente em nosso canal do Discord!

O que é escalabilidade?

Sua aplicação consegue se adaptar conforme a demanda, quantidade de acesso, volume de dados que recebe? Pois isso que é escalabilidade.

Durante o desenvolvimento, pouco nos preocupamos com escalabilidade, afinal, no seu computador o código está rodando bem, estável, sem travamentos e tudo parece funcionar muito bem. Isso pode até funcionar quando estiver em produção, com 10 ou 100 pessoas acessando sua aplicação, mas de acordo com a evolução do seu produto e o crescimento de volume isso pode mudar bastante.

É sempre importante que seu projeto consiga suportar a um grande trafego de usuários na sua aplicação ou a uma operação complexa que exija mais do sistema, sem prejudicar o desempenho da aplicação ou até mesmo causar uma queda no serviço.

Como escalar uma aplicação?

Imagine o seu próprio computador, com várias abas do Chrome abertas. O seu PC vai ficar extremamente lento, isso se não causar uma tela azul, certo? O que você faz nessa situação? Fecha abas desnecessárias que você não está usando, ou até mesmo, trocar para um navegador que performa melhor. Podemos aplicar este mesmo exemplo na sua aplicação: se está lento demais, melhore os processos do seu sistema, optimize o seu código e use tecnologias mais leves e rápidas para sua aplicação.

Mas você é um usuário que precisa mesmo de várias abas abertas no Chrome. Qual a solução? Aumentar a memória do seu computador. Isso também é válido para desenvolvimento de software, e se chama escalabilidade vertical. Você pode melhorar sua aplicação com um servidor mais potente, que consiga processar melhor o seu código e que consiga lidar com uma demanda maior.

Ainda assim, existe um limite certo? Não importa o quanto você melhore seus processos, ou tenha um servidor poderoso, se o trafego da sua aplicação ainda for alto você pode sofrer com os mesmos problemas de instabilidade e performance. Bom, nesta solução, você não conseguiria aplicar para resolver suas abas do Chrome, mas existe algo bem interessante em desenvolvimento de software chamado de escalabilidade horizontal: se um computador, por melhor que seja, está sofrendo com o número de demandas, que tal usar 2, 3 ou 10 computadores e distribuir essa carga? Com tecnologias em nuvem, isso não só é extremamente possível como é bastante popular.

O que grandes apps fazem?

Na prática, as grandes aplicações já usam e já são desenvolvidas pensando escalabilidade e por padrão já usam algumas técnicas e soluções bastante comuns para resolverem seus problemas:

• Uma arquitetura distribuída em microserviços, em que diversas aplicações dividem suas responsabilidades de forma independente, equilibrando os processos, conforme a demanda de cada específico serviço.

• Uso de cache em diversas pontas da aplicação. Porque reprocessar os dados, se já sabemos que o resultado será o mesmo de alguns minutos atrás? Utilizar o cache em situações como essa diminui bastante o processamento de seu servidor, diminuindo o custo, e abrindo mais espaço para um tráfego maior.

• Dimensionamento de servidores de forma horizontal, acrescentando máquinas e instâncias e balanceando o trafego em diferentes serviços para equilibrar as demandas e processamento do sistema.

• Infraestrutura voltada a nuvem, como AWS, Google Cloud ou Azure que já trazem serviços de escalonamento automático, de acordo com a demanda recebida na aplicação.

• Implementação de técnicas de observabilidade e monitoramento para justamente saber onde, e o que melhorar no seu sistema.

Essas são algumas das soluções mais comuns aplicadas em grandes apps. Assim como o próprio conceito de escalabilidade, que preza pela adaptação, as estratégias de escalabilidade devem também ser adaptadas segundo a necessidade do seu sistema.

Com estes conceitos, esteja sempre atento, e já construa sua aplicação pensando na escalabilidade do seu projeto. Um bom código é aquele que sempre funciona, não importa a quantidade de pessoas acessando, não importa a complexidade do processo, não importa o trafego de dados. E se você quer ter um bom código e principalmente um bom produto, escalabilidade é fundamental.

O que é um monorepositório?

Hoje em dia estamos acostumados a desenvolver uma API, e desenvolver uma interface em projetos e repositórios separados —backend e frontend. Mas, a depender do projeto, ou da tecnologia, existe a possibilidade de desenvolver tudo em um único projeto, sem essa divisão de backend e frontend. Isso é tal do “monorepositório”.

Com apenas um repositório você terá uma facilidade maior de manuntenção e o código fica mais visível e acessível durante o desenvolvimento. É interessante para quem está começando com programação e fica bem legal quando é um pequeno projeto, ou algum estudo ou experimentação de tecnologia que você está fazendo.

Usar monorepositório é uma boa prática?

Sendo bastante sincero, existe um motivo para monorepositórios não serem mais tão populares.

Dividir seu projeto, em diferentes repositórios e códigos, não só pode adicionar uma boa camada de segurança, como também melhora a divisão de responsabilidades em uma aplicação, e isso sim é uma boa prática de programação.

Ter tudo em um único lugar torna seu projeto um “monstro”. Por mais que até certo nível seja até amigável quanto mais o seu projeto cresce, essa junção de responsabilidades torna o seu código extremamente complexo, e até dificulta a manutenção —que deveria ser um dos pontos positivos de um projeto com monorepositório.

Hoje em dia, quando discutimos bastante monolitos e microserviços, digo que utilizar um monorepositório é até contra intuitivo.

Como está voltando aos holofotes?

A algum tempo atrás eram assim que sites e aplicações funcionavam, backend e frontend todos em um mesmo código. Projetos em monorepositórios chegaram ser bastante populares, principalmente no “boom” do PHP.

Hoje, o monorepositório volta a discussão pois tecnologias mais recentes, como o React e o framework NextJS, estão trazendo um novo recurso de “Server Actions” que permite trazer funções hoje já bastante comuns ao backend, como uma conexão ao banco de dados, para o mesmo repositório que estão seus componentes em React.

Olha só um componente React chamando uma função que insere um dado em um banco de dados:

import db from './db';
import { redirect } from 'next/navigation';

async function create(formData: FormData) {
  'use server';
  const post = await db.post.insert({
    title: formData.get('title'),
    content: formData.get('content'),
  });
  redirect(`/blog/${post.slug}`);
}

export default function Page() {
  return (
    <form action={create}>
      <input type="text" name="title" />
      <textarea name="content" />
      <button type="submit">Submit</button>
    </form>
  );
}

Todo recurso é útil

Por mais que eu pessoalmente ainda ache estranho, todo recurso é realmente útil. Os benefícios ainda existem, basta sabermos usá-los. Além disso, ainda é um recurso bastante novo em fase Alpha no NextJS, o que mais ainda pode estar por vir até a versão final?

E você? O que acha de Server Actions e de monorepositorios? Participe de nosso canal no Discord e conte pra gente!

Eu te entendo…

São milhares de coisas para você estudar. O mercado de trabalho te pede um framework específico. É claro que você, que está apenas começando neste mundo, iria focar em um framework. É mesmo o jeito mais rápido de conseguir um trabalho. Mas também é o pior jeito. Você vai mesmo ficar refém de um único framework?

Frameworks vem e vão

Houve o tempo em que nem frameworks existiam. Houve o tempo em que uma página na internet era toda feita de tabelas. Houve o tempo em que desenvolvimento frontend era praticamente só CSS, o Bootstrap era bem famoso. O jQuery também tinha o seu espaço garantido. AngularJS surgiu e foi completamente substituído por uma nova versão. No mobile, os frameworks nativas eram até a única solução disponível para criar um aplicativo. Hoje o mundo já é bem diferente. E o que será do React, Vue, Flutter, Nest e Laravel no futuro?

Frameworks vem e vão, mas o conhecimento que você tem na linguagem de programação fica.

Se você sabe bem uma linguagem, vai conseguir trabalhar bem em um framework

Nós já te explicamos o que é um framework, mas nada custa lembrar: framework é um conjunto de funções e ferramentas de uma linguagem de programação estruturadas de uma forma que facilite o seu desenvolvimento. E é isso mesmo, é apenas uma biblioteca de funções que utiliza a mesma linguagem de programação que você tem negligenciado seus estudos.

A lógica é muito simples: se um framework tem como base uma linguagem de programação, basta conhecer bem essa linguagem de programação e você conseguirá utilizar o framework —com uma capacidade até maior do aqueles que se limitam a estudar somente o framework.

O framework ficou decadente, ou surgiu uma opção melhor no mercado? Tudo bem, você ainda terá o conhecimento da linguagem de programação. Por isso, os desenvolvedores que passado desenvolviam bastante com jQuery e foram para os novos frameworks de Javascript, como o próprio React, Vue e Angular. O mesmo vale para os desenvolvedores PHP que se adaptaram extremamente bem do Zend para o Laravel. E se acha que isso é válido somente quando um framework é depreciado pela comunidade, que tal tentar migrar do React para Vue? Como ambos tem a mesma base em Javascript será muito mais fácil!

Estude certo

Você precisa saber onde investir os seus estudos. E a resposta certa, é estudar a linguagem de programação, entender os conceitos, aprender a lógica. Use o framework apenas como um facilitador, afinal, é até esse o objetivo proposto pelos frameworks.

Por aqui na devGo, essa é a nossa metodologia e é assim que trataremos em nossos próximos artigos. Se você quer continuar bem nos estudos, participe de nosso canal no Discord e acompanhe em nossos próximos artigos.

Se você entendeu bem o nosso último texto e está se preparando para ser um bom desenvolvedor, sabe que a entrega é a parte mais importante do seu trabalho, e uma entrega, de fato, é seu projeto estar em produção. E é aqui que de fato o seu projeto começa.

Uma coisa é desenvolver o seu projeto localmente, ou até em um ambiente controlado de teste. Outra coisa é quando usuários começam a usar. Agora, problemas inesperados podem surgir, soluções rápidas precisarão acontecer, e melhorias precisarão serem feitas.

Ter um projeto em produção significa ter responsabilidade constante sobre o produto. É ter uma infraestrutura potente o suficiente para aguentar a demanda de seus usuários; estar atento a bugs e resolver o que for preciso o mais rápido possível e da melhor forma possível; trabalhar em melhorias, e principalmente saber como trabalhar com essas melhorias para o seu projeto.

Confira a infraestrutura de seu projeto

Quando milhares de pessoas acessam seu projeto, tudo pode acontecer: a aplicação ficar lenta, apresentar algum comportamento não esperado e até mesmo ficar completamente fora do ar. Pouco importa se você tem um código bem feito, limpo de bugs e problemas se a infraestrutura não suportar a demanda.

Sua aplicação está disponível na nuvem? Os serviços desenvolvidos são escaláveis? Existem políticas de balanceamento de carga? Existe uma solução para cache? A estrutura é elástica o suficiente para suportar a demanda? Foram feitos testes de sobrecarga para entender até onde a aplicação suporta tudo isso? São essas as perguntas que sempre devemos fazer quando um projeto está entrando em produção.

Não basta até que seu projeto esteja “funcionando”. Em produção o seu projeto funcionar “sempre”.

Monitore o que acontece na aplicação

Acabo de dizer que é importante que seu projeto funcione “sempre”. Mas como saber que está, realmente, sempre funcionando?

Você precisa ter ferramentas de monitoramento e métricas para ser possível identificar possíveis gargalos e problemas com o seu projeto. É importante que você veja se sua aplicação realmente está no ar, se há algum log de erro desconhecido e não tratado acontecendo, se está lento demais e até mesmo se o comportamento do cliente, como vendas, buscas por um produto e taxa de conversão estão de acordo com a proposta de negócio da sua aplicação.

Serviços como Sentry, New Relic, ou até dashboards do Grafana, ou Prometheus podem te ajudar com isso. Com eles é possível monitorar em tempo real, conferir logs, e até ter alertas, relacionados a certas métricas para te chamar atenção a cada possível problema.

Tenha protocolos de deployment

Quem nunca teve medo de subir um código em produção? Errado é quem não tem.

Subir um código em produção significa ter uma mudança imediata no seu produto que pode afetar milhares de clientes ao mesmo tempo. Pode ser uma ótima melhoria para seu projeto, mas também pode ser um comportamento não esperado, um bug, um erro no código que irá acabar com o seu produto.

Versionamento da aplicação, um bom fluxo no Git, testes bem feitos e até automatizados, e até um monitoramento mais preciso pós uma nova versão em produção irão te ajudar. Combine com o seu time estes protocolos, valide bem qualquer alteração no código e principalmente esteja atento.

É agora que o trabalho começa

É somente em produção que entendemos melhor o nosso produto.

É agora que começamos a ver como realmente é o nosso produto, se os usuários se comportam como o esperado, se os usuários sentem falta de algum recurso importante e até se o produto foi mesmo bem desenvolvido.

Uma aplicação nunca deixa de ser desenvolvida, sempre precisa de melhorias, de refinamento, de novos recursos. O produto sempre precisa evoluir. E é aí que o seu trabalho realmente começa.

Em produção, você terá um mundo de oportunidades para mostrar o seu trabalho.

Participar de um grande projeto, ser especialista em uma linguagem de programação ou framework, liderar outros desenvolvedores, formar novos programadores. Há diversos caminhos para se considerar um bom desenvolvedor, mas no geral, existem importantes pontos que te valorizam e te destacam entre tantos outros desenvolvedores, aumentando de forma considerável o seu valor no mercado.

Hoje vamos discutir o que você deve trabalhar para ser um ótimo desenvolvedor.

Além de ser um técnico

Já comentamos por aqui diversas vezes: ser um bom desenvolvedor, vai muito além do técnico. Não tiro a importância de você conhecer bem uma linguagem, saber trabalhar bem em um framework e ser especialista em determinada ferramenta. É claro que estes são pontos indispensáveis para que você se torne um bom desenvolvedor.

Mas para ser um bom desenvolvedor, você precisa de um diferencial, e este diferencial vai muito além do técnico. Trata-se muito mais do valor que você consegue agregar, e da forma que você trabalha para atingir o seu valor.

É importante que você, como desenvolvedor, consiga ir além do ser um bom técnico, e é justamente nestes pontos que iremos focar.

Ser desenvolvedor é resolver problemas

Vamos primeiro entender o verdadeiro objetivo do trabalho de um desenvolvedor: resolver problemas. Um desenvolvedor é aquele que cria um código, desenvolve uma aplicação, constrói um programa a fim de resolver o problema de alguém ou de alguma empresa. E é por isso que este deve ser o seu foco.

No mercado, desenvolvedores são contratados, pois empresas estão com um determinado desafio que precisa ser resolvido.

Um ótimo exemplo de um caso como este foi durante a pandemia: empresas que funcionavam apenas ficaram fisicamente limitadas com o lockdown, precisando então recorrer a algum outro recurso para atingir as metas de seus produtos. Essa solução foi uma grande transformação digital nas empresas, com sites, ecommerces e aplicativos e para isso, desenvolvedores precisaram ser contratados.

Pois bem, se você foi contratado para resolver um determinado problema, tenha como foco desenvolver este determinado problema. E lembre que por muitas vezes, isso exigirá que você pense muito além do seu desenvolvimento, pense nas suas entregas!

Pense no valor de suas entregas

Com o mesmo exemplo de que durante a pandemia, empresas passaram por uma grande mudança e produtos digitais precisaram ser desenvolvidos, vamos pensar em como este momento poderia ter afetado o seu trabalho.

Pense que durante este tempo, não só o seu cliente ou a sua empresa precisavam desta transformação. Pense também, que este foi um tempo limitado e que, por exemplo, hoje, as empresas já podem atuar fisicamente como sempre atuaram.

Naquele momento, o que as empresas precisavam era de uma solução rápida, uma transformação “imediata”, que as tirassem da crise o mais rápido possível, e até mesmo antes de seus concorrentes, para que assim dominassem o vazio do mercado criado pela pandemia. Se você foi um desenvolvedor que entendeu este recado e conseguiu desenvolver um produto rápido o suficiente para isso, tenho certeza que está colhendo os frutos desta entrega hoje.

Para uma empresa não basta apenas ter um produto desenvolvido, até porque, o problema para a empresa não é “não ter um produto digital”, e sim “vender mais” e “dominar o mercado”. A grande questão é: o que você irá fazer para que o seu desenvolvimento resolva este problema? Qual vai ser o seu diferencial?

Sair do lado técnico para entender o mercado e suas necessidades é justamente o que pode aumentar o valor de suas entregas. E lembre-se, o valor de suas entregas é o seu valor como desenvolvedor.

Seja um líder

Se você além de ter qualidade técnica, entende o seu objetivo como desenvolvedor e principalmente entende o valor de suas entregas, porque não passar isso adiante?

Para uma empresa, melhor do que ter uma única pessoa que entende o que faz um bom desenvolvedor é ter 5 pessoas que entendem o que faz um bom desenvolvedor. E se você, é alguém que consegue passar o conhecimento e experiência que você adquiriu para outros desenvolvedores, tenha a certeza de que será bem valorizado.

Não se trata de uma concorrência, em que você precisa competir para ser um bom desenvolvedor, muito pelo contrário. Se trata de um crescimento exponencial. Se você consegue formar outros bons desenvolvedores, você expande todo o seu alcance: as entregas de seus liderados passam a ser a sua entrega, o valor de seus liderados para a ser somados ao seu valor.

Seja a referência do seu projeto, trabalhe de forma para compartilhar o seu conhecimento e experiência entre seus desenvolvedores. É sendo um líder que você aumenta o seu valor.

Compartilhe suas experiências

Importante neste processo é o compartilhamento de experiências. Por mais que você esteja começando agora, ou já seja um desenvolvedor experiente, um líder e já realmente considerado um “bom desenvolvedor” esteja sempre disposto a compartilhar e principalmente a ouvir outras experiências.

E é até mesmo com este intuito que a devGo foi criada. Estamos em nosso canal no Discord, abertos para novos temas e novas discussões, sempre pensando em nossa evolução pessoal.

Você já participa de nosso canal do Discord? Apareça por lá e nos conte mais sobre sua trajetória.

ChatGPT é uma inteligência artificial criada pela OpenAI que está bem famosa por responder tão bem as perguntas de forma objetiva e direta. Muitos já dizem que é uma nova geração para ferramentas de pesquisa e que pode substituir até mesmo o Google.

Nós sabemos bem: que programador vive sem o Google? E não tem problema nenhum com isso. As vezes precisamos mesmo procurar uma resposta, descobrir como funciona uma biblioteca, procurar o que é aquele maldito bug que você não consegue resolver.

Com uma evolução pra o ChatGPT tudo fica mais fácil. Podemos ter a resposta diretamente em código, com uma solução pronta para nossos problemas.

Peça para te introduzir a um tema

Que tal ter um resumo, bastante completo até, do que é o novo tema que você está estudando? O ChatGPT é ótimo para te introduzir a um assunto, trazendo o funcionamento de forma bem detalhada. Olha só o retorno quando pergunto sobre Test Driven Design:

Peça guias de estudo

Além de um resumo sobre o tema, o ChatGPT pode te dar um guia bem completo para você estudar o assunto, com recomendações de onde você pode estudar:

Peça solução para um erro de código

Quem nunca passou horas e horas procurando a solução de erro? Pois o ChatGPT consegue te dar uma explicação exata do motivo desse erro, e como você pode resolver

Peça ajuda para desenvolver uma pequena função

Faz parte, as vezes precisamos de alguma ajudinha para desenvolver uma pequena função, e o ChatGPT consegue te entregar isso

Bem interessante não? E você, já usa alguma ferramenta com inteligência artificial para te ajudar no código? Conta pra gente em nosso canal do Discord!

Nossa profissão como desenvolvedor naturalmente traz algumas particularidades em comparação com outras atividades: é “rápido” se tornar um desenvolvedor. Muitos já dizem que não precisa de graduação para atuar com desenvolvimento e vemos muitos cursos e bootcamps que prometem te preparar para toda jornada de desenvolvimento com pouquíssimo tempo de estudo. Enquanto isso, temos desenvolvedores de longa data que precisam se readaptar completamente a uma tecnologia que acabou de surgir no mercado. No meio dessa confusão, como definir o que é um desenvolvedor júnior, um pleno e um sênior?

Júnior, Pleno e Sênior

Primeiramente vamos entender, em um conceito geral, o que é um júnior, um pleno e um sênior.

O senso comum diz que essa definição vêm conforme o tempo em que você está no mercado de trabalho: júnior até 5 anos no mercado, pleno até 10 anos, e sênior de 10 em diante. Outra forma de definir o que é júnior, pleno e sênior é comparando a produtividade: o júnior é alguém iniciante, que está começando agora com desenvolvimento e ainda precisa de bastante ajuda; o pleno é alguém que consegue entregar demandas de forma independente, e dá conta de resolver sozinho; o sênior é aquele que não só consegue resolver as demandas, mas sabe o que está fazendo e consegue repassar este conhecimento ao júnior e ao pleno.

Na prática, essas duas definições podem se contradizer bastante. Vemos desenvolvedores sêniores com 3-4 anos de experiência e, enquanto vemos desenvolvedores com anos no mercado de trabalho para que não conseguem entregar uma simples demanda porque está trabalhando com uma nova tecnologia.

Temos que considerar que ser desenvolvedor difere de qualquer outra profissão. Temos uma profissão que é relativamente fácil entrar no mercado, quando comparada as outras; ao mesmo tempo, tudo está mudando a todo tempo, daqui a 5 anos a tecnologia que você trabalha não ser mais relevante para o mercado. Pode ser bem capaz alguém com pouquíssimo tempo de experiência conhecer bem mais de uma tecnologia do que alguém com anos de experiência. E pensando assim, é realmente difícil definir o que é ser um Júnior, um pleno ou um sênior.

A experiência é, sim, importante

Mas calma, é claro que a experiência é importante. Alguém com 10 anos no mercado indiscutivelmente vai ter mais conhecimento do que alguém com 2 anos de trabalho como desenvolvedor.

As situações, os diferentes problemas encarados durante os anos que se passam trabalhando como desenvolvedor sempre terão muito valor, independente da tecnologia.

Como já disse em alguns outros textos aqui na devGo, desenvolver e programar é muito mais do que código. Trata-se de conceitos, de lógica e de entendimento do que há por trás do código. Uma nova linguagem de programação ou um novo framework jamais irá te tirar do mercado, e seus conhecimentos e experiência sempre serão úteis.

Por que se limitar a um nível?

Precisamos entender que é, sim, possível que alguém com anos de experiência, que conheça todos os conceitos e tenha toda a lógica trabalhada por anos simplesmente não se adapte a nova tecnologia ou novo método de trabalho. Alguém, iniciante e bastante dedicado, poderia muito bem superar as habilidades e conseguir entregar tão bem quanto um desenvolvedor de anos atrás.

Ao contratar alguém, por exemplo, o meu grande ponto de importância é o comprometimento e autoconfiança. É claro que vou analisar o código, buscar qualidades diferentes a depender do nível proposto na vaga, mas ao ser uma pessoa comprometida e esforçada poderia muito bem abandonar estes conceitos pré-definidos de Júnior, pleno e sênior.

A grande questão, por aqui, é porque limitar pessoas a uma “etiqueta”. Não que devemos desconsiderar conhecimento, estudo e experiência, mas sim estarmos abertos a novas possibilidades, afinal podemos sempre ser surpreendidos.

E você, como você vê os juniores, os plenos e os sêniores em desenvolvimento? Participe do nosso canal do Discord e conte para gente!

O que é uma Web View?

Um Web View é como se você abrisse um navegador dentro do seu aplicativo, e utilizasse a página por ali mesmo. Parece muito com um <iframe>, que temos no HTML, mas para aplicações nativas de um celular.

O usuário se mantém no aplicativo, mas, na verdade, acessa uma aplicação web, completamente independente desta aplicação móbile.

Quais são minhas opções de desenvolvimento?

Não sendo um Web View podemos usar a opção mais padrão e natural de construir um novo aplicativo.

A partir daí temos várias opções: Flutter, Swift, Kotlin, React Native e tantas outras, que devem ser analisadas individualmente da forma que melhor te agrade, ou seja, boa para o seu negócio, tal qual uma escolha de linguagem de programação ou framework a ser utilizado no projeto.

Vale a pena?

“Tenho minha página web, responsiva, e funciona muito bem no celular. Porque então desenvolver um aplicativo e manter esse aplicativo, para fazer a mesma coisa?”.

Este é um argumento que de início faz bastante sentido. Você realmente pode economizar tempo de desenvolvimento e recursos de uma equipe para desenvolver um aplicativo. A manutenção do aplicativo é mais fácil, visto que é preciso trabalhar somente na versão web.

Mas existe um motivo pelo qual grandes empresas não usam Web View em seus aplicativos:

As lojas Google Play e AppStore não recomendam

As duas maiores lojas de aplicativo, para Android e iOS, respectivamente, não recomendam aplicativos feitos somente com WebView.

Por não poderem garantir a segurança de aplicativos feitos a partir de Web View a seus usuários, as lojas tendem a até mesmo não aceitar a publicação dos aplicativos, e deixam isso bastante em claro nas documentações:

O Google Play diz:

“Your app must not merely provide a webview of a website or have a primary purpose of driving affiliate traffic to a website, regardless of ownership of the website.”

A Apple Store também:

“Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store”

Construir então um aplicativo com base em uma Web View pode ser bastante perigoso, afinal, ninguém quer correr o risco de seu aplicativo sair da loja de uma hora para outra.

Bugs acontecem

Um Web View não é o mesmo que o navegador do seu celular.

Lembram do finado Internet Explorer? Programávamos o site, estava tudo certo, funcionando 100%, mas era abrir a página no Explorer e estava toda quebrada. Acontece bem parecido em um Web View.

Por mais que seja mais rápido simplesmente trazer sua página para dentro do app em um web view, bugs inesperados podem acontecer, e quebras imprevisiveis na sua página podem estar presentes. Tratar esses bugs podem ser uma experiência bastante descontrolada, pois perdemos referência do que acontece na página justamente por se tratar de um Web View.

Experiência do usuário

Um Web View ainda não é um aplicativo.

Desenvolver para web e desenvolver para aplicativo são coisas bem diferentes, justamente por se tratarem de ambientes completamente diferentes. Deve ser visto que um Web View é apenas uma “simulação” de uma página na web. Da mesma forma que bugs podem acontecer, a experiência do usuário também não é a mesma.

Quando se constrói um aplicativo, as próprias ferramentas e frameworks utilizados são optimizados para funcionamento dentro de um ambiente mobile. É muito mais fluído, a perfomance é muito melhor, e trazem ao usuário a mesma experiência que ele tem ao utilizar seu dispositivo naturalmente.

Este é até o grande diferencial de um aplicativo: a experiência do usuário. Por mais que pareçam pequenos detalhes, na prática, isso é uma grande diferença para o usuário. Uma boa experiência do usuário: trás mais confiança no seu produto, mantém o usuário por mais tempo na aplicação, e consequentemente gera uma conversão melhor.

Então, quando usar uma Web View?

Geralmente utilizamos Web View em conteúdos “estáticos” que trazem informação importante ao usuário e deve ser mantida sempre atualizada, como, por exemplo, uma página de política de privacidade. Este, sim, é um exemplo seguro de uso para uma Web View.

Mas, é claro que construir um app é custoso. Se trata mesmo de uma aplicação completamente nova, portanto, assim como tudo em desenvolvimento de software, deve-se sempre pensar no custo benefício. Seu projeto está disposto a aceitar os riscos? O quão importante é atrair o cliente para o seu produto? São essas as reais perguntas que devem ser feitas durante a escolha de desenvolvimento com Web View ou um App Nativo.

Quer discutir um pouco mais esse caso com a gente? Participe do nosso canal do Discord e acompanhe nossos conteúdos!

Considerações iniciais

• Os passos necessários para a execução dos testes de validação, bem como a preparação do ambiente para tal, serão descritos da maneira mais clara possível para que mesmo um iniciante consiga acompanhar e reproduzir os resultados sem dificuldades, mas é esperado o mínimo de familiaridade com o Postman, pois este texto foi escrito partindo da suposição de que algumas funcionalidades básicas e uma visão geral do software já são conhecidos.

• O Postman possui duas bibliotecas integradas para a realização das validações: tv4 (Tiny Validator for v4 JSON Schema) e Ajv (Another JSON Schema Validator). Apesar de a documentação oficial do Postman utilizar a tv4 nos exemplos, esta não é mais mantida desde 2017, e seu uso, portanto, não é recomendado.

• É importante se orientar de modo a sempre buscar testar para as falhas primeiro para ter certeza de que a validação funciona da maneira correta (para cada cenário a ser testado, garante-se que o teste irá falhar propositalmente em um primeiro momento para, então, seguir com a validação). Isso garante a confiabilidade do teste, afinal, se este não falha em nenhum cenário, como se pode ter certeza se o que passa é realmente válido?

• Pratique um pouco com schemas gerados manualmente, pelo menos no começo. Deixe para utilizar geradores automáticos, como o https://jsonschema.net, quando já possuir um melhor entendimento da estrutura típica de um schema e suas regras, e precisar lidar com schemas longos e complexos. Dessa forma, o arquivo gerado não vai lhe parecer confuso e você será capaz de fazer intervenções quando necessário, garantindo a qualidade dos testes, pois saberá exatamente o que cada coisa faz.

Preparação do ambiente

Antes de mais nada, vamos criar uma coleção, definir as variáveis de ambiente, gerar um exemplo e criar um mock de servidor para realizar os testes iniciais.

Coleção (collection)

Coleções são “pastas” que possibilitam o armazenamento de requisições, facilitando a organização dos endpoints para agilizar utilizações futuras. No menu lateral do Postman clique em Collections e, em seguida, no botão “+” para adicionar uma nova coleção:

Defina um nome, clique sobre a coleção com o botão direito (ou no menu de 3 pontos), e adicione uma nova requisição do tipo GET em Add request. O endpoint que será será utilizado é:

https://postman-echo.com/get?foo1=bar1&foo2=bar2

Variáveis de ambiente (environment variables)

As variáveis de ambiente, apesar de não serem estritamente necessárias, ajudam no controle dos endpoints a serem testados e agilizam requisições futuras por meio da reutilização de valores. Após configurado, a URL acima pode ser substituída por {{url_API}}, por exemplo. Se a coleção já possuir variáveis definidas, pule esta etapa e prossiga com a criação de exemplos.

Para não estender demais o texto e desviar da sua finalidade principal, acesse mais informações sobre a criação e utilização de variáveis dentro do Postman clicando aqui.

Criando exemplos

No contexto do Postman, exemplos são cenários pré-definidos de requisições e respostas que podem ser editados e utilizados nas simulações de servidor, como veremos mais adiante. A maneira mais fácil de se criar um exemplo é a partir de uma requisição para a API que será testada.

Vamos criar um exemplo para uma requisição do tipo GET. Para isso, basta abrir a coleção, escolher a requisição desejada (no caso, a que foi criada anteriormente) e clicar em Send. Feito isso, clique em Save Response e, em seguida, Save as example.

Automaticamente será aberta uma nova aba com o exemplo recém criado. Note que a tela é bem parecida com a de uma requisição comum, e que as informações apresentadas inicialmente são idênticas àquelas da requisição feita anteriormente:

É possível editar parâmetros, headers e o body, assim como em uma requisição normal. Porém, diferentemente do que ocorre nesta, um exemplo permite que a resposta também seja editada, bem como o código de status da mesma. Com isso, é possível criar cenários controlados - perfeito para a execução de testes - a partir do uso de mocks. Para mais detalhes sobre os exemplos, outras formas de criação e utilizações, clique aqui.

Mock de servidor

A ideia por trás do mock é criar um endpoint para um servidor falso que irá simular o comportamento de uma API real, enviando retornos para as requisições feitas, e é aqui que entram os exemplos citados anteriormente: com base no tipo de requisição feita para o mock, o Postman encontrará um exemplo correspondente e responderá com os dados contidos neste. Desta forma, será possível, quando necessário, modificar tais respostas para forçar situações de erros propositais, por exemplo, garantindo que o teste falhe nos cenários em que espera-se que isso ocorra e seu teste seja confiável. Portanto, para que o mock funcione adequadamente, é necessário que ao menos um exemplo do mesmo tipo da requisição que se deseja fazer tenha sido criado na coleção.

Para criar o mock, selecione Collections, clique no menu de 3 pontos da coleção que deseja simular e, em seguida, selecione Mock collection. É preciso estar logado em uma conta do Postman para criar mocks.

Na tela seguinte, escolha um nome para o mock e confira se a coleção a ser simulada está correta (caso exista mais de uma no seu workspace). Você pode selecionar um ambiente para que o mock use as variáveis ali definidas, onde, posteriormente, poderá incluir a URL do mock. Também é possível optar por salvar automaticamente a URL em uma variável, que será criada em um novo ambiente. Aqui seguirei com a segunda opção, mas sinta-se livre para fazer o que achar melhor. Por fim, clique em Create Mock Server.

Tendo criado o mock, já é possível testá-lo. Abra uma nova aba no Postman. No canto superior direito, selecione o ambiente nomeado tal qual o mock criado e monte a URL para a requisição, substituindo a primeira parte da URL original do endpoint, da seguinte forma:

{{url}}/get?foo1=bar1&foo2=bar2

Onde {{url}} é a variável de ambiente correspondente à URL do mock, gerada automaticamente na etapa de criação deste, e /get?foo1=bar1&foo2=bar2 é o caminho do endpoint original e seus parâmetros. Caso não queira fazer uso da variável de ambiente, ao invés de {{url}} basta inserir a URL do mock diretamente.

Ao enviar a requisição, se tudo tiver sido feito corretamente, será apresentado um retorno. Pode-se notar que a resposta recebida é idêntica àquela enviada pelo endpoint original da API, mas isso é porque este retorno é exatamente aquele criado junto ao exemplo, que ainda não foi alterado. Ou seja, quaisquer modificações feitas (e salvas) lá irão se refletir no mock.

Validação do schema

A primeira coisa a ser feita na validação de um schema JSON é estabelecer a estrutura que o compõe. O ideal aqui é ter acesso à documentação provida, por exemplo, através do Swagger, e copiar o schema disponibilizado. Mas, para fins didáticos, aqui será utilizada como base a própria resposta enviada pela API, de onde ele será extraído manualmente.

{
    "args": {
        "foo1": "bar1",
        "foo2": "bar2"
    },
    "headers": {
        "x-forwarded-proto": "https",
        "x-forwarded-port": "443",
        "host": "postman-echo.com",
        "x-amzn-trace-id": "Root=1-63addcc9-5ab135d701ba98d92efac901",
        "user-agent": "PostmanRuntime/7.30.0",
        "accept": "*/*",
        "postman-token": "8bff98e4-237c-4940-bef8-067b3998dd58",
        "accept-encoding": "gzip, deflate, br",
        "cookie": "sails.sid=s%3AmyxFsngmsAqbFM1FofXwBn3M-TlpbIOf.NjXpy0b07Qp08dIDDeOAy9iK7oh5w6Y%2FhyBpbzM9Z1c"
    },
    "url": "<https://postman-echo.com/get?foo1=bar1&foo2=bar2>"
}

Logo de cara é possível perceber que a resposta é composta de um objeto contendo 3 propriedades, sendo duas delas também do tipo objeto e uma do tipo string. Traduzindo para uma estrutura esquemática, inicialmente temos o seguinte:

const schema = {
    "type": "object",
    "properties": {
        "args": {
            "type": "object"
        },
        "headers": {
            "type": "object"
        },
        "url": {
            "type": "string"
        }
    }
}

No primeiro nível, a raiz, temos a definição da tipagem geral do schema: "type": "object". Em seguida, properties enumera as propriedades contidas no objeto principal e, para cada uma, é declarada sua tipagem, assim como foi feito no nível anterior. Essa é a base inicial do schema, ainda bem simples, mas já é possível realizar os primeiros testes.

Dentro da aba do mock, localize a aba Tests, abaixo da barra de endereços, e declare a variável schema, como feito no exemplo acima. Em seguida, declare a função de teste:

pm.test("Validate schema", () => {
    pm.response.to.have.jsonSchema(schema);
});

Aqui vale abrir um pequeno parêntese para destrinchar a função e entender o que está sendo feito.

De acordo com a documentação do Postman:

O objeto pm contém todas as informações pertencentes ao script que está sendo executado e permite o acesso a uma cópia da requisição que está sendo enviada ou da resposta recebida. Também permite obter e definir variáveis de ambiente e globais.

Portanto, o objeto pm é fundamental na construção de testes, sejam de que tipo for. Dentre as propriedades e métodos associados a este objeto, o primeiro a ser utilizado aqui é o método test, que recebe dois argumentos. O primeiro é uma string, que será usada para identificar o teste em questão. É recomendável escolher um nome claro e autoexplicativo, que facilite o entendimento do que se propõe tal teste (neste exemplo foi usado o nome “Validate schema”). O segundo argumento é uma função onde o teste em si será especificado. No caso do nosso exemplo, uma função anônima contendo a seguinte linha: pm.response.to.have.jsonSchema(schema), onde pm.response acessa a resposta recebida do servidor e, em seguida, é feita a asserção to.have.jsonSchema(schema) para garantir que a resposta satisfaça o schema definido anteriormente. Até o momento o schema ainda é bem simples, mas qualquer resposta recebida com tipagem diferente para as propriedades listadas não deverá passar no teste.

Se for enviada uma requisição agora o teste irá passar, mas para ter certeza que funciona corretamente devemos modificar a especificação do schema ou a resposta para forçar uma situação de erro. A fim de evitar confusões mais adiante e você não acabe com um schema - e, consequentemente, um teste - incorreto, o ideal é fazer alterações apenas na resposta, pois é justamente pra isso que criamos o exemplo. Volte na aba do exemplo e altere o tipo de alguma das propriedades. No caso, irei alterar a propriedade url de string para um valor numérico qualquer:

{
    "args": {
        "foo1": "bar1",
        "foo2": "bar2"
    },
    "headers": {
        "x-forwarded-proto": "https",
        "x-forwarded-port": "443",
        "host": "postman-echo.com",
        "x-amzn-trace-id": "Root=1-63addcc9-5ab135d701ba98d92efac901",
        "user-agent": "PostmanRuntime/7.30.0",
        "accept": "*/*",
        "postman-token": "8bff98e4-237c-4940-bef8-067b3998dd58",
        "accept-encoding": "gzip, deflate, br",
        "cookie": "sails.sid=s%3AmyxFsngmsAqbFM1FofXwBn3M-TlpbIOf.NjXpy0b07Qp08dIDDeOAy9iK7oh5w6Y%2FhyBpbzM9Z1c"
    },
    "url": 123
}

Salve a alteração, volte na aba do mock e envie novamente a requisição. Se tudo tiver sido feito corretamente, o teste deverá falhar:

Note que a mensagem de erro nos dá uma pista do que houve: era esperado que data.url fosse do tipo string, conforme definimos no schema. Ótimo! Sinal de que o teste funciona corretamente - por enquanto. Contudo, sua eficiência ainda está limitada pelo nível de especificidade definido no schema. Perceba que se formos até o exemplo e alterarmos o nome de alguma dessas propriedades, adicionarmos propriedades não especificadas, excluirmos da resposta alguma das existentes ou alterarmos o tipo de uma das propriedades aninhadas, o teste passará da mesma forma, pois a especificação, até o momento, é:

A resposta deve vir como um objeto, e sempre que as propriedades args, headers e url estiverem presentes, seus tipos devem ser object, object e string, respectivamente.

Qualquer cenário diferente desse ainda não é coberto pelo teste, permitindo a validação equivocada de vários erros em potencial, então é hora de aumentar o grau de especificidade para termos um teste mais rigoroso. Vale atentar também para erros de digitação ao definir o schema, pois se args for escrito como arg, por exemplo, o Ajv (a biblioteca de testes que usamos) irá entender que se trata de uma outra propriedade (e não há nada ainda que impeça a presença de propriedades não especificadas), ignorando possíveis problemas em args.

Voltando ao schema, a primeira alteração que já pode ser feita é “descrever” melhor as propriedades args e headers, definindo "type" e "properties" como fizemos anteriormente, garantindo que a tipagem de todas propriedades não sejam violadas:

const schema = {
    "type": "object",
    "properties": {
        "args": {
            "type": "object",
            "properties": {
                "foo1": {
                    "type": "string"
                },
                "foo2": {
                    "type": "string"
                }
            }
        },
        "headers": {
            "type": "object",
            "properties": {
                "x-forwarded-proto": {
                    "type": "string"
                },
                "x-forwarded-port": {
                    "type": "string"
                },
                "host": {
                    "type": "string"
                },
                "x-amzn-trace-id": {
                    "type": "string"
                },
                "user-agent": {
                    "type": "string"
                },
                "accept": {
                    "type": "string"
                },
                "postman-token": {
                    "type": "string"
                },
                "accept-encoding": {
                    "type": "string"
                },
                "cookie": {
                    "type": "string"
                }
            }
        },
        "url": {
            "type": "string"
        }
    }
}

Até agora apenas listamos as propriedades e suas tipagens, mas não especificamos se existem propriedades obrigatórias e quais seriam estas. Podemos fazer isso através de required, que se constitui como um array de strings. Para fins de demonstração, required será adicionado apenas para a raiz do schema, mas pode ser incluído para os objetos args e/ou headers também, claro. O importante é entender seu uso:

const schema = {
    "type": "object",
    "properties": {
                "args": {...},
        "headers": {...},
        "url": {
            "type": "string"
        }
    },
    "required": ["args", "headers", "url"]
}

// Detalhes de "args" e "headers" omitidos apenas para abreviar o exemplo

A partir de agora, a ausência de args, headers e/ou url na resposta deve resultar em erro. Como sempre, é importante testar para o erro antes de prosseguir, então irei remover url e reenviar a requisição:

Porém, a presença de propriedades adicionais ainda não é tratada corretamente, de modo que o schema, cumpridos os demais requisitos, continua sendo válido ainda que contenha outras propriedades além das 3 já conhecidas. Neste exemplo específico, não queremos isso. Para lidar com esse problema, utilizaremos additionalProperties:

const schema = {
    "type": "object",
    "properties": {
        "args": {...},
        "headers": {...},
        "url": {
            "type": "string"
        }
    },
    "required": ["args", "headers", "url"],
    "additionalProperties": false
}

// Detalhes de "args" e "headers" omitidos apenas para abreviar o exemplo

Ao enviar uma requisição contendo propriedades adicionais no retorno, a validação deverá falhar:

Aqui cabe uma diferenciação importante entre required e additionalProperties: na primeira estão listadas as propriedades que devem, obrigatoriamente, existir na resposta do servidor, mas não diz nada sobre propriedades extras; já na segunda podemos ou não permitir que a resposta contenha propriedades das quais não temos conhecimento prévio. Sendo assim, um schema contendo as propriedades X, Y e Z que não as liste como obrigatórias, mas onde additionalProperties receba o valor false, não exigirá que X, Y ou Z estejam presentes na resposta, mas invalidará o teste se esta contiver a propriedade N (não prevista) ou no caso de uma das 3 anteriores estar com o nome incorreto (já que seria tratada como desconhecida pelo schema).

Conclusão

Com isso, nosso schema agora é capaz de definir as propriedades, suas tipagens, lista eventuais propriedades obrigatórias e permite ou não a presença de outras, estando pronto para ser usado na validação dos retornos da API verdadeira, bastando copiar o conteúdo da aba Tests do mock. São regras relativamente simples perto do grau de especificidade que é possível atingir, mas já é o suficiente para realizar testes que irão cobrir boa parte dos cenários menos exigentes, garantindo a qualidade dos dados transmitidos. Na maioria dos casos, quando se atua com outras equipes, o schema já estará definido na documentação, poupando parte do trabalho aqui descrito de identificar as regras manualmente. De toda forma, é sempre uma boa utilizar os mocks para executar alguns testes rápidos pra ter certeza de que está tudo ok com as definições. Recomendo uma lida nas regras específicas para propriedades do tipo array, visto que é um tipo bem comum e que não foi abordado neste texto. Para saber mais sobre as regras e o que pode ser definido além do que foi apresentado aqui, a documentação está sempre disponível: https://json-schema.org/. Bons testes!

Links úteis

• Documentação: https://json-schema.org/

• Validadores, geradores, utilitários, etc: https://json-schema.org/implementations.html

• Ajv: https://github.com/ajv-validator/ajv

• JSON Schema (gerador online): https://www.jsonschema.net/

Tento aqui construir uma aplicação sem muita complexidade ou impeditivos, realmente da forma mais simples. Temos algumas alternativas como o Clean Architecture, que vem se tornando bastante popular, mas a ideia é mesmo ser bastante direto, sem nos esquecer de conceitos importantes de desenvolvimento e boas práticas de programação.

O que não pode faltar em uma API?

Precisamos definir nossas rotas; para gerenciar essas rotas, precisaremos dos controllers; e por fim, para trazer funcionalidade a nossa aplicação, precisaremos dos services.

Este é um modelo bastante simples, padrão até mesmo do NestJS, Laravel e outros frameworks de API. É a partir deste modelo que vamos nos aprofundar um pouco, explorar recursos e tentar definir uma API simples e eficiente.

Montando a estrutura

Veja bem que por aqui, definirei muito bem a responsabilidade de cada estrutura necessária para a API. É importante que siga muito bem a sua função, não fazendo nada mais, além disso. Gosto também de organizar os arquivos de acordo com essa estrutura, cada qual em sua pasta, cada arquivo de acordo com a sua funcionalidade —por ex: na pasta rotas, os arquivos products.route.ts e payment.route.ts

Rotas

Toda API começa pela definição de rotas: os caminhos, ou endpoints, que nossas aplicações clientes irão utilizar para solicitar e receber informações da nossa API.

As rotas devem ser sempre bem escritas, de forma clara e intuitiva a quem vá utilizar. É bastante importante seguir bem os padrões de servidores HTTP, que irão até te ajudar bastante na legibilidade de rotas.

As rotas devem ser responsáveis por definir os caminhos, e enviar aos controllers. Apenas isso.

Se você usa o NestJS será bem interessante, pois rotas e controllers trabalham juntos, como explicamos em nosso texto sobre o NestJS.

Controllers

Os controllers são responsáveis por gerenciar as respostas exibidas ao cliente em uma API. Cliente solicitou a informação de um produto? Exibir o produto. O produto não existe? Retornar um erro 404, com uma mensagem de que este produto não está disponível.

Gosto de limitar os controllers somente a isso. Não é função de um controller procurar um produto em um banco de dados, alterar uma informação, ou qualquer coisa do tipo. O controller é responsável somente por tratar as respostas. Dessa forma, conseguimos deixar nosso código bastante organizado.

Outra função do controller, é de processar as funcionalidades recebidas de o “service” —este, sim, responsável por trazer funcionalidade a API.

Services

Um service tem como responsabilidade centralizar todas as funcionalidades de uma API. Assim como no exemplo que dei de controller: quer buscar um produto? É uma função no service que será responsável por isso. Quer adicionar um novo registro no seu banco de dados? É novamente uma função no service que será responsável por isso.

Em uma aplicação, podemos ter vários services. É importante que eles sejam divididos conforme a funcionalidade: um service para funções dos produtos, um service para funções de pagamento, um service para funções de compra de produtos, e por aí seguimos. Não é um problema, muito pelo contrário, ter uma variedade de services como no exemplo que dei, é justamente isso que ajudará a manter o seu código bem organizado.

Mas claro que, nem tudo precisa estar em um service —é importante apenas que o service centralize as funções. Por exemplo, para cuidar de ações diretamente no banco de dados, podemos ter “repositórios”, para cuidar de uma integração com outro serviço ou API podemos ter um “provider”. A depender de seu projeto, pode ser importante dividir responsabilidades para evitar poluição de código.

É só isso?

Sim, é só isso. Seguindo essa estrutura você consegue montar da mais básica até a mais complexa de uma API, com um código limpo, legível, bem organizado e escalável. A depender da aplicação, realmente não precisamos de muito mais.

É importante ainda que você esteja atento a alguns conceitos importantes por aqui: divisão de responsabilidades, dinamicidade e desacoplamento de funções.

• Devemos dividir bem a responsabilidade de nossas classes e funções de forma que elas não façam nada além do que lhe é proposto. Isso faz com que nosso código esteja melhor organizado, e consequentemente facilita o nosso trabalho de desenvolvimento

• Todas as funções e classes devem ser bastante dinâmicas e estarem preparadas para qualquer possível objetivo, evitando, por exemplo, repetição de código.

• Tenha quantas rotas, controllers, e principalmente services forem necessários. Quando falamos de desacoplamento de funções queremos justamente diminuir a dependência de uma determinada ferramenta. Por que usar um repositório, por exemplo? Se você trocar de banco de dados, ajuste apenas as funções do seu repositório. Os services, que utilizam o repositório, não vão nem mesmo perceber a diferença de troca de banco de dados. Esse conceito pode ser aplicado em qualquer ponta da sua aplicação.

Perceba também que nem mesmo cito linguagens ou frameworks. Não faz diferença. Programação vai muito além da ferramenta, e é mesmo sobre o conceito por trás de sua estrutura.

Podemos ainda mais explorar esses conceitos, melhorando a nossa estrutura e sempre adaptando a realidade do nosso projeto.

Como você monta a sua API? Qual estrutura utiliza? Participe de nosso canal no Discord e conte para gente!

O que é um Array?

Array é uma lista de valores.

Em Javascript, definimos um array como itens dentro de colchetes [“item1”, “item2”], simples assim.

const novoArray = ['item1', 'item2', 'item3'];

Agora o grande mistério é como trabalhar com estes arrays: adicionar um valor, buscar um valor, filtrar um valor, conferir se existe um valor na lista, e diversas outras funções. Existem diversas funções assim e vamos tratar as principais:

push() — Adicionando um item no Array

Para adicionar um novo item na sua lista, basta utilizar a função push(). Um push irá adicionar um novo item na última posição da lista, como você pode conferir no exemplo:

const novoArray = [];
novoArray.push('item1');
novoArray.push('item2');

console.log(novoArray);
//['item1', 'item2']

pop() e shift() —Excluindo um item do Array

Você pode excluir um item do seu array de duas formas: excluindo o primeiro, ou excluindo o último da lista, com as funções pop() ou shift()

const novoArray = ['item1', 'item2', 'item3'];
const ultimoItemExcluido = novoArray.pop();
const primeiroItemExcluido = novoArray.shift();

console.log(novoArray)
//['item2']

indexOf() —Buscando a posição de um item

Com essa função, você passa um valor como parâmetro a ser buscado na lista. Se existir, retornará em que posição está este valor:

const novoArray = ['item1', 'item2', 'item3'];
const indexDoItem2 = novoArray.indexOf('item2');

includes(), some() e every() —Conferindo se item existe

Você pode conferir se um item existe na sua lista com a função includes(), que retornará um valor booleano indicando se existe ou não.

Existem também as funções some() ou every(), bem interessantes para uma analise geral da lista: “existe algum item que cumpre a condição Y na lista?”, “todos os itens da lista cumprem a condição Z?”)

Segue o exemplo:

const novoArray = [1, 2, 3, 4, 5, 7, 8, 'umaStringQualquer'];
const listaPossuiNumero4 = novoArray.includes(4);
const listaPossuiNumero10 = novoArray.includes(10);
const existeAlgumaStringNaLista = novoArray.some((item) => typeof item == 'string');
const todosItemsSaoNumeros = novoArray.every((item) => typeof item == 'number');

console.log(listaPossuiNumero4, listaPossuiNumero10, existeAlgumaStringNaLista, todosItemsSaoNumeros)
//true false true false

filter() —Filtrando items de um array

Uma outra função bastante interessante, e bastante utilizada em diversas situações. Um filter() permite que você gere uma nova lista, filtrando os resultados desejados, seguindo uma determinada condição.

No exemplo abaixo, filtrei de uma lista os resultados pares e impares:

const novoArray = [1, 2, 3, 4, 5, 7, 8];
const numerosPares = novoArray.filter((item) => item % 2 == 0);
const numerosImpares = novoArray.filter((item) => item % 2 == 1);

console.log(numerosPares)
//[2, 4, 8]
console.log(numerosImpares)
// [1, 3, 5, 7]

map() e forEach() —Passando por todos os items de um array

São duas funções parecidas e que geram uma certa confusão. Tanto o map() quanto o forEach() passam por todos os itens da lista.

A diferença, é que o forEach apenas passa pela lista, e o map() pode “remapear” os valores, criando uma nova lista com valores completamente diferentes.

No exemplo abaixo, usei o map() para transformar todos os itens da lista em strings, e usei o forEach para chamar uma ação para todos os itens da lista.

const novoArray = [1, 2, 3, 4, 5, 7, 8];
const novoArrayComoString = novoArray.map((item) => item.toString());

console.log(novoArrayComoString)
//['1', '2', '3', '4', '5', '7', '8']

const novoArray = [1, 2, 3, 4, 5, 7, 8];
novoArray.forEach((item) => realizaAlgumaAcao(item));

Tratamento de listas no Javascript podem parecer complexos, mas é mesmo uma questão de prática? Ainda tem alguma dúvida? Participe de nosso canal no Discord e nos chame por lá que podemos te ajudar!

O NestJS:

NestJS é um framework em Javascript para desenvolver APIs. Simples assim.

Sendo um framework, o NestJS ajuda bastante o processo de desenvolvimento de uma aplicação, trazendo ótimas ferramentas como Swagger, ORMs, Gerenciador de Cache, validações com DTOs, GraphQL e até mesmo um grande suporte a microsserviços, de um jeito bastante fácil e simplificado.

Se você está acostumado a desenvolver APIs puramente com Express ou Fastify, pode até achar um pouco estranho, pois o NestJS conta com uma estrutura bastante particular, com uso de módulos e decorators como base de toda a aplicação, mas é mesmo uma questão de adaptação, toda essa diferença é mesmo uma grande ajuda.

Vamos explorar um pouco mais:

Controllers

Toda API começa na definição de rotas e controllers. Geralmente, fazemos criamos nossas rotas, apontando para um controller que irá fazer todo o gerenciamento de funcionalidade.

No NestJS, é diferente e um pouco mais fácil. Com o uso de decorators, agrupamos nossa definição de rotas diretamente no controller e em suas funções, já de cara definindo o endpoint das rotas e método a ser utilizado, em uma estrutura como essa:

import { Controller, Get, Body } from '@nestjs/common';
import { RequestDto } from '../requestDto.dto';

@Controller('nome_da_rota_aqui')
export class ExampleController {
  @Get('nome_endpoint_aqui')
  getExample(): string {
    return 'Retorno qualquer de um GET';
  }

  @Post()
  postExample(@Body() request: RequestDto) {
    return 'Retorno qualquer de um POST';
  }
}

Ainda nos controllers, algo bem interessante é a criação de DTOs e validação dos payloads enviados. Podemos criar uma classe, em que nossas propriedades recebem um decorator indicando a validação a ser usada. Basta usar essa classe como tipagem de uma variável no controller, e a partir desta definição, automaticamente o NestJS irá validar a sua rota. Um exemplo de um DTO é como:

import { IsNotEmpty, IsEmail } from "class-validator";

export class RequestDto {
    @IsNotEmpty()
    nome: string;

    @IsEmail()
    email: string;
}

Entities

As entities são responsáveis por cuidar do gerenciamento de banco de dados. Em nosso exemplo, vamos utilizar o TypeORM, mas você poderia também trazer o Prisma ou até o Moongose para o NestJS.

O uso de entities segue o padrão da ORM que você irá utilizar, mas a lógica é sempre a mesma: definir os campos e as colunas de sua tabela no banco de dados a partir dos decorators:

import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm';

@Entity('nome_da_tabela')
export class App {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  name: string;

  @Column({ nullable: true })
  lastName: string;

  @Column()
  email: string;
}

Services

Os services são bastante importantes no desenvolvimento de uma API, afinal, é em um service que acontece todo o gerenciamento de funcionalidades da aplicação.

No NestJS, um service nada mais é do que uma classe, que contém as nossas funções. O interessante é que o Nest trabalha com uma injeção de dependencias, mantendo um baixo nível de acoplamento entre nossas funções. Por isso, é bastante fácil trazer outras ferramentas, como um repositório do TypeORM, ou uma ferramenta de requisições HTTP para dentro do nosso service, assim como é bastante tranquilo exportar este mesmo service e usar em outro contexto da aplicação.

Um service no NestJS segue a seguinte estrutura:

import { NewAppData } from './../dto/app.dto';
import { Injectable } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { App } from '../entities/app.entity';
import { Repository } from 'typeorm';
import { HttpService } from '@nestjs/axios';

@Injectable()
export class AppService {
  constructor(
    private httpService: HttpService,
    @InjectRepository(App)
    private appRepository: Repository<App>,
  ) {}

  getHello(): string {
    return 'Hello World!';
  }

  addNewAppData(data: NewAppData): Promise<App> {
    const app = {
      name: data.name,
    };

    return this.appRepository.save(app);
  }

  findAppDataById(dataId): Promise<App> {
    return this.appRepository.findOne({ where: { id: dataId } });
  }
}

Módulos

Tudo no NestJS acaba em um módulo. Um módulo é responsável por inicializar os nossos controllers, services, entities e outras ferramentas dentro de nossa aplicação.

Se você está familiarizado com o Angular, é a mesmo padrão: tudo que criamos dentro do NestJS deve ser inicializado num módulo.

Você pode ter a quantidade de módulos que quiser e organizar da melhor forma que puder imaginar, o que pode trazer ao NestJS uma ótima funcionalidade de gerenciamento de módulos. Por exemplo, você pode centralizar toda uma funcionalidade de “Usuários” dentro de um “UserModule” que irá conter todos os controllers, services e entities utilizados neste contexto, e então, aplicar este módulo no “AppModule”, módulo base do NestJS.

Um módulo no NestJS é como o exemplo abaixo:

import { App } from './entities/app.entity';
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { Database } from './helpers/database';
import { AppService } from './services/app.service';
import { AppController } from './controllers/app.controller';
import { ExampleModule } from '../example.module';

@Module({
  imports: [
    ExampleModule,
    ConfigModule.forRoot(),
    Database.build(),
    Database.registerEntities([App]),
  ],
  controllers: [AppController],
  providers: [AppService],
  exports: [AppService],
})
export class AppModule {}

De forma bastante simplificada, este é o NestJS.

Ainda há muito a ser explorado e traremos estes pontos em nossos próximos textos da devGo, mas que esteja claro os benefícios: as ferramentas disponíveis, a estrutura simplificada, a agilidade no desenvolvimento e a facilidade de adaptação ao framework.

E você? Já usa o NestJS ou algum outro framework? Participe do nosso canal no Discord e conte para gente!

Trello, Jira, Asana, Clickup

A maioria dos desenvolvedores já deve estar mais do que acostumados com essas ferramentas. Metodologias como Agile, Scrum ou Kanban usam como base aplicações neste formato para organização e planejamento das demandas.

Gosto de usar essas aplicações para grandes demandas: “desenvolver página da home”, “criar endpoint para usuários”, “criar recurso de recuperação de senhas” ou qualquer outra coisa que demande bastante atenção e tempo.

O legal é mesmo usar em trabalhos em equipe, até porque várias pessoas trabalhando em um projeto requer uma boa organização e fácil acompanhamento. Aqui utilizamos bastante o recurso de “arrastar para a próxima coluna” ao atualizar o status da nossa tarefa, e temos todos os detalhes e planejamento da tarefa por aqui!

Combine como usar com a sua equipe e traga seu planejamento para dentro da aplicação. Importante é sempre estar usando!

Todoist, Ticktick

Estes são ferramentas de “Listas a fazer”. Diferente do Jira ou ClickUp, mais usados em equipe, gosto de usar essas aplicações para uso pessoal e individual mesmo: apenas eu uso, vejo e gerencio.

Anoto pequenas demandas, rápidas de serem feitas, e organizadas das diariamente: “falar com fulano”, “conferir status da demanda X”, “mapear banco de dados”.

Uma organização dessa forma faz parte do método Get Things Done, que tem me ajudado bastante e recomendo a todos: literalmente tudo que tenho para fazer, deixo registrado. Se está feito, apenas concluo a tarefa e está fora da minha lista. Organizo por prioridades e se for o caso até deixo alguns alarmes. O foco é finalizar tudo o que deve ser feito naquele dia.

Importante aqui é: anotar tudo!

O bom e velho calendário

Nada substitui o calendário. Se você faz muitas reuniões, tem sempre algumas chamadas aqui e ali, não pode deixar de usar o calendário.

Por mais simples que pareça, nos ajuda a não perder os planejamentos e ter tudo mapeado para o dia. Deixo tudo registrado e com alarmes para não esquecer de nada!

Não subestime!

São pequenas ações como essas comentadas aqui que nos ajudam a não perder o rumo. Durante um momento de muita agitação, muita correria ou muita urgência, você quer ter certeza de que não está esquecendo de nada, certo?

Ter esses hábitos incorporados no dia a dia, independente do momento, é o que faz a diferença.

E você? Como organiza as suas demandas? Participe do nosso canal do Discord, e conte para gente!

É impossível prever o futuro

Este é o ponto mais importante: você não sabe o que vai acontecer amanhã. Passar um prazo tentando imaginar o futuro é apenas “chutar” uma data, e isso é a pior coisa que você pode fazer enquanto está dando um prazo.

O seu “Waze” ou “Google Maps”, por exemplo, só sabem que você leva 15 minutos do ponto X ao ponto Y porque você irá passar por um caminho bastante específico. Em um projeto é a mesma coisa, você precisa construir uma rota.

Planejamento

O que é preciso ser feito no projeto? Tenho conhecimento suficiente para isso? Precisarei de alguma ajuda ou suporte? Há algum ponto de atenção durante o projeto?

São perguntas que sempre devem ser feitas antes de dar um prazo. E o planejamento começa a partir do momento que você responde essas perguntas.

Entenda o que precisa ser feito e mapeie as demandas; estude tudo que for necessário para que você desenvolva o projeto; vá atrás de alguém que te dará o suporte e já resolva todas as pendências, ou ao menos já deixe marcado; dê atenção as maiores dificuldades do projeto, e se possível até as faça primeiro.

Dê pequenos passos

Se você tem um projeto fullstack para desenvolver, você não pode pensar “10 dias para o backend, 10 dias para o frontend”. O que vai ser feito no backend? O que precisa ser desenvolvido no frontend? É mesmo tão simples a ponto de ser definido de forma tão macro?

A dica é trabalhar com pequenas tarefas: no backend, preciso construir a rota X e isso levará 2 dias, no frontend preciso construir o componente Y e isso levará 1 dia. Isso te dá uma perspectiva mais realista sobre o projeto e permite que você seja mais preciso com os prazos.

A questão por aqui é que é mais difícil dar um bom prazo para um projeto grande, do que para uma tarefa pequena.

A Lei de Murphy

Se algo tem chance de dar errado, vai dar errado. E vai mesmo. Esteja sempre preparado para algum possível problema: atraso em alguma tarefa, desenvolvimento não previsto, uma dificuldade maior do que você espera.

Por isso, volto em alguns pontos: planejamento e tarefas pequenas: com um bom planejamento você evita e se prepara para maior parte dos problemas; com pequenas tarefas você vê o erro acontecendo mais cedo e tem mais tempo hábil para solucionar.

Se um erro irá acontecer, você precisa estar preparado e ser ágil para resolver.

Experiência

O seu primeiro prazo vai ser horrível, o segundo só vai ser ruim, o terceiro foi quase lá e no quarto você finalmente acertou.

A experiência vai te permitir planejar melhor, se preparar para os problemas melhor e até descobrir novos caminhos. É o que você mais precisa para dar um bom prazo.

Ao final de um projeto, sempre tente entender onde você errou, o que poderia ter feito melhor e como fazer melhor. Desta forma, a experiência vai surgindo gradualmente.

Ainda assim você vai errar

Não importa o nível de planejamento, se demandas foram bem colocadas, se você viu um erro acontecendo e até conseguiu resolver, no fim, o seu prazo pode ir completamente errado, independente até da experiência que você tenha.

Por isso, gosto sempre de usar uma “margem de erro”. É bem simples até: Se é 10 dias, digo 15. Se é 20 dias, digo 30. Essa pequena diferença me dá mais espaço para resolver qualquer eventual problema sem quebrar a expectativa do cliente. E se tudo ocorrer bem, acabo entregando até mesmo antes da data que eu disse.

Prazos são uma negociação

Se mesmo com todas as dicas as coisas podem dar errado, o que fazer então? Bom, veja que estamos tentando trabalhar de forma exata, com algo que não é exato, e é por isso que erramos tanto.

Um bom prazo não é acertar em quantos dias você consegue entregar algo, até porque prazos não são sobre datas, são sobre expectativas, e expectativas estão bem longe do campo de exatas. Um bom prazo depende da forma em que isso é apresentado, em como é trabalhado durante toda a etapa de desenvolvimento, e principalmente em como é entregue ao final.

Tenha isso em mente, independente dos problemas, trabalhe com a expectativa do cliente.

Termino dizendo que prazo realmente não é nada tão exato quanto nós pensamos, e por isso, é um ótimo assunto a ainda ser discutido várias e várias vezes. Você já conhece o nosso canal do Discord? Estaremos por lá debatendo ainda debatendo este assunto. Participe conosco, e compartilhe como você trabalha com prazos também

Icons

Atualmente no vscode existem várias extensões de arquivos que ajudam a gente a não precisar olhar somente a extensão do arquivo e deixam o ícone da extensão do arquivo e das pastas para uma melhor visualização, logo abaixo recomendarei algumas extensões que fazem esse papel:

Material Icon Theme:

Link para download: https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme

VsCode Icons

Link para download: https://marketplace.visualstudio.com/items?itemName=vscode-icons-team.vscode-icons

Material Theme Icon

Link para download: https://marketplace.visualstudio.com/items?itemName=Equinusocio.vsc-material-theme-icons

Snipets

Os snipets estão aí para além de facilitar nossa vida adicionando certas estruturas previamente prontas, como, por exemplo, um switch case ou um laço for, pequenas estruturas que escrevemos várias e várias vezes durante o dia com uma simples palavra, ele já digita toda a estrutura básica e fica faltando você somente adicionar os dados necessários.

GitLens

O git lens está aí para melhorar a usualidade do git dentro do vscode, podendo mostrar quem editou ou escreveu tal linha de código, mostrar uma worktree simplificada, poder ver de uma forma melhor os últimos commits feitos em determinado arquivo, além de muito mais.

Link para download: https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens

Live Share

Para você que trabalha em equipe e precisa desenvolver com outro desenvolvedor simultaneamente, para auxiliar ou fazer um pair code. O live share permite exatamente isso. Com ele basta uma conta da microsoft ou do github você consegue "entrar" dentro do código na máquina do seu parceiro, assim podendo editar com ele o mesmo arquivo em simultâneo.

Link para downlod: https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare

Bracket pair colorizer

Para você que utiliza uma linguagem com muitas chaves, colchetes e parênteses, essa extensão colore os fechamentos, assim deixando mais fácil localizar o início e o fim. Com isso você consegue se localizar melhor no seu código, além de ficar visualmente mais estético.

Link para download: https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2

Prettier e Beutify

São extensões que irá realizar a indentação do código para você, deixando mais limpo e bonito para que outras pessoas vejam. Além de que bem configurado você não terá problemas em ter que ficar arrumando o seu código a todo instante.

Prettier

Link para download: https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

beautify

Link para download: https://marketplace.visualstudio.com/items?itemName=HookyQR.beautify

Polacode

Polacode é uma extensão para que você possa printar determinada parte do código, assim ficando melhor para enviar para alguém. Essa extensão permite você também redimensionar o tamanho das linhas no próprio print.

Link para download: https://marketplace.visualstudio.com/items?itemName=pnp.polacode

TODO Highlight

Essa é uma extensão para que os TODO e FIXME no código fiquem mais fáceis de se verem, dando assim mais oportunidades para desenvolvedores resolverem problemas no código. Pois se algo está brilhando e chamando a atenção, o desenvolvedor não terá a desculpa que não enxergou o comentário.

Link para download: https://marketplace.visualstudio.com/items?itemName=wayou.vscode-todo-highlight

Color Hightlight

Essa extensão coloca um contorno da cor do código hexadecimal de cor em volta dos códigos hexadecimais de cores. Isso da mais liberdade pro desenvolvedor testar novas combinações de cores, já que não será necessário olhar na tela para ver qual cor é a daquele código hexadecimal.

Link para download: https://marketplace.visualstudio.com/items?itemName=naumovs.color-highlight

Live Server

Essa extensão permite você criar um micro servidor http para códigos html deixando assim mais fácil a edição desses arquivos. Já que com esse micro servidor qualquer mudança feita no arquivo será modificada em tempo real na página.

Link para download: https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer