Em pleno feriado, nada para fazer, eu tinha em mente um relatório que recebi no fim de semana, de um dos meus serviços que deixo rodando no meu homelab.

O report recebido era esse:

Essa era a “pior” query, visto que era um serviço com poucos acessos, então outros endpoint estava em um ótimo tempo de resposta.

Essa query, se fosse algum serviço maior e mais sério, não precisava gastar tanto tempo nisso, mas foi umas horas de aprendizado.

Contexto

Tenho uma API onde a autenticação é delegado ao Auth0, e ao criar um novo usuário na minha db, antes preciso verificar se esse email já foi criado ou não. A princípio, isso é uma coisa banal de se fazer, já que temos índices unique na maioria dos bancos de dados.

O “problema” é que um usuário, pode ter várias “identidades”, ou formas de se conectar. Para o Auth0, login via Google, é uma conta diferente de Login / Password, que também é diferente do Login com Facebook. Para vincular as contas, entra os “link account”.

Se sua regra de negócio não permite que o mesmo email seja contas diferentes, você precisa ter uma “action” que faz alguma ação antes de realizar o cadastro. E eu tenho uma API com chave (M2M) que diz se aquele email já existe em minha base, ou não.

Basicamente armazeno as contas do seguinte formato:

• id (PK)
• auth0_id (qual identity é a principal, para controle de qual não pode ser desassociada, até a troca de outra principal)
• auth0_infos

Entenda auth0_infos como dados parciais da conta como se fosse um cache. por exemplo:

