The latest articles on DEV Community by Matheus Silva (@matheusdsilva01). https://dev.to/matheusdsilva01 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F888049%2F3a8d486c-5764-4515-a75b-956dfa223f4e.webp https://dev.to/matheusdsilva01 en Matheus Silva Fri, 21 Aug 2026 19:37:54 +0000 https://dev.to/matheusdsilva01/feature-based-por-que-sua-pasta-components-virou-uma-bagunca-51lc https://dev.to/matheusdsilva01/feature-based-por-que-sua-pasta-components-virou-uma-bagunca-51lc <p>Acho que todo dev já passou pelo momento de se deparar com um projeto e se perder no meio de tantos arquivos. Isso pode ser resultado de N fatores, e um deles pode ser a forma como o projeto está organizado.</p> <p>Falando especificamente de frontend, quando criamos um projeto do zero em qualquer framework, ele vai lhe entregar uma estrutura padrão, chamada de <code>Type-based</code> em que você consegue desenvolver coisas simples, nada muito complexo ou escalável. Você vai conseguir seguir essa estrutura inicial e entregar as features necessárias, e é isso.</p> <p>Até certo ponto, beleza: tudo funciona, você consegue se localizar entre as pastas e arquivos. Aí você vai integrando mais endpoints da API, adicionando features, novos fluxos, e então as coisas ficam entrelaçadas, distantes e muito desorganizadas. Implementar uma feature nova já não é tão simples, e se localizar é pior ainda.</p> <h3> Por que essa dor? </h3> <p>Isso foi uma experiência própria que vivi em projetos que desenvolvi, e que despertou minha curiosidade sobre como estruturar melhor meus projetos. Aí encontrei algumas possibilidades de arquiteturas, como DDD, Clean Architecture, MVC e Micro-frontend. Mas muitas delas eram voltadas para projetos backend, eu não via com bons olhos trazer isso para o frontend moderno e também me pareciam soluções muito complexas para algo simples.</p> <h3> Uma solução... Simples? </h3> <p>Foi aí que encontrei uma solução chamada <code>Feature-based</code>. É uma abordagem que parece simples, em resumo: você pega seu projeto e quebra em partes. Que partes? Bom, aí pode ser por entidade, domínio, etc. Essa quebra traz algo interessante, que é a modularidade: seu sistema agora está mais desacoplado, cada parte passa a ser autogerenciável, tem sua própria responsabilidade e seu propósito bem definido.</p> <p>Dando um exemplo visual antes de seguirmos:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>src/ ├── features/ │ ├── movies/ │ │ ├── components/ │ │ ├── hooks/ │ │ ├── api/ │ │ └── types/ │ ├── comments/ │ │ ├── components/ │ │ ├── hooks/ │ │ ├── api/ │ │ └── types/ │ └── auth/ │ ├── components/ │ ├── hooks/ │ ├── api/ │ └── types/ ├── shared/ │ ├── components/ │ ├── hooks/ │ └── utils/ └── app/ ├── routes/ └── layout/ </code></pre> </div> <h3> Prós e contras </h3> <p>Os prós? <strong>Organização</strong>: Você consegue identificar com facilidade onde trabalhar. <strong>Testabilidade</strong>: Seus fluxos de testes de e2e, integração e unitários ficam melhor localizados. E <strong>escalabilidade</strong>: Surgiu um fluxo novo? Para qual feature? Altere o código na pasta da feature que vai receber a implementação. Surgiu uma feature, entidade nova? Literalmente crie uma pasta nova em features... ou não. Acredito que aqui é um bom momento para falar dos contras.</p> <p>Dando um contexto para facilitar o entendimento: imagine um cenário em que vamos adicionar os nomes das empresas produtoras na página de detalhes de um filme. Primeiro pensamento: nova entidade <code>companies</code>, logo vamos criar uma pasta nova de <code>companies</code> em features. O backend vai ter um endpoint <code>/companies?movie_id=?</code>, jogamos isso dentro de <code>companies</code> e <code>movies</code> vai importar o que for necessário dali. Resolvido, isso está errado? Não, é um excelente caminho e segue os requisitos para ser uma feature nova no projeto. Mas, nesse momento, é somente uma chamada para a API que retorna uma lista simples. Outra possibilidade, que também não estaria incorreta, é um simples <code>getMovieCompanies</code> dentro de <code>features/movies</code> — nesse momento é aceitável. Mas, caso <code>companies</code> ganhe mais fluxos e telas no projeto, aí o próximo passo é mover essa lógica para dentro de <code>features/companies</code>.</p> <p>"Como isso se encaixa em um contra?" Aqui entra o ponto de maturidade para tomar esse tipo de decisão de implementação e levar em conta os trade-offs — nesse caso, o trabalho de criar uma nova feature versus a simplicidade do momento, em troca de uma possível refatoração no futuro. Obviamente esse exemplo é bem simples, usado só para ilustrar um cenário que poderia acontecer em um projeto real.</p> <h3> Conclusão </h3> <p>Com a IA muito presente no dia a dia de desenvolvimento, acredito que ter essa preocupação com a estrutura do projeto é importante. Sem uma estrutura bem definida, é fácil um agente duplicar lógica sem você perceber e só acabar aceitando o que foi gerado porque, aparentemente, está tudo funcionando como esperado</p> <p>É isso, tem mais pontos que podem ser abordados como circular dependency, deep import, arquivos compartilhados mas isso já é um bom introdutório para pensar sobre como organizar seus projetos.<br> Se quiser se aprofundar mais sobre o assunto deixo aqui um pouco do que foi meu estudo sobre esse tópico contém alguns resumos e lições sobre testes, definição de features, discussões mais técnicas sobre implementação e você pode encontrar alguns exemplos de código sobre <code>Feature-based</code>: <a href="https://github.com/matheusdsilva01/learning/tree/main/learning-feature-based" rel="noopener noreferrer">https://github.com/matheusdsilva01/learning/tree/main/learning-feature-based</a></p> <p>Espero que isso tenha lhe incentivado a estruturar melhor seus projetos e tmj</p> <h3> Referências </h3> <p><a href="https://github.com/alan2207/bulletproof-react/" rel="noopener noreferrer">https://github.com/alan2207/bulletproof-react/</a></p> braziliandevs frontend architecture Matheus Silva Tue, 23 Jun 2026 19:30:46 +0000 https://dev.to/matheusdsilva01/porque-o-postgresql-e-tao-queridinho-3eh0 https://dev.to/matheusdsilva01/porque-o-postgresql-e-tao-queridinho-3eh0 <h2> Introdução </h2> <p>PostgreSQL é um dos bancos de dados relacionais mais populares no mundo por alguns motivos e tudo isso começou como um simples projeto de faculdade, hoje sendo a principal ferramenta adotada por grandes projetos e empresas no mundo.<br> E neste artigo vou dar um pouco de contexto de como ele alcançou esse posto.</p> <h2> <strong>Table of contents</strong> </h2> <ul> <li>Historinha</li> <li>Open source</li> <li>Extensões</li> <li>Confiabilidade</li> <li>Comparativo</li> <li>Conclusão</li> </ul> <h2> Historinha </h2> <p>Contando um pouco de historia, o PostgreSQL nasceu dentro da universidade de Berkeley nos Estados Unidos ja com o objetivo em extensibilidade e suporte a tipos de dados complexos, como pesquisa científica inicialmente chamado de apenas Postgres. E foi crescendo, mais tarde tendo suporte para SQL sendo nomeado como PostgreSQL e lançado para web ganhando performance e mais manutenção.</p> <h2> Open source </h2> <p>O PostgreSQL não tem um único dono, hoje é mantido pela PostgreSQL Global Development Group um agromerado de empresas e desenvolvedores que contribuem para o projeto sem o poder de tomada de decisões de forma unilateral sobre o projeto.</p> <h2> Extensões </h2> <p>Graças a compatibilidade com extensões é possivel usar o PostgreSQL para vários propósitos algumas extensões famosas são:</p> <ul> <li><p><em>PostGis</em>: A possibilidade de processamento de dados geográficos e espaciais.</p></li> <li><p><em>pgvector</em>: Para uso de Inteligência Artificial o pgvector possibilita a busca vetorial em embeddings.</p></li> </ul> <h2> Confiabilidade </h2> <p>A partir de 2001 se tornou ACID(Atomicidade, Consistência, Isolamento e Durabilidade) garantindo segurança, robustez e confiabilidade para os usuários. Também possui mecanismo de MVCC(Multi Version Concurrency Control) para não bloquear ações de leitura e escrita otimizando paralelismo e garantindo performance em ambiente com grande tráfego.</p> <h2> Comparativo </h2> <p>Mesmo levando em consideração outras opções conhecidas do mercado como MySQL, Oracle e até mesmo não relacional como MongoDB, PostgreSQL ainda tem uma grande aceitação para uma aplicação que seja pequena ou grande porte.</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Critério</th> <th>PostgreSQL</th> <th>MySQL / MariaDB</th> <th>MongoDB</th> <th>Oracle DB</th> </tr> </thead> <tbody> <tr> <td><strong>Paradigma</strong></td> <td>Relacional (Objeto-Relacional)</td> <td>Relacional</td> <td>Documento (NoSQL)</td> <td>Relacional</td> </tr> <tr> <td><strong>Licença</strong></td> <td>Open Source (Permissiva)</td> <td>Open Source (GPL) / Comercial</td> <td>Source-available (SSPL)</td> <td>Proprietária (Muito cara)</td> </tr> <tr> <td><strong>Extensibilidade</strong></td> <td>Excelente (UDFs, Extensions, FDW)</td> <td>Limitada</td> <td>Limitada</td> <td>Excelente, mas proprietária</td> </tr> <tr> <td><strong>Suporte a JSON</strong></td> <td>Excelente (<code>jsonb</code> indexado)</td> <td>Bom</td> <td>Nativo</td> <td>Bom, mas complexo</td> </tr> <tr> <td><strong>Principais Usos</strong></td> <td>Sistemas financeiros, IA, GIS, aplicações robustas de qualquer porte</td> <td>Aplicações web tradicionais, WordPress, e-commerces simples</td> <td>Protótipos rápidos, catálogos flexíveis, dados semi-estruturados</td> <td>Grandes corporações legadas, ERPs de altíssima escala</td> </tr> </tbody> </table></div> <h2> Conclusão </h2> <p>Se você precisa de segurança, flexibilidade e robustez, o PostgreSQL faz por merecer esse posto de queridinho.</p> database braziliandevs postgressql software Matheus Silva Mon, 20 Apr 2026 19:20:05 +0000 https://dev.to/matheusdsilva01/o-basico-para-gerenciar-e-se-proteger-de-vulnerabilidades-em-dependencias-no-seu-projeto-node-3gnk https://dev.to/matheusdsilva01/o-basico-para-gerenciar-e-se-proteger-de-vulnerabilidades-em-dependencias-no-seu-projeto-node-3gnk <p>Verificar e eliminar vulnerabilidades em dependências pode ser mais simples do que você imagina e lhe garanto que isso pode salvar seu tempo e te livrar de algumas dores de cabeça no futuro.</p> <p>Antes de tudo, é importante saber gerenciar as dependências do seu projeto e entender como o seu gerenciador de pacote faz uma parte do trabalho para você, nesse artigo vou abordar os seguintes tópicos:</p> <h2> <strong>Table of contents</strong> </h2> <ul> <li>SemVer</li> <li>Relação entre package.json e package-lock.json</li> <li>Lidando com vulnerabilidades</li> <li>Conclusão</li> </ul> <p>Antes de falar sobre as vulnerabilidades em si, acho importante uma explicação básica sobre o que significa a sigla SemVer (Semantic Version) e como funciona a relação do <code>package.json</code>com o <code>package-lock.json</code> </p> <h2> SemVer </h2> <p>SemVer, ou Versionamento Semântico, é uma especificação para ajudar desenvolvedores a entender as mudanças e atualizações durante o versionamento de pacote.</p> <p>Uma versão de pacote é definida em 3 números <code>Major.Minor.Patch</code> (ex: 2.3.14), bom o que significa cada número desse:</p> <ul> <li>Major (2): Uma versão com atualizações que não tem compatibilidade com versões major anteriores. Então se você atualizar da 1.0 para 2.0 pode ser que isso cause algum problema quando você executar seu projeto, seja por alguma funcionalidade obsoleta ou alguma mudança na sua utilização, etc.</li> <li>Minor (2.3): Uma versão que adiciona recursos que tem compatibilidade com versões minor anteriores, ou seja, atualizações dentro da mesma versão major não devem quebrar seu sistema.</li> <li>Patch (2.3.14): Normalmente uma versão para lançar correções de bugs, vulnerabilidades e claro mantendo compatibilidade com versões de patch anteriores.</li> </ul> <p>Aqui não tem muito segredo, então quando você ouvir algo do tipo “tal pacote já lançou uma versão de patch(x) pra corrigir aquela vulnerabilidade da V14.3” é uma versão 14.3.x (entenda x como qualquer número).</p> <ul> <li>Intervalo de versões (^, ~)</li> </ul> <p>Algo fora dessa especificação são os sinais de circunflexo <code>^</code> e til <code>~</code> , que você comumente verá em projetos, são usados para definir intervalo de versões e sinalizar para o npm como ele deve lidar com as atualizações da dependência.</p> <ul> <li> <code>^</code> circunflexo</li> </ul> <p>Permite atualizações até versões minor mas não major, por exemplo: 2.3 pode atualizar para 2.4 mas por conta própria não vai fazer uma atualização de versão para major 3.x</p> <ul> <li> <code>~</code> til</li> </ul> <p>Permite atualizações apenas de versões patch dentro da minor especificada, por exemplo: 2.3.14 pode atualizar para 2.3.20. E claro não vai atualizar para uma versão 2.4</p> <p>Também é possível não especificar um intervalo de versões, dessa forma a instalação é fixada em uma versão e só pode ser alterada manualmente com uso do <code>npm install</code> por exemplo.</p> <p>Definir um intervalo de versões vai trazer mais segurança e praticidade quando precisar dependências mas caso precise de um controle mais rígido pode travar em uma versão sem problemas.</p> <h2> Relação entre package.json e package-lock.json </h2> <p>São arquivos que se completam. </p> <p>O <code>package.json</code> salva as dependências do projeto, é onde você vai ter um overview geral e pode definir o intervalo de versões.</p> <p>O <code>package-lock.json</code> é quem vai controlar a árvore de dependências e definir qual a versão exata que vai ser instalada, claro seguindo a referência definida no <code>package.json</code>, garantindo que todas as instalações tenham as mesmas versões de dependências, por isso é muito importante você manter o <code>package-lock.json</code> commitado/salvo no seu repositório além de deixar processo de instalação mais rápido vai dar consistência entre diferentes ambientes.</p> <h2> Lidando com vulnerabilidades </h2> <p>O npm nos forcene basicamente duas funcionalidades para identificar e resolver vulnerabilidades em nossas dependências.</p> <h3> npm audit e npm audit fix </h3> <p>Para verifica se as versões instaladas das dependências no projeto contém alguma vulnerabilidade conhecida, <code>npm audit</code> eu diria que é o primeiro passo. Executar esse comando no seu terminar vai gerar algo como:<br> <a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F0lo18ofkd9f4e2y3sbmc.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F0lo18ofkd9f4e2y3sbmc.png" alt="npm audit report" width="800" height="283"></a></p> <p>Nesse exemplo estou com a versão 16.1.6 do Next, aqui o relatório indica que nesse projeto só tenho vulnerabilidade nessa dependência e essa versão está dentro de um range de 6 vulnerabilidades conhecidas e como pelo menos uma delas tem gravidade de nível <code>high</code> a gravidade geral é essa, mesmo se algumas delas tiverem nível menor, também retorna links com mais informações sobre elas. </p> <p>Para eliminar essas vulnerabilidades, como no meu <code>package.json</code> defini o pacote do Next como <code>^16.1.6</code> (olha o ^) e existe uma correção para essas vulnerabilidades dentro desse intervalo de versão definido, isso permite que apenas executando <code>npm audit fix</code> ele atualize a dependência para uma versão sem vulnerabilidades.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Flzb4y0cmsdjedh2iwbuj.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Flzb4y0cmsdjedh2iwbuj.png" alt="npm audit fix report" width="428" height="95"></a></p> <p>Aqui foi feita uma atualização para <code>16.2.4</code> mas e se tivesse definido com <code>~</code> ? Fica aí a lição de casa.</p> <h2> Conclusão </h2> <p>Escrevi esse artigo com o propósito de fixação do conteúdo que estudei e deixo aqui alguns tópicos para se aprofundar sobre o assunto.</p> <ul> <li>Dependabot</li> <li>.npmrc (save-exact, audit-level)</li> <li>Snyk</li> </ul> <h2> Referências: </h2> <p><a href="https://www.youtube.com/watch?v=kK4Meix58R4" rel="noopener noreferrer">https://www.youtube.com/watch?v=kK4Meix58R4</a></p> <p><a href="https://semver.org/lang/pt-BR/" rel="noopener noreferrer">https://semver.org/lang/pt-BR/</a></p> <p><a href="https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json" rel="noopener noreferrer">https://docs.npmjs.com/cli/v11/configuring-npm/package-lock-json</a></p> braziliandevs npm javascript programming Matheus Silva Fri, 12 Dec 2025 21:22:10 +0000 https://dev.to/matheusdsilva01/controlando-cache-atraves-do-navegador-1h6j https://dev.to/matheusdsilva01/controlando-cache-atraves-do-navegador-1h6j <p><code>Cache</code> você já deve ter ouvido esse termo várias vezes e recentemente resolvi aprender como o navegador implementa esse mecanismo e então resolvi escrever esse post sobre o que aprendi.</p> <p>Contextualizando, <code>Cache</code> é um mecanismo utilizado com a finalidade de trazer velocidade ao acesso um conteúdo que é frequentemente utilizado.</p> <p>Quando estamos implementando cache em nosso sistema é importante mantê-lo o mais próximo possível do cliente e para isso podemos usar o sistema de cache dos navegadores assim mantendo velocidade no acesso ao conteúdo e salvando recursos de nossos servidores.</p> <h2> Tipos de cache </h2> <p>Para gerenciar cache no navegador usamos o header <code>Cache-Control</code> e podemos trabalhar com os seguintes valores para ele:</p> <p><code>default</code></p> <p>Por padrão o seguinte fluxo será seguido:</p> <ul> <li>Se for encontrada em cache uma versão atualizada dos dados essa será retornada.</li> <li>Caso seja obsoleta será feita uma espécie de consulta ao servidor e verificar se os dados do cache sofreram alterações, se sofreram alteração os dados atualizados vão ser retornados e atualizados no cache, caso contrário o dado do cache será retornado.</li> <li>Se não for encontrado nada em cache será feita a requisição ao servidor e o cache vai ser atualizado com os dados retornados.</li> </ul> <p><code>no-store</code></p> <p>O navegador vai ignorar o cache, efetuar a requisição para o servidor e não irá armazenar o retorno no cache.</p> <p><code>reload</code></p> <p>O navegador vai ignorar o cache, efetuar a requisição para o servidor e vai atualizar o cache com o retorno da requisição.</p> <p><code>no-cache</code></p> <p>O navegador verifica no cache se existe alguma versão atualizada dos dados ou obsoleta depois disso é verificado com o servidor se há uma nova versão dos dados, se houver será retornado a nova versão pelo servidor e o cache será atualizado, se não a versão do cache vai ser retornada.</p> <p><code>force-cache</code></p> <p>O navegador verifica o cache, se encontrar uma versão atualizada ou obsoleta dos dados ela vai ser retornada se não encontrar nada no cache ele vai fazer a requisição normalmente no servidor retornando os dados e salvando no cache.</p> <p><code>max-age=&lt;valor em segundos&gt;</code></p> <p>Pode ser usado em conjunto com os valores acima e define por quanto tempo aquele dado é definido como “atualizado”.</p> <p>Também e possível gerenciar o cache usando o header <code>Expires</code> que pode ser definido com um tempo específico, exemplo: <code>Expires: Thu, 25 Dec 2025 18:18:18 GMT</code> ou seja a partir do tempo especificado aquele dado passa a ser obsoleto.</p> <p>Esse foi o conteúdo que estudei espero que tenha agregado de alguma forma. 😊 </p> <p>Referências: <br> <a href="https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Guides/Caching" rel="noopener noreferrer">https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Guides/Caching</a><br> <a href="https://developer.mozilla.org/en-US/docs/Web/API/Request/cache" rel="noopener noreferrer">https://developer.mozilla.org/en-US/docs/Web/API/Request/cache</a></p> webdev browser programming web