{ {"identities" => {"google-oauth2|1234" => {"email" => "xx@x.com", "connection" => "google-oauth2", "email_verified" => true } } )

Problema

O index que criei primeiramente, era para solucionar a busca rápida pelo auth0_id, que fazia algo do tipo:

select auth0_infos->'identities' ? 'google-oauth2|1234' from users

com o index:

(auth0_infos -> 'identities'::text)

O explain analyze me retornou um bitmap, com menos de 1ms, estava feliz e pronto, vida que segue.

Porém quando surgiu a necessidade de existir a implementação dos identities, o que eu fiz foi algo do tipo:

SELECT "users".* FROM "users" WHERE (EXISTS (
        SELECT 1 FROM jsonb_each(auth0_infos->'identities') AS identity
          WHERE identity.value->>'email' = 'user_xpto@example.com'
));

Na minha cabeça, funcionava perfeito, como tinha poucos usuários, não me importei muito, então “compilou, vendeu”.

O resultado foi ter um FULL SCAN Query.

Pesquisa

Após ver o report, decidi melhorar meu entendimento sobre como isso realmente funcionava, e vou deixar uns artigos que me ajudou:

• Optimizing Array Queries With GIN Indexes in PostgreSQL

• Understanding Postgres GIN Indexes: The Good and the Bad

• GIN - Just A Kind Of Index

• Mastering PostgreSQL GIN Indexes: The Ultimate Guide to Faster JSONB, Array, and Full-Text Search

Um post do Stack Overflow me chamou atenção aqui: “For containment @> it works with nested values. For other operators it works only for top-level keys or whatever level is used in expression index. Also, according to documentation, using expression index on level you want to query will be faster than simple index on whole column (makes sense as size is smaller).

If you are doing only containment search, consider using jsonb_path_ops while building your index. It is smaller and faster.”

Então se juntarmos os posts, com o esse comentário, percebemos que o problema ta mesmo na query e não no index.

Mas até onde podemos melhorar?

Solução

Primeiro, Vamos trocar testar remover o jsonb_each e usar operador simples de concat. @> que o jsonb_path_ops suporta:

SELECT * FROM users WHERE auth0_infos -> 'identities' @> '[{"auth0_id": "auth0|52e3af8e7f5be863c4169abb"}]'::jsonb;
SELECT * FROM users WHERE auth0_infos -> 'identities' @> '[{"email": "user_100000_aa7daf85@example.com"}]'::jsonb;

No Rails:

Para aproveitar o melhor da indexação, mudamos a estrutura que armazenamos para:

{
  "identities": [
    {
      "auth0_id": "auth0|1234",
      "email": "user@example.com",
      "isSocial": false,
      "email_verified": true,
      "connection": "Username-Password-Authentication"
    }
  ]
}

Preparei uma DB com uma quantidade considerável de usuários ( 100 mil ), e o resultado:

Antes:
Execution Time: 187.472 ms

Depois: 
Execution Time: 0.084 ms

Se só estamos utilizando esse operador, e não precisamos de tanta flexibilidade (interseções, mais entradas indexadas), não precisamos ter tantas entries no nosso índice.

Atualmente temos este peso (índice não é grátis):

SELECT pg_size_pretty(pg_relation_size('index_users_on_auth0_infos_identities'));

22 MB

Agora quero ver qual a diferença que tenho, após criar apenas jsonb_path_ops:

CREATE INDEX idx_users_auth0_identities ON users USING GIN ((auth0_infos -> 'identities') jsonb_path_ops);
SELECT pg_size_pretty(pg_relation_size('index_users_on_auth0_infos_identities'));

12 MB

Bem menos, resolvendo o mesmo problema!

Conclusão

Ainda não é um assunto que domino 100%, mas entender a diferença de BTREE, GIN, GIST, Brin, Hash como índice, e sua estrutura de dados te faz pensar com mais clareza na solução.

Foi bom conhecer também os limites de escritas dos índices GIN, tanto em tamanho de pendentes, como em lentidão de escrita, que me faz pensar no como o não relacional resolve bem essa parte.

Obrigado por ler até aqui, um abraço.

Este artigo vai ser bem breve, e o objetivo principal é mostrar como hoje faço meus estudos.

Leitura

Eu iniciei minha carreira, lendo muitas apostila em PDF de PHP, e sofri pra aprender lendo.

Ultimamente tenho lido muito conteúdo teórico da faculdade, e livros recomendados pelos meus professores, e livros que tenho muita curiosidade para aprender.

Normalmente eu prefiro livros físicos, mas dependendo da leitura, eu também uso kindle, e (bem raramente) o iPad.

Eu também faço notas nos livros que leio, e quando é um mais mão na massa, igual ao livro de Java, eu paro pra testar coisas diferentes, para validar se o que li, eu aprendi direito.

Quando eu gosto muito do livro que estou lendo de forma virtual, eu compro o livro físico, para fazer notas. ( mesmo que já tenha comprado na amazon ).

Papers

Essa modalidade é nova, mas ultimamente, com o aumento do meu interesse na área acadêmica, eu estou lendo papers acadêmicos relacionado a sistemas operacionais e sistemas de arquivos. É uma área que quero contribuir, então logo espero fazer algo por aí.

Papers são complexos, foram anos de estudo, e se você entender bem a proposta, poderá valer mais que centenas de vídeos.

Engineering blog

Existem muitos blogs bons, de cientistas e engenheiros de verdade. Netflix Medium, Uber, Shopify blog, etc.. Esquece Medium de pessoas randoms que querem fazer bait como “stop doing …”. Pelo amor de Deus, é uma perca de tempo.

Meu próprio blog, eu faço pra mim, e pensando em mim.

Palestras Online

Eu gosto de palestras gravadas, não de vídeos de influencers no Youtube. Também não gosto de cursos pagos. Faz muito tempo que não pago algum curso.

Os cursos na Udemy, e alguns específicos, foram bons no início da minha carreira. Depois acabei assistindo alguns com destaques, tipo Full Cycle e Balta. Esses tem conteúdo dedicado em um tema que eu não queria perder muito tempo, e acabei aprendendo bastante. São ambos que têm décadas de experiência.

Eu já não tenho paciência para esses cursos, são lentos, e eu consigo hoje facilmente na documentação, entender o objetivo, e aprender por mim mesmo.

Palestras normalmente são deep dive bem abrangente, e mostra muito o overview do problema que tal solução resolve.

Palestras presenciais

Além do network, palestras presenciais são muito boas, por que muitas das vezes, eu posso levantar a mão e perguntar algum ponto das palestras.

Nem todas vão valer a pena. Eu já assisti palestras onde o tema era nada interessante, mas ao conversar no final com algumas pessoas experientes, valeu muito mais e agregou muito no conhecimento limitado que tenho.

Ler pull requests de Open source

É bem legal ler pull request de algum projeto em uma linguagem que você tem interesse. Por exemplo, eu costumo ver os PR e RFC do Swift Lang. Também costumo ver PRs do Ruby on Rails, Spring Boot, e ver o que estão fazendo e que forma implementam as coisas.

Ver também os comentários resolvidos do PR, são bem interessantes.

Learning by doing

Quando estou cansado de conteúdos repetidos, eu costumo mexer com placas de ensaio e microcontroladores.

Também testo coisas como manter um servidor em um Raspberry, e monitorar o mesmo.

Considerações

Faça as coisas, leia documentação, leia livros, e tente evoluir. Sai desses videozinhos do youtube, que você não aprende nada.

Esses dias no Linkedin uma pessoa postou que viu o vídeo XPTO, e não concordava e perguntou o que outros achavam. Simplesmente queria tocar numa discussão de gosto pessoal. Pelo amor de Deus, vá estudar!

Se você discorda de algo, vá pro próximo tópico de estudo, ou vá você e crie um exemplo de que XYZ funciona em tal linguagem, ou framework, mas só caso você não tenha certeza. Se já tem, vá pra outra coisa.

É muito melhor ter uma boa base técnica, e boas fundações, do que um badge de ’top voice’ ou qualquer porcaria que recompensa por perder seu tempo.

Este artigo é minha reflexão sobre a minha carreira na programação. Serve como um lembrete para mim mesmo, uma forma de lembrar que tracei algumas metas e não desisti delas. Também gostaria de indicar quem me motiva e inspira.

Com o tempo, vou esquecer de detalhes que hoje está bem vivo. Então espero que eu consiga ler este blog daqui muitos anos.

Quem eu era

Eu hoje em dia, com 28 anos, tenho muito claro em minhas lembranças 2005, quando fiz minha primeira conta MSN, como relacionava no MySpace, e como era limitado o acesso a informação.

Alguns detalhes me trazem nostalgia como: Os horários limitados a internet como sábado após as 14h ( que na verdade nunca me perguntei o motivo desse horário ), e domingo o dia todo. Dia de semana era de meia noite as 06:00, mas eu só utilizava este horário para ficar conectado, por que “ganhava” pontos no provedor intelig que eu conseguia trocar por créditos de operadora para meu chip de celular.

Nesta mesma época eu comecei um curso de datilografia na associação de moradores do meu bairro. Era praticamente horas escrevendo páginas de livros, durante alguns meses. Eu lembro que faziamos algo mais, como gravar documento de texto em um disquete. Eu lembro que disquete não era tão caro, e vendia ao lado da mercearia onde minha vó era dona e trabalhava. Esses disquetes tinha de várias cores (inclusive eu tinha preto, vermelho e verde), mas não lembro exatamente o que eu fazia com eles.

Eu vou me referir a esta época como entre os anos de 2005 a 2008, por que é exatamente dos 09 aos 12 anos que foi o meu início de descobrimento do que é um computador.

Nesta época, tinhamos vários discadores de internet: Oi, intellig, IG, POP (que eu odiava), e terra. A internet era então 56kbps, então como a internet era “discada” ( literamente, era uma ligação para se comunicar na internet ), existia o risco da internet “cair”. O sentido de cair, era literamente perder a conexão, e ter que “discar” novamente para voltar a ter acesso.

O maior problema era ter que tentar fazer download de jogo, música, que demorava horas e horas e a internet cair, precisava fazer tudo de novo. Além de até o fator de pessoas te ligarem, afetar a internet e ela cair. Então eu utilizava formas de fazer download de música e clips como Emule, Kazaa. Mesmo se a internet caisse, eu conseguia continuar de onde parei o download. Além disso, era possível utilizar o download accelerator, que fazia uma gestão desses pacotes e pulava o que já tinha feito o download. ( Não me lembro bem como funcionava, nem nunca tive essa curiosidade )

Além disso, uma forma de espalhar algum conteúdo era por meio de revistas. Eu lembro de comprar revistas como da LevelUp, Digerati, em bancas de jornais. Sempre vinha com algum CD, que tinha demo de algum jogo, algumas apostilas em PDF para ler e aprender algo. Isso era louco, ter que ir na banca de Jornal, para saber o que há de novo para aquele mês.

Entre 2009 a 2010 foi uma época que eu fui apaixonado por MMORPG, e Ragnarok Online era mágico para mim. E nesta época meu tio começou a fazer curso na Microlins de montagem e manutanção de micros e redes de computadores. E foi neste ponto, que minha curiosidade começou a aumentar sobre a computação.

2011 foi definitivamente o marco da minha vida, eu assistia Naruto e existia muito site de animes, então em algum papo dentro do Ragnarok, conheci um garoto que sabia criar sites, e ele me chamou pra criar um site de naruto que ele tava fazendo pelo Photoshop. Eu copiava o html, e css de alguns sites, e me lembro claramente a decepção que tive, quando eu fiquei por dias sem conseguir fazer um efeito de esconder conteudo e meu código tava igual a um tutorial, e no fim, era a falta de um import de javascript.

Eu não entendia nada mas era muito legal construir sites, e esse garoto na época chegou a abrir um perfil HiPix eu acho, que era para vender PSD (arquivo de photoshop) de Web Design. Então eu tinha 15 anos, minha mãe deixou eu fazer um curso de web design ( na época existia uma escola de desenvolvimento de jogos, que se chamava Seven, era uma ótima iniciativa, mas era muito caro, e não tinhamos dinheiro para investir num curso assim), e neste curso aprendi coisas como Macromedia flash, dreamweaver, fireworks ( Vulgo MX Studio ).

Meu tio tinha me ensinado como iniciar um emulador de Ragnarok, e então imagina que, com 15 anos, eu estava aprendendo a fazer site, comecei a entender como compilar um servidor ragnarok pelo Visual Studio, e iniciar ele, e entrar em um servidor onde eu era o “game master” e eu também podia criar uma “rede virtual” via Hamachi e 5 pessoas podiam jogar na mesma rede, era incrivelmente maravilhoso.

Importante comentar aqui, que eu comecei a ter internet discada (acho que acima de 56kbps), e todo dia disponivel, e então comecei a frequentar bastante fórum de discussão de programação, e de ragnarok (Cronus, eAthena, brAthena e Hercules)

Entre 16 e 17 anos (2012 e 2013), foi um contexto que já tinha internet de 1mbps (sem limitação de dias e horário), e eu comecei a fazer alguns sites para servidores de Ragnarok, e comecei a ganhar um dinheiro aqui e ali, por que eu já conhecia o Schema do banco de dados (MySQL) dos emuladores de Ragnarok, e conseguia saber qual Clan conquistou qual castelo, Ranking PvP, e comecei a fazer script para NPC.

Foi quando também comecei a ler muitas apostilas de PHP, e juntar conhecimento de PHP + MySQL, conhecer também como subir arquivo via sftp pelo filezilla. Isso me levou a procurar entender como funcionava o cPanel, e comecei a entender os servidores apache, XAMPP e Wamp.

Até os 17 anos (2013) eu jogava muito Ragnarok, então entre 2011 a 2013 comecei a vender sites (alguns muito inspirado no themeforest), instalar Fórums para servidores (tantos Invision IPboard), configurar layout de alguns tipo “forumeiros”.

Neste ponto, antes de terminar o ensino médio, eu já conhecia um pouquinho de C++ devido ao emulador de Ragnarok, PHP 4 e 5, como alguns sistemas de gestão como cPanel, Whm e ipboard funcionavam. Também conhecia como entrar numa VPS via SSH, fazer um servidor de ragnarok rodar, junto com Banco de dados, e que porta era necessário liberar. ( Login-server, Char-server e Map-server )

Eu ja conhecia um pouco de Linux, por causa do CentOS.

E meu último “grande” projeto foi construir um painel onde um cliente de uma plataforma de servidores, conseguia ver o status dos 3 server do jogo. E fazer operação como: Compilar servidor (um script que via SSH fazia um curl, depois executava a compilação do servidor), ligar o servidor (um script via SSH que fazia algo como ./login-server &), desligar servidor, baixar todo o conteudo do servidor (um script que fazia zip e acessava o link publico diretamente do servidor via porta 80). E acreditem que esse painel, era o diferencial de todos os provedores de VPS, já que não eram dedicado para Ragnarok.

Cheguei a fazer um outro Rewamp em 2016, mas nunca foi pro ar ( já tinha acabado a era de ouro do Ragnarok ).

Após meus 18 anos ( a partir de 2014 ), que comecei a estudar para trabalhar na área de verdade. O mercado era cruel, pelo menos na minha visão, onde eu não era um completo idiota, mas não sabia das linguagens de mercado como Delphi e Java.

Salto na história

Demorou 5 anos, além dos outros 3 que estava aprendendo e ganhando dinheiro, para começar em uma empresa de verdade. De 2014 a 2019 foram muitos trabalhos freelances (alguns de poucos valor, outros com mais), e ter que trabalhar e estudar (começar uma faculdade, trancar por falta de tempo, dormir mal por passar noites estudando). Não tem nenhum valor em contar sobre esses anos.

De 2019 a 2024 foram anos de tabalhar em empresas, fazer duas faculdades, e estudos extracurriculares.

O que sou hoje

Hoje em dia, olho pra trás, e vejo o que construi com PHP, NodeJS, Ruby on Rails, JQuery, e os infinitos frameworks/biblioteca Frontend, e ainda estou construindo, agora um pouco mais voltado a Backend.

Também estou bastante focado em ler muitos livros, e ter bastante conhecimento, e conseguir compartilhar eles.

O que serei

A médio prazo, pretendo continuar estudando Java e C# para trabalhar com sistemas maiores, talvez ir pra Banco, ou empresas que trabalham com processo em escala.

Já se passaram 10 anos, que estou em TI, e pretendo até os 20 anos de carreira, acumular toda essa experiência, fazer meu Mestrado, seguir para um Doutorado, participar ativamente no campo de pesquisa e enfim, até os 30 anos de carreira, me tornar um professor universitário, e ajudar a próxima geração de programadores.

Tendo em conta que estamos numa era de Inteligência Artificial, então, continuar me adaptando para que eu continua relevante na área que é a minha paixão.

Agradecimentos

Sou primeiramente grato pela minha esposa, Karen Castro, que esteve do meu lado desde o dia 0, da minha vida profissional, e que me conheceu antes disso tudo, e que ajudou a chegar onde cheguei e sempre me apoiou.

Sou muito grato ao primeiro CTO - Ian Paletta - que me deu a minha primeira oportunidade.

Sou grato ao CTO que me inspirou em vários aspectos, como flexibilidade, bondade e foco. - Daniel Vieira

Sou grato ao Lucas Testa, que não consigo definir como CTO, Backend, Head, já que teve todos esses chapéus, mas merece um destaque, por que alem de um ótimo amigo, foi outro impulso na carreira, na vida, com suas soft skills.

Sou grato também ao CTO que hoje em dia, é mais que um chefe, mas é uma inspiração como pessoa, como pesquisador, como mentor, e que conseguiu dar o maior impulso de carreira que já tive. - João Ferreira Loff.

E por fim, mas não menos importante, a todos meus amigos que fiz durante esse percurso e aos que vão fazer.

Esses amigos que foram além de colegas de trabalho, mas sempre se ajudaram, que um deu a mão para o outro.

Amigos que passamos momentos das nossas vidas pessoais juntos, e que também aprendemos coisas juntos.

Existem algumas coisas que me deixam profundamente chateado no nosso contexto de desenvolvimento de software.

Posso citar algumas como: decisão sem motivo técnico, ataque à decisão sem saber o contexto de implementação e falta de compromisso com seu próprio trabalho.

Vou explorar esses três pontos e dar minha visão pessoal sobre eles.

Ataque à decisão técnica

Não importa se você é Frontend, Backend ou DevOps. Se você já tem experiência, já deve ter implementado algo que hoje em dia não é muito comum.

Assim como no Japão se usa fax ao invés de e-mail, ou startups que usam FTP ao invés de algum CI com Github, Gitlab, ou o que for, sempre haverá alguém que irá criticar a abordagem.

O que eu defendo não é o que está sendo usado e sim o contexto do todo. Vá até o Japão e grite para todo mundo que deveriam usar e-mails, e que sua opinião é super validada e maravilhosa. Boa sorte!

Um post muito “interessante” falando sobre não se deveria usar várias bibliotecas para resolver o suposto “problema”.

O autor não estava errado em dizer que não deveria haver falta de padronização, porém duas ferramentas podem coexistir pela identificação de um problema técnico.

Vou contar uma experiência pessoal, mas não leve tanto em conta a tecnologia usada, porque hoje ela está em alta, amanhã será uma totalmente diferente.

Eu mesmo, quando era Frontend Lead, tomei uma decisão onde escolhi uma biblioteca que era bastante usada, tinha “battle-tested” (termo usado para algo bem utilizado por anos), e resolvia 90% dos problemas.

Porém, a implementação no NextJS era ruim, mas só se perceberia isso com o tempo. Após um ano e meio da existência, foi necessário migrar, pois do contrário prejudicaria o uso da plataforma.

Uma nota importante aqui: o workaround não valia a pena. Era tampar o sol com a peneira.

A escolha da mudança deveria ser bem testada, cobrir a necessidade do uso atual e cobrir o caso de uso onde estava ocorrendo o problema.

Migrar tudo seria muito trabalhoso, então decidi criar uma dívida técnica e migrar os pontos onde estava começando o gargalo. E então, toda alteração na aplicação posterior que tocasse nessa biblioteca, era necessário mover para a nova implementação.

Pontos importantes:

• O ponto é usar a ferramenta correta no tempo correto.
• Ter base técnica na escolha e na mudança.
• Nem tudo é projeto recém-iniciado, onde você tem todas as escolhas certas.
• Provavelmente, a ferramenta que você acha ideal nem existia quando a solução foi feita.

Decisão sem motivo técnico

Uma decisão feita por falta de contexto ou conhecimento, embora não seja comum num cargo de líder técnico, na minha opinião, dá para entender.

Ninguém tem que ficar a cada segundo procurando a última ferramenta do momento, embora as escolhas precisem ser baseadas no CASO DE USO para o problema que está sendo resolvido.

Mas não estou falando de overengineering. Não é basicamente escolher Kubernetes, Kafka, RabbitMQ, e outros exemplos que podem ser demais para atender poucos clientes.

Vou dar um exemplo baseado na experiência que tive um tempo atrás.

Existe um problema no Frontend que não é novidade. Acontece em todos os frameworks e foi resolvido com Tree-Shaking. Você pode depois pesquisar caso não conheça esses problemas de bundler. Você também pode ver uma pesquisa que eu fiz sobre code splitting.

Certa altura, quando apresentei esse problema em um dos comentários de um code review, a resposta que recebi foi: “Entendo seu ponto. Mas siga da minha forma, que fica mais padronizado”.

Onde a opinião pessoal foi mais forte que uma base técnica.

Eu realmente não me importo com isso, desde que não seja com um projeto sob minha responsabilidade. Isto é um sintoma de fraqueza, onde o ego é maior do que sua base técnica e suas bases fracas.

Eu compartilho de uma coisa que o Akita disse sobre DHH e o Ruby on Rails: “Certo ou errado, ele owna as decisões em vez de se esconder atrás de um comitê. Isso é integridade conceitual que todo projeto precisa: um ditador benevolente. Gostem ou odeiem, foi o que manteve o Rails intacto até hoje.”

DHH, ou o criador do Rails, tem opiniões fortes porque suas bases são fortes.

Pontos importantes:

• O chef não conhece todas as comidas do mundo, mas ele tem um paladar treinado e sabe quando algo é mal feito.
• Você não precisa saber tudo, mas precisa ter boas bases sólidas.
• Com bases fracas, criam-se líderes fracos.

Falta de compromisso com seu próprio trabalho

Eu já falei minha opinião no último post sobre fazer testes unitários e de integração.

Se você ainda está aprendendo ou tem pouca experiência como programador, o que vou dizer não é para você. Mesmo que, na minha opinião, você já deveria estar explorando testes.

Mas eu já estou cansado de ver pessoas “experientes” dando desculpinhas sobre fazer testes. Pessoas com anos de experiência, com a falácia de “ninguém faz testes, e se meu PR for aprovado, não vou fazer o teste. Só se for obrigatório”. Ou até mesmo líderes que não se importam com testes, não têm métricas, e os poucos testes que fazem têm nível porco de validação.

Para mim, todos não têm compromisso com seu próprio trabalho, preferem estar correndo atrás do rabo em um ciclo sem fim, tentando corrigir bugs que nem deveriam existir, e bugs que já foram corrigidos várias vezes e que passam de mão em mão.

Pior que um líder medíocre é ter pessoas que não se importam se seu “grande código à prova de falha” quebrar em produção.

Se você ainda quer se salvar, leia este artigo sobre: Rant: Projetos, TESTES e Estimativa???

Pontos importantes:

• Sua estimativa da tarefa deveria contar com a tarefa e os testes.
• Se você tem a possibilidade de fazer testes e mesmo assim não faz, seu trabalho ainda é tão medíocre quanto você.
• Falar que o projeto já está há meses ou até anos sem nenhum teste é o cúmulo da preguiça.

Sempre gostei de testes unitários, integração, e tive que aprofundar mais, quando fiz um trabalho pela minha empresa durante um ano em testes manuais e automatizado em um e-commerce escrito em React Native.

Os problemas no fim das contas, são sempre os mesmos: Fluxos complexos, tempo de execução, dispositivos diferentes, sistemas operacionais diferentes, ambiente diferentes e problemas que surgem por causa de versão do dispositivo, do S.O, da linguagem nativa, da linguagem utilizada de alto nível, arquitetura, e etc…

Eu não vou abordar todos os pontos, mas vou selecionar um específico.

Testes unitários não é uma bala de prata

Houve um tempo que como líder técnico, eu decidi deixar o Jest num projeto NextJS com 90% de coverage para todo novo módulo.

Essa era uma das muitas vantagem de ter um Monorepo, se você tem um projeto em andamento, e ele tem 30, 40, 50% de coverage em todo o projeto, você pode trabalhar com módulos completos como um package, e exigir que seja um coverage alto. até mesmo se você achar que o módulo Y não precisa ter tanto testes, por ser algo interno, ou uma prova de conceito, você pode abaixar, ou até anular para aquele package, sem influenciar todo o projeto em volta que está sendo melhorado.

Um exemplo desse bom funcionamento, é uma aplicação de delivery, onde cada parte do App era administrado por uma squad. Pelo menos no contexto do Android, o carrinho era um .jar com seus gerenciamento de estado, fluxos, e etc. Assim era mais fácil de gerir um módulo especialista ou até simplesmente descartar ele por completo, sem se preocupar com arquivos perdidos no resto da aplicação.

Dessa forma, eu consegui com que diminuisse drásticamente a quantidade de issue aberta por causa de erros de renderização ou informações que não deveriam aparecer de tal forma.

Estes testes não cobrem coisas visuais, alinhamento, fontes, e outros erros no desenvolvimento de Frontend, para isso existe outras ferramentas, e não é disso que quero abordar hoje.

Um dos motivos de eu ter decidido parar de exigir um nível tão alto de coverage, foi ver que embora as issues referentes a quebras de componentes e módulos terem diminuido, não garantia a integração nas aplicações.

Como posso saber que ao alterar um módulo de verificação de disponibilidade de um produto vai funcionar no App X, e quebrar no App Y ? Todas as funcionalidades estão normais, a API não mudou, tenho 90% de coverage, e o meu Storybook mostra todas as definições.

A reposta é simples: O teste unitário não leva em conta o contexto.

Embora as ferramentas evoluam, e esteja mais próximo do comportamento real do user (como o Testing Library), ainda não é um fluxo integrado, e sim uma unidade, por isso, advinha advinha, teste UNITÁRIO.

Então, vamos avaliar os problemas:

Problemas e Soluções

Para cada desafio aqui, vai ser um pequeno tópico.

Nestes exemplos, não se preocupe com qual ferramenta eu vou mencionar, qualquer uma que resolve esses problemas, vai ser a melhor. Isso é atemporal.

Login externo

O fluxo era mais ou menos simples, eu entrava na aplicação, me redirecionava para a página do Auth0, eu validava o network do client, colocava login e senha (use variáveis de ambiente), era redirecionado e fazia o snapshot dos cookies.

Isso era feito no setup global do Playwright, é bem similar ao cypress. Eu conseguia entrar em todas páginas logado, com esse unico setup global.

Reutilização

É muito comum repetir fluxos durante vários testes, e os testes ficarem grande.

Pense em DRY (do not repeat yourself). Imagine que você precise de criar um produto, então você terá duas classes.

• BaseTest
• ItemTest

ItemTest herda de BaseTest, então no BaseTest você terá o browser headless, e poderá fazer qualquer coisa.

Se para criar o produto, você precisa: Navegar para inventário -> clicar em criar -> preencher X, Y e Z -> Clicar em Salvar -> Produto deve aparecer na lista de produtos.

Você não precisa ter tudo no arquivo spec, no BaseTest você tem o “navegar para” (vai ser igual para todos), e para cada “preencher Y”, “preencher X” é um método da classe ItemTest. Então seu teste ficaria simples:

const item = new ItemTest()
const name = Faker().name // Use aqui para verificar se está na tabela 

item.fillTitle(name) // se quiser pode ter internamente um Faker::name
item.fillDescription()

await page.waitForSelector(`tr >> text=${nameOfItem}`)

const findItemInTable = await page.$(`text=${nameOfItem}`)

// Valide
expect(findItemInTable).toBeTruthy()

Deste jeito, se você precisar mudar algo do fluxo, você concentra os selector e ação em um único lugar.

Utilize boas práticas da sua ferramenta de teste, mas tente atender esse problema, por que quando você tiver 700 testes de integração, como hoje no backend temos, será horrível ter que atualizar todos testes que ficaram outdated.

Mitigue esse problema o máximo possível.

Reutilização de HTTP

No Ruby on Rails, utilizamos VCR, uma ferramenta nascida em 2010 e que funciona perfeitamente até hoje. O nome no Playwright se chama HAR ( HTTP Archive ).

Você não precisa SEMPRE chamar o backend, você precisa que com a resposta do Backend, a sua funcionalidade funcione sempre, mesmo que modifique o componente. É isso, não inventa.

Se vai mudar algo no Backend, por exemplo, na criação de produto, agora existe uma nova validação, onde o produto tem pode ou não aparecer no Marketplace, então sim REGRAVE os HAR.

Lembre que o importante é fazer com que a integração do Frontend funcione.

Não utilizar HAR, gera pode gerar vários problemas como: Rate limit, um teste pode corromper outro (concorrência ou ordem de execução pode excluir ou inativar um produto que no próximo teste irá precisar) e longo tempo de execução ( Tempo da tarefa + Resposta das requisições )

Começar pelo meio, não pelo começo

Em certa altura, você pode precisar ter um produto, reservado para um cliente, para os próximos dois dias, e pago.

Só que para isso, você precisa ter um item novo (para não ter erro de ordem de execução ou concorrência), criar a ordem, adicionar o produto, a data, o cliente e mover para estado de reservado. Isso pode gerar um tempo desnecessário de execução, por que você pode ter 20 testes que valida a partir deste ponto.

Então é hora de começar a usar helpers (fixtures/support), e criar classes ou funções que utilizam os serviços que você já usa no frontend (Redux, axios, fetch, tanstack, ou qualquer outra ferramenta), para deixar um ambiente pronto para começar a partir daquele ponto. Talvez você precise fazer umas 2 ou 3 request: Criar produto, Criar ordem já com o produto, data, cliente, e outra para trocar o estado da reserva.

Agora você tem o que é necessário para iniciar o teste, e validar o que for necessário validar.

Existe formas mais fáceis, caso o backend fosse mais perto do frontend, como criar service container no github actions e criar usuários específicos para cada situação, mas nem sempre é assim. O backend vai ser em Java, C#, PHP, Ruby, então prefiro que os testes sejam sempre independente do Backend.

Multiplos frontend web com testes integrados

Este deixei por ultimo, por que precisa entender os problemas anteriores.

Talvez seja necessário inativar um cliente, e todos produtos dele no marketplace não apareçam mais. Então é necessário navegar para outra página. Acredito que todas ferramentas populares, como Playwright, Cypress, Selenium atenda esse requisito, é basicamente alterar o endereço. Porém o bom uso do DRY, como eu disse anteriormente vai ajudar a não ter que perder fluxo que você já criou.

Se você já consegue achar um dono de produto, ou achar um produto pelo dono dele, nos testes do seu e-commerce / Marketplace, você pode reutilizar esses teste e esperar que eles falhem.

A gente se vê, até mais!

Mas vamos ao ponto principal, e não espere uma solução mágica vindo deste post, por que o limite dele, é meu conhecimento.

Minha empresa não faz testes, o que fazer?

Vários fatores cria esse ambiente, falta de prioridade, produto interno que não tem grande prioridade, falta de senioridade do líder (existe líderes junior, acreditem), entre outros…

Todos esses fatores não justificam que o pedaço que você está construindo, seja feito de qualquer forma, igual aos outros membros.

Lugares “flexíveis”

Em alguns casos, onde não se é proibido (sim, existe esse local) criar testes no projeto e for algo totalmente opcional, você pode importar apenas seu trecho, e validar a função ou a classe que criou.

Nestes casos, vai ser mais fácil para Mid-level, já que eles fizeram testes, ou tem uma facilidade em ler uma documentação. Sinto de dizer que para muito juniors, vai ser uma experiência ruim, já que vai ter que fazer sozinho (caso realmente ninguém se importe com testes), e quando falhar, vai ser um pouco decepcionante, caso for outra pessoa que quebrou e não validou.

Pode também ser considerado uma pessoa mais lenta para fazer funcionalidades. Mas considere um seguinte ponto, é melhor ser conhecido por fazer um pouco mais lento que outros, e fazer apenas uma vez, do que fazer rápido e estar sempre voltando por causa de problemas.

No final, eu sempre vou aconselhar seguir com testes, sempre foi minha opinião, e nunca me impediram isso, mas tenho amigos que já bloquearam ele e poderia custar o emprego. Sinceramente, segure seu emprego e aprenda coisas por fora, até encontrar um ambiente melhor.

Lugares não flexíveis

Como eu disse no texto anterior, existem lugares onde realmente não querem que você perca tempo criando testes, porém, vão te cobrar se não funcionar corretamente, exigindo um teste manual.

Neste caso, no Backend (na minha opinião), será mais fácil resolver, por que você pode usar localmente um modelo Behaviour Driven Development, onde você precisa trabalhar com API’s, e então seus testes locais vão fazer requisições, e você pode no final validar as resposta 200, 400, 422, etc…

O Frontend é pra mim, muito mais difícil fazer esse isolamento. Vou dar um exemplo de uma parte do fluxo da empresa onde eu trabalho.

Se eu quiser testar a disponibilidade de um produto, dentro de uma reserva, eu preciso: Ter um produto criado (com preço, configuração de estoque, fotos, descrição), ter uma reserva (com cliente, data), o cliente precisa ter parametros cadastrados, e enfim adicionar tudo a reserva e então validar com testes de end-to-end. E tem o risco de alguem alterar parte do fluxo, e quebrar seu teste.

Claro que não nos encaixamos neste cenário, mas como eu já disse, tenho amigos que passaram por isso.

Falta de senioridade

Esta talvez seja a mais desafiadora no começo, quando você nunca teve uma experiência com testes, quer implementar, mas nem você e nem seus colegas tem conhecimento. (Aqui, eu só conheço 1 pessoa, onde ele é o lider, e tem pouco tempo de experiência, e tem apenas 1 desenvolvedor com ele.)

Neste caso, tente você ler sobre testes, divide seu tempo com vídeos e artigos que ensinam como fazer no ambiente próximo ao seus, e no final puxa um workshop para que todos consigam aprender um pouco contigo. Não espere que outros façam, vai e faz.

Tente pedir ajuda de alguém experiente em colocar verificação de testes na pipeline, caso você não souber.

Não tenho muito o que dizer além disso, é sentar na cadeira de noite, e estudar para resolver o problema.

Afinal de contas, Então o que fazer ?

Não tem o que fazer para mudar o agora, mas normalmente esses tipo de lugares, muito das vezes, quebra fluxo quase o tempo todo. Aí é sua hora de brilhar, na reunião fala que é possível resolver com testes unitários, end-to-end, de integração. Mostra seu projeto pessoal como você fez isso.

Óbvio, não é sempre que vão te dar a medalha pela brilhante idéia, mas insiste, em outras reuniões, que certamente vai ter fluxo quebrando, diz que é possível resolver.

Tenha cuidado ao dizer, e quando dizer. Imagina que o fluxo quebrou em um cliente importante, perderam uma oportunidade muito boa, ou uma considerável, e ele recebeu reclamação, e então vai repassar isso pro Sênior ou Lead. Ai você, um bom menino vai falar: “Olha, testes resolveria esse caso.”.

Talvez seja uma experiência que você nunca vai ter, mas não tira a possibilidade de você mostrar para seu Lead ou Sênior a importância.

Outra coisa que você pode fazer ( mesmo sendo junior ), é pedir para criar uma meeting de 15 a 20 minutos, sobre testes, e como você faz. Você não precisa ser o melhor testador de software do planeta, sua soft skill de melhorar a qualidade da sua entrega, vai ser compensada em ajuda de desenvolvedores mais experientes.

Considerações finais

Este artigo não é um paper ciêntifico, então, não tem referências. Assim como a maioria dos livros, é apenas minha experiência pessoal.

Não espere que seus esforços para mudar as coisas, vão acontecer. Mas sempre espere que seu conhecimento adquirido em criar algo com qualidade, seja um fruto de emprego, salário e considições melhores.

Não pense que foi em vão, todo seu esforço. Em uma entrevista, mostrar que você viu algo errado, e tentou melhorar, é um ótimo ponto.

Uma recomendação não técnica, é ler o livro do Pete Goodlife: Como ser um Programador Melhor: um Manual Para Programadores que se Importam com código.

Instabilidade gera milhões em prejuízo, e nós como desenvolvedores precisamos saber como mitigar esse tipo de problema. Esse assunto acaba indo para algumas tangentes que leva desde a experiência do usuário, observabilidade, e escalabilidade horizontal com orquestração de containers.

Mas um assunto muito básico e útil, é o uso de Background Jobs.

Entendendo o problema

Eu fiz uma experiência recentemente com Node HTTP, e mesmo que não deixamos de receber requisições no Node, por utilizar o Event loop pattern e o Event Emitter, cada processo síncrono precisa ser processado um de cada vez. Então se eu tenho um processo que exige mais CPU, e pare o processo de resposta, outras chamadas vão dar timeout ou simplesmente, crashar. ( Veja a referência 4 )

Essas tarefas podem ser:

• enviar e-mails

• processar imagens e vídeos

• Acionar webhooks ou fazer solicitações a terceiros

• Reconstruir índices de busca

• Importar grandes conjuntos de dados

• Limpar dados obsoletos

Por que usamos Background Jobs?

Background Jobs são usados para diminuir o trabalho excessivo da sua aplicação principal. Independente da linguagem que você esteja utilizando, o processo feito será fora do ciclo de vida da sua aplicação.

Hoje em dia uso Ruby on Rails e NestJS, tanto um como o outro podem delegar uma tarefa para ser executada, por exemplo processar alguma imagem na Azure, essa tarefa é armazenada um UUID no Redis, e um Worker – ou seja, um novo processo separado – irá processar (na mesma ou em outra máquina), e depois preencher o resultado e emitir que foi concluido para aplicação principal. Então a aplicação principal poderá enviar um email de sucesso, mudar um campo no banco de dados, ou enviar uma mensagem via websocket. A implementação pode mudar, também como o uso da tecnologia também pode, por exemplo como usar banco relacional para guardar os jobs ( veja a referência 6). Mas o importante aqui, é o uso dessa implementação, e não da tecnologia utilizada.

Implementações

O conceito de multi-tarefa vem evoluindo desde 1950, então com certeza hoje temos soluções buil-in nos frameworks Backend.

No Rails podemos usar o Sidekiq, ou o mais novo ActiveJobs ( referência 9 )

O NestJS, por ser mais um wrapper, ele abstrai o package (BullMQ)[https://github.com/taskforcesh/bullmq]

Ambos são fáceis de usar, sabendo do problema que isto resolve, e o modo Rails e Nest de resolver sua estrutura.

Espero ter ajudado, e fique a vontade para ler os links de referências.

References

1 - https://shopify.engineering/high-availability-background-jobs

2 - https://www.servertribe.com/kubernetes-alternatives/

3 - https://nodejs.org/en/guides/dont-block-the-event-loop

4 - https://blog.platformatic.dev/the-nodejs-event-loop

5 - https://docs.abp.io/en/abp/latest/Background-Jobs

6 - https://planetscale.com/blog/distributed-caching-systems-and-mysql

7 - https://docs.nestjs.com/techniques/queues

8 - https://learn.microsoft.com/en-us/azure/well-architected/reliability/background-jobs

9 - https://edgeguides.rubyonrails.org/active_job_basics.html

Já faz uns meses que eu não tenho escrito nada, e nem feito twitch ou lives no Youtube. Isso tem me chateado um pouco, por que é algo visível da minha evolução de explicar algumas coisas que tenho curiosidade. Exclusivamente para isso, pois nunca olhei números de views de meus vídeos, e nem tenho atualmente analytics no meu blog.

Este artigo vai documentar um pensamento, e espero que ajude a ver as coisas desse modo, concordando ou não.

Frameworks

Hoje todos nós temos um leque de frameworks como o NestJS, Adonis, Express, Fastify, Koa, Hapi, etc…

Fora os ORM (TypeORM, Prisma, Knex, etc…), Testing library, etc…

No mundo Javascript, isso é bem normal, né ? “Não gosto da biblioteca X, vou construir uma totalmente nova e diferente, por que do meu jeito é melhor”. Daí percebemos uma divisão na comunidade.

Background

Normalmente quando eu penso em Java, penso Spring e Hibernates, quando penso C#: .NET MVC e Entity Framework, Ruby: penso em Rails e PHP penso Laravel e Eloquent.

Essas ferramentas (entenda que são ferramentas) não são bala de prata, mas padronizam os projetos.

Veja por exemplo o caso do Ruby on Rails, e da própria comunidade Rails. A mentalidade é completamente diferente, as coisas já foram resolvidadas a tanto tempo, que não é necessário ficar recriando as coisas.

“Ah, e se eu quiser escalar”, Rails escala mesmo com arquitetura monolito. (Veja o caso Spotify com Rails Engine)[https://shopify.engineering/shopify-monolith]

Não é necessário recriar ORM, se existe algum problema no ORM Active Record, bora lá abrir uma issue, abrir um PR, e resolver o problema. Sinceramente, isso mudou meu pensamento. ( olha que eu amo criar Open Source )

Realmente, tem coisas que não precisa ser criadas, e um PR resolveria.

O Tempo

O ponto alto da produtividade, é usar ferramentas que existe há um tempo, que já resolve o mesmo problema há tempo.

O melhor Framework, ORM, Biblioteca de testes em pleno 2024 não deveria ser a pergunta para iniciar um projeto. e na verdade, convention over configuration já existe desde antes de 2005.

O AdonisJS traz isso ao Backend NodeJS desde 2015. Não estou dizendo que vai resolver todos seus problemas, mas repito que essas decisões não deveria existir no começo da construção de software.

Ferramentas novas, ainda não sofreu suficiente no mundo real, para se por a prova. Você não vai mudar tudo de Node para Bun, Denos, “por que sim”. Muito menos mudar de TypeORM, Sequelize, Lucid que já existe há anos para Prisma “por que sim”.

Se você se pergunta, “será que devo…?” Não, primeiro resolve seu problema com algo que já existe, quando “bater na parede”, você pensa em mudar.

Arquitetura de pastas?

Por que não existe um consenso? você vai para uma empresa, utilizam DDD, sem convenção, e ás vezes você se pergunta se os devs implementaram eram Domain Driven Design ou Directory Driven Design. Outras vão usar Clean Architecture, com seus use cases, etc… Só que Clean Architecture na empresa A, não é igual na empresa B.

Você perde tempo, perde produtividade, e as vezes você trabalha debaixo de uma arquitetura de como o líder acredita ser a correta.

então novamente, convention over configuration.

Performance

O desempenho da sua aplicação, depende muito mais de você e da sua infraestrutura, do que do seu código. O seu conhecimento sobre SQL e banco de dados, deveria ser superior ao qual é o ORM de qualquer framework do momento.

Tenha um pensamento crítico, por exemplo: Deveria usar um framework MVC na Azure Functions? (ou Google Functions, AWS lambda, etc.. ?) Claro que não, Serveless não é pra isso.

Pensa em iniciar com performance, se você está num contexto onde já existe um negócio, com milhares de usuários, com problemas acontecendo a cada X tempos, e essa aplicação é pra tirar o gargalo de outros serviços.

Trabalho em equipe

A melhor coisa de convention over configuration, é trabalhar em equipe.

Você consegue trocar de contexto entre projetos, de forma uniforme e com foco na entrega de valor.

Entrega de valor

Eu simplesmente amo essa parte.

Você faz o start do seu projeto, e já ataca o negócio / solução.

Esquece qual é a melhor tecnologia para X, Y, Z. ( pense no que eu disse sobre performance )

Isso não se aplica somente a framework e bibliotecas.

Olha esse seguinte caso:

Caso: Processando dados em massa

Tenho um monolito, onde tudo está correndo tudo bem.

Recebo uma demanda para trabalhar com arquivos Word, Excel com validações, etc… Podemos trabalhar com Node Streams para resolver isso. A limitação não seria a linguagem.

Mas como andam as bibliotecas que resolvem isso ?

Se isso resolvesse rápido com C# ? Bibliotecas já implementadas, todas mantidas pela Microsoft.

Somos pagos para resolver problemas com as ferramentas certas, de forma produtiva.

Conclusão

Não tem uma conclusão, Conhecer arquiteturas não é o mal.

Os pontos foram focados em eficiência na entrega de valor.

Referências

https://www.mindtheproduct.com/overengineering-can-kill-your-product/

https://rubyonrails.org/doctrine

Seja um desenvolvedor experiente buscando solidificar seu entendimento ou um novato tentando compreender os fundamentos, este repositório tem como objetivo fornecer insights que desmistificam as complexidades da estilização no desenvolvimento web.

Começaremos explorando os conceitos fundamentais que sustentam como os navegadores renderizam o conteúdo e aplicam estilos. Este conhecimento servirá como um bloco de construção crucial para entender tópicos mais avançados, como SSR, e as compensações ao usar abordagens de estilização específicas.

À medida que avançamos, percorreremos diferentes cenários e exemplos que esclarecerão o comportamento dos navegadores, o papel do JavaScript na renderização e as implicações do uso de soluções CSS-in-JS, como o styled-components. Também discutiremos os desafios de implementar SSR com essas ferramentas e forneceremos insights sobre alternativas mais adequadas para estilos renderizados no servidor.

Ao final desta jornada, você terá adquirido uma compreensão abrangente dos mecanismos envolvidos na renderização de conteúdo e aplicação de estilos na web. Se você escolher adotar metodologias tradicionais de CSS, explorar módulos CSS ou trabalhar com bibliotecas modernas como o styled-components, estará equipado com o conhecimento necessário para tomar decisões informadas que atendam aos requisitos de seus projetos.

Vamos embarcar nesta exploração da estilização e renderização no mundo do desenvolvimento web, desvendando a magia nos bastidores e compreendendo as opções disponíveis para nós como desenvolvedores.

Repositório

Aqui eu deixo bem mais explicado meu deep-dive sobre estilização inline, em arquivos CSS e em bibliotecas como o styled-components, inclusive utilizando desde vanilla, até os frameworks mais populares como o Next, Remix, etc…

Link para o repositório: https://github.com/castro-research/research-styled-components-behaviours

O Problema 1

Em desenvolvimento, quando se importa um componente de um index (por exemplo no diretório components/index2.ts) com outras exportações, o webpack gera o bundle com todos os componentes exportados no index.

No nosso screens/Home_1.tsx, temos um exemplo, onde só está sendo usado o componente Modal e em development, o bundle gerado é o seguinte:

O Dialog pesa 1mb, e o Modal uns 3kb, mas o bundle gerado tem 1.03mb, pois o webpack gera o bundle com todos os componentes exportados no index.

Imagina uma página com um Design System inteiro importado, vai ficar super pesado e lento.

O Problema 2

Se você fizer o uso do Dialog, ao invés do Modal, no NextJS, o browser vai tentar renderizar os 1mb do Dialog via Server Side Render, e na hidratação, irá carregar de novo os 1mb do Dialog.

O Problema em produção

Introdução

Em produção, quando se importa um componente de um index com outras exportações, o webpack gera o bundle apenas com o componente importado.

Porém o Problema 2 do ambiente de desenvolvimento, continua em produção.

A Solução do Problema 1

Este problema vai te atrapalhar mais em desenvolvimento, pois em produção, o webpack gera o bundle apenas com o componente importado.

Então, se você importar apenas o componente que você vai usar, o bundle gerado será apenas com o componente que você importou.

por exemplo, ao invés de importar:

import { Modal } from '@/components'

Seria melhor importar:

import { Modal } from '@/components/Modal'

Porém, se você está criando package local, ou alguma pasta global, onde você não quer ficar importando todos os componentes, você pode usar o import dynamic do NextJS, citado na solução do Problema 2.

ou você pode utilizar o React Lazy, que também vai resolver o problema.

O Resultado vai ser esse:

Repara também que o App foi carregado mais rápido e depois foi feito o carregamento do Dialog, que é o componente que foi importado.

A Solução do Problema 2

Existe uma solução bem simples que resolve o problema 2, que é o uso do dynamic import do NextJS.

O dynamic import, faz com que o componente seja carregado apenas no client side, e não no server side.

Isso então vai evitar que o Dialog seja renderizado no server side, e na hidratação, o Dialog não será carregado de novo.

você pode encontrar a implementação no arquivo screens/Home_1.tsx

O Resultado vai ser esse:

Fallback

O fallback é uma propriedade do dynamic import, que pode ser usada para renderizar um componente de loading enquanto o componente é carregado.

Já que o dynamic não usa mais o você pode usar a propriedade loading, e renderizar via server side render, um componente de loading ou um skeleton.

Exemplo:

import dynamic from 'next/dynamic'

const Modal = dynamic(() => import('@/components/Dialog'), {
  loading: () => <div>Carregando...</div>
})

Disclaimer

O then usado no dynamic em screens/Home_1.tsx é apenas por que:

1 - Todos imports de arquivos são assincronos 2 - O @/components exporta componentes individuais, ao invés de export default { ... }

Como está sendo usado:

const Dialog = dynamic(() => import('@/components').then((components) => components.Dialog()), {
  ssr: false,
  loading: () => <div>loading...</div>
})

Se por acaso você usar com export default { ... }

export default {
    Modal: () => import('./Modal'),
    Dialog: () => import('./Dialog'),
}

Exemplo em components/index3.ts

Você pode usar o dynamic assim:

const Dialog = dynamic(() => import('@/components').then((components) => components.default.Dialog()), {
  ssr: false,
  loading: () => <div>loading...</div>
})

Observação: Mudou de 1mb para 500kb por que? Após passar o minified code, o Dialog ficou com 500kb.

Por que? Todo export default é retornado como default, então você precisa acessar o default para acessar o componente.

Se você fizer um console, vai ver algo assim:

{
    __esModule: true,
    default: {
        Modal: () => import('./Modal'),
        Dialog: () => import('./Dialog'),
    }
}

e caso você manter os export const, você terá:

{
    __esModule: true,
    default: {
        Modal: () => import('./Modal'),
        Dialog: () => import('./Dialog'),
    },
    Modal: () => import('./Modal'),
    Dialog: () => import('./Dialog'),
}

Conclusão

O problema 1, pode ser resolvido apenas importando o componente que você vai usar, ou usando o dynamic import.

O problema 2, pode ser resolvido apenas usando o dynamic import.

Sugiro também que veja uma solução melhor que vá ter menos problemas, que é o uso do babel-plugin-transform-imports, que vai fazer o uso do dynamic import automaticamente.

https://www.npmjs.com/package/babel-plugin-transform-imports

Referências

https://nextjs.org/docs/advanced-features/dynamic-import

https://www.freecodecamp.org/news/code-splitting-in-react-loadable-components/

https://webpack.js.org/guides/code-splitting/

https://developer.mozilla.org/en-US/docs/Glossary/Code_splitting

https://nextjs.org/learn/foundations/how-nextjs-works/code-splitting

https://nextjs.org/learn/foundations/how-nextjs-works/client-and-server