Técnicas
Adote
-
À medida que o desenvolvimento de aplicações se torna cada vez mais dinâmico e complexo, é um desafio entregar produtos acessíveis e utilizáveis com estilo consistente. Isso é particularmente verdadeiro em organizações maiores com várias equipes trabalhando em produtos diferentes. Sistemas de design definem uma coleção de padrões de design, bibliotecas de componentes e boas práticas de design e engenharia que garantem produtos digitais consistentes. Uma evolução dos guias de estilo corporativos do passado, os sistemas de design oferecem bibliotecas e documentos compartilhados que são fáceis de encontrar e usar. Geralmente, as orientações são escritas em código e mantidas sob controle de versão para que o guia seja menos ambíguo e mais fácil de manter do que documentos simples. Os sistemas de design tornaram-se uma abordagem padrão ao trabalhar em equipes e disciplinas no desenvolvimento de produtos, pois permitem que as equipes se concentrem. Eles podem resolver desafios estratégicos em torno do produto em si sem reinventar a roda sempre que um novo componente visual for necessário. Nossas experiências mostram que as equipes raramente aplicam uma mentalidade centrada no produto ao construir sistemas de design. Os principais consumidores das bibliotecas e documentos compartilhados são as equipes de desenvolvimento de produtos. Ao aplicar uma mentalidade de produto, as responsáveis pelo sistema devem estabelecer empatia com os grupos consumidores internos (as equipes de desenvolvimento) e colaborar com eles. Descobrimos que o motivo de muitas bibliotecas de componentes serem criticadas, é porque a equipe responsável não foi capaz de fornecer aos grupos consumidores o que eles precisavam de maneira rápida o suficiente e também não estavam configuradas para receber contribuições externas. Uma mentalidade centrada no produto também requer que as organizações pensem em como as contribuições ao sistema de design devem ser feitas e como essas contribuições devem ser governadas - neste tópico, recomendamos aplicar a técnica Registros de Decisões do Sistema de Design. Para nós, administrar um bom sistema de design ou biblioteca de componentes requer tanto trabalho social quanto técnico.
-
O Request for Comments (RFC) é um documento formal que inclui ideias de design e arquitetura atreladas a um contexto para facilitar a colaboração e tomada de decisão das equipes. Quase todas as organizações que são nativas digitais e de alto crescimento usam RFCs para registrar as decisões sobre design, arquitetura, técnicas e as maneiras como suas equipes colaboram. Organizações maduras usam RFCs em equipes autônomas para promover uma melhor comunicação e colaboração, especialmente na tomada de decisão em conjunto. Eles são frequentemente usados como um processo para revisar e validar os registros de decisões de arquitetura. O resultado é um processo colaborativo transparente que permite que as pessoas afetadas pela decisão tenham a chance de contribuir e compartilhar feedbacks antes que a decisão seja aprovada. Muitas vezes, em ambientes de rápida mudança, os motivos que levam à tomada de decisão de design se perdem ao longo do caminho, e as equipes responsáveis pela implementação dessa decisão ficam sem saber o que fazer. Um RFC fornece um registro de auditoria de decisão que beneficia os membros futuros da equipe e documenta a evolução técnica e comercial de uma organização. Um RFC pode ser uma ferramenta valiosa para facilitar a arquitetura evolutiva. Entretanto, para obter o melhor resultado, recomendamos uma abordagem simples para RFCs. Se não forem de escopo e objetivo limitados, esses documentos tendem a crescer em tamanho ao longo do tempo e começam a se assemelhar a documentos de arquitetura de solução tradicionais que são arquivados e esquecidos.
Experimente
-
Um dos muitos lugares no processo de entrega de software onde os requisitos de acessibilidade devem ser considerados é durante o teste de componentes web. Embora plugins de frameworks de teste como o chai-a11y-axe forneçam asserções em suas APIs para verificar o básico, o design de teste de componentes ciente da acessibilidade pode ajudar ainda mais a fornecer todos os elementos semânticos necessários para leitores de tela e outras tecnologias assistivas. Primeiro, ao invés de usar test ids ou classes para encontrar e selecionar os elementos que deseja validar, utilize o princípio de identificar elementos por funções do ARIA ou outros atributos semânticos usados por tecnologias assistivas. Algumas bibliotecas de teste, como a Testing Library, até recomendam isso em sua documentação. Segundo, não teste apenas interações por clique; considere também pessoas que não podem usar um mouse ou ver a tela, e considere adicionar testes adicionais para o teclado e outras interações. A técnica descrita está bem estabelecida dentro de nossas equipes, e deveríamos tê-la colocado no anel Experimente há algum tempo.
-
A Análise de caminho de ataque (ACA) é uma técnica de análise de segurança que identifica e avalia os potenciais caminhos que um invasor pode tomar para explorar vulnerabilidades nos sistemas e redes de uma organização. Anteriormente, a maioria das estratégias ou ferramentas de análise de segurança se concentrava em áreas de risco específicas, como configurações incorretas, contêineres vulneráveis ou alertas de CVE. Essa abordagem em silos significa que as equipes não podem ver como os riscos podem ser combinados com as fraquezas em outras camadas do stack de tecnologia para criar caminhos de ataque perigosos. Embora essa técnica não seja nova, os recentes avanços nas ferramentas de análise de segurança tornaram-na mais acessível às equipes de segurança. Orca e Wiz são duas dessas ferramentas. Sugerimos que as equipes que gerenciam infraestruturas complexas considerem essa técnica ao planejar uma estratégia de segurança ou selecionem as ferramentas de análise de segurança para sua organização.
-
A complexidade da cadeia de suprimentos de software é um grande risco, e nós a abordamos isso extensivamente, por exemplo, em nossos artigos sobre SBOM e SLSA. O calcanhar de Aquiles para a maioria das equipes ainda é a presença de vulnerabilidades em dependências, muitas vezes dependências indiretas em vários níveis. Ferramentas como Dependabot ajudam criando pull requests (PRs) para atualizar as dependências. No entanto, é preciso disciplina de engenharia para cuidar dessas PRs de forma rápida, especialmente quando são para aplicativos ou serviços que não estão em desenvolvimento ativo. Nas circunstâncias certas, agora defendemos o uso do merge automático de PRs de atualização de dependência. Isso requer que o sistema tenha cobertura de teste extensiva — não apenas testes de unidade, mas também testes funcionais e de desempenho. A pipeline de compilação (build) deve executar todos esses testes e deve incluir a varredura de segurança. Em resumo, a equipe deve ter total confiança de que, quando a pipeline for executada com sucesso, o software estará pronto para ser colocado em produção. Nesses casos, as PRs de atualização de dependência, mesmo quando incluem atualizações de versão principal em dependências indiretas, devem ser mescladas (merged) automaticamente.
-
A mentalidade de produto para dados prioriza o tratamento das pessoas consumidoras de dados como clientes, garantindo que elas tenham uma experiência perfeita em toda a cadeia de valor dos dados. Isso abrange a facilidade de descoberta de dados, compreensão, confiança, acesso e consumo. A “mentalidade de produto” não é um conceito novo. No passado, nós o adotamos no mundo operacional ao construir produtos operacionais ou microsserviços. Ele também sugere uma nova maneira de construir equipes multifuncionais de longa duração para deter e compartilhar dados em toda a organização. Acreditamos que, ao trazer uma mentalidade de produto para os dados, as organizações podem operacionalizar os princípios FAIR (encontráveis, acessíveis, interoperáveis e reutilizáveis). Nossas equipes usam catálogos de dados como Collibra e DataHub para permitir a descoberta de produtos de dados. Para promover a confiança, publicamos métricas de qualidade de dados e SLI como recenticidade, completude e consistência para cada produto de dados, e ferramentas como Soda Core e Great Expectations automatizam as verificações de qualidade dos dados. A observabilidade de dados, por sua vez, pode ser obtida com a ajuda de plataformas como Monte Carlo. Temos visto os produtos de dados evoluírem como blocos constitutivos reutilizáveis para vários casos de uso ao longo do tempo. Isso é acompanhado por um tempo de lançamento mais rápido para casos de uso subsequentes, à medida que avançamos na identificação e construção de produtos de dados orientados por casos de valor. Portanto, nosso conselho é abraçar a mentalidade de produto para dados FAIR.
-
Uma das técnicas que recomendamos para implementar a confiança zero para pipelines de CI/CD é autenticar seus pipelines para acesso a serviços de nuvem por meio de mecanismos de identidade federada como OpenID Connect (OIDC). Como o GitHub Actions é amplamente utilizado — e essa técnica importante ainda é subutilizada — queremos destacar o OIDC para GitHub Actions. Dessa forma, você pode evitar o armazenamento de tokens de acesso de longa duração para seus recursos de nuvem e seus pipelines não terão acesso direto a segredos. No entanto, certifique-se de restringir o acesso cuidadosamente para que as ações realmente sejam executadas com privilégios mínimos.
-
Infraestrutura como código (IaC) é uma abordagem amplamente aceita para definir e provisionar ambientes de hospedagem. Mesmo com a contínua evolução de ferramentas e técnicas nessa área, o Terraform continua sendo a ferramenta dominante para fazer IaC em recursos nativos da nuvem. Entretanto, a maioria dos ambientes de hospedagem hoje são combinações complexas de serviços nativos de fornecedores de nuvem, serviços de terceiros e código personalizado. Nestes ambientes, percebemos que as pessoas engenheiras muitas vezes recorrem a uma combinação de Terraform para recursos de nuvem e scripts personalizados para o restante. Isso pode levar a uma falta de consistência e repetibilidade no processo de provisionamento. Na verdade, muitos dos serviços de terceiros que são comumente usados em ambientes de hospedagem — incluindo Splunk, Datadog, PagerDuty e New Relic — possuem provedores do Terraform que você pode usar para provisionar e configurar esses serviços. É por isso que recomendamos que, além de recursos de nuvem, as equipes também provisionem monitores e alertas com Terraform. Isso leva a um IaC com melhor modularidade que é mais fácil de entender e manter. Como em toda IaC, há um risco de introduzir inconsistências quando a configuração é alterada por meio de outras interfaces. Para garantir que o código do Terraform permaneça como fonte da verdade, recomendamos que você desabilite as alterações de configuração por meio de interfaces da pessoa usuária e APIs.
-
O ReAct prompting é um método de prompt LLMs (modelos de linguagem de grande porte) que visa melhorar a precisão de suas respostas em relação a métodos concorrentes, como cadeia de pensamento (CoT). Introduzido em um artigo de 2022, ele funciona combinando raciocínio e ação (daí o nome ReAct). Tal abordagem ajuda a tornar as respostas dos LLMs mais explicáveis e reduz as alucinações em comparação com o CoT, dando as engenheiras de prompt uma chance melhor de obter o que desejam. LangChain foi originalmente desenvolvido para suportar esse estilo de comando. Os agentes autônomos baseados no método de comando ReAct provaram ser algumas das aplicações mais amplamente utilizadas de LLMs que nossas equipes têm construído. Recentemente, a OpenAI introduziu chamada de função em suas APIs para facilitar a implementação do ReAct e de estilos de prompt semelhantes sem recorrer a ferramentas externas como LangChain. Ainda estamos nos estágios iniciais da definição desta disciplina, mas até agora, ReAct e seus descendentes apontaram o caminho para algumas das aplicações mais fascinantes de LLMs.
-
Retrieval-Augmented Generation (RAG) é uma técnica para combinar memória paramétrica e não paramétrica pré-treinada para geração de linguagem. Ela permite que você aumente o conhecimento existente de LLMs pré-treinados com conhecimento privado e contextual do seu domínio ou setor. Com RAG, você primeiro recupera um conjunto de documentos relevantes da memória não paramétrica (geralmente por meio de uma busca de similaridade a partir de um datastore vetorial) e, em seguida, usa a memória paramétrica dos LLMs para gerar uma saída que seja consistente com os documentos recuperados. Nós achamos que RAG é uma técnica eficaz para uma variedade de tarefas de processamento de linguagem natural (PLN) que requerem conhecimento profundo, incluindo respostas a perguntas, resumo e geração de histórias.
-
Modelagem de falhas baseada em risco é um processo usado para entender o impacto, a probabilidade e a capacidade de detectar as várias maneiras que um sistema pode falhar. As equipes de entrega estão começando a usar essa metodologia para projetar e avaliar os controles necessários para prevenir essas falhas. A abordagem é baseada na prática da análise de modos e efeitos de falha (FMEA), uma técnica de avaliação de riscos que existe desde os anos 1940 e tem um histórico de sucesso em indústrias que constroem sistemas físicos complexos, como aeroespacial e automotivo. Assim como nessas indústrias, a falha de software também pode ter consequências graves — comprometendo, por exemplo, a saúde e a privacidade humana — razão pela qual estamos observando uma necessidade crescente dos sistemas serem submetidos a uma análise rigorosa. O processo começa a partir da identificação dos possíveis modos de falha. A equipe então realiza uma análise da causa raiz e atribui pontuações de acordo com a probabilidade de uma falha ocorrer, o tamanho de seu impacto e a probabilidade de detectar a causa raiz da falha. Descobrimos que isso é mais eficaz quando as equipes multifuncionais iteram por esse processo à medida que o sistema evolui. No que diz respeito à segurança, modelagem de falhas baseada em risco pode ser um complemento útil à modelagem de ameaças e à análise de caminho de ataque.
-
Temos tido sucesso em várias aplicações usando linguagem natural semiestruturada para LLMs. As entradas estruturadas, como um documento JSON, são nítidas, precisas e dão ao modelo uma indicação do tipo de resposta que está sendo buscada. Restringir a resposta dessa maneira ajuda a estreitar o espaço do problema e completar de forma mais precisa, particularmente quando a estrutura está em conformidade com uma linguagem de domínio específico (DSL) cuja sintaxe ou esquema é fornecido ao modelo. Também descobrimos que o enriquecimento da entrada estruturada com comentários ou notações de linguagem natural produz uma resposta melhor do que a linguagem natural ou a entrada estruturada sozinha. Tipicamente, a linguagem natural é simplesmente intercalada com conteúdo estruturado ao construir o prompt. Como em muitos comportamentos de LLM, não sabemos exatamente por que isso funciona, mas nossa experiência mostra que colocar comentários de linguagem natural no código escrito por humanos também melhora a qualidade da saída para assistentes de programação baseados em LLM.
-
Estamos observando que as equipes estão melhorando seu ecossistema ao tratar a classificação de saúde da mesma forma que outros objetivos de nível de serviço (SLO) e priorizando as melhorias de acordo, em vez de se concentrarem apenas no rastreamento da dívida técnica. Ao alocar recursos de forma eficiente para resolver os problemas de maior impacto relacionados à saúde, as equipes e organizações podem reduzir os custos de manutenção de longo prazo e evoluir os produtos de forma mais eficiente. Essa abordagem também aprimora a comunicação entre stakeholders técnicos e não técnicos, promovendo uma compreensão comum do estado do sistema. Embora as métricas possam variar entre as organizações (veja este post do blog para exemplos), elas contribuem para a sustentabilidade de longo prazo e garantem que o software permaneça adaptável e competitivo. Em um cenário digital em constante mudança, rastrear a saúde em vez da dívida técnica dos sistemas fornece uma estratégia estruturada e baseada em evidências para mantê-los e melhorá-los.
-
Observabilidade e monitoramento são essenciais para equipes de software. Dada a natureza imprevisível de certos eventos, é crucial criar mecanismos de alerta precisos com regras complexas. No entanto, a verdadeira validação dessas regras só ocorre quando os cenários surgem em produção. A técnica de teste unitário para regras de alerta permite que as equipes definam melhor as regras testando-as e refinando-as proativamente antes, aumentando a confiança na forma como a regra está configurada. Isso ajuda a reduzir os alarmes falsos e garantir que os problemas reais sejam destacados. Ferramentas como Prometheus suportam teste unitário para regras; nossas equipes já estão relatando seus benefícios em cenários do mundo real.
-
Se não forem devidamente protegidas, a infraestrutura e as ferramentas que executam nossas pipelines de compilação e de entrega podem se tornar uma grande vulnerabilidade. Os pipelines precisam acessar dados e sistemas críticos, como código, credenciais e segredos, para compilar e implantar software. Isso torna esses sistemas muito atrativos para agentes maliciosos. Portanto, recomendamos fortemente a aplicação da arquitetura de confiança zero para pipelines de CI/CD e infraestrutura — confiando neles o mínimo necessário. Isso engloba uma série de técnicas: se disponível, faça a autenticação dos seus pipelines com seu provedor de nuvem por meio de mecanismos de identidade federada como OIDC; em vez de dar a eles acesso direto a segredos, implemente o princípio do menor privilégio, minimizando o acesso de contas de usuárias individuais ou de execução, em vez de empregar contas de acesso ilimitado; use seus executores de forma efêmera em vez de reutilizá-los, para reduzir o risco de expor segredos de atividades anteriores ou executar atividades em executores comprometidos; mantenha o software em seus agentes e executores atualizado, monitore a integridade, confidencialidade e disponibilidade de seus sistemas CI/CD da mesma forma que você monitora seu software em produção. Estamos observando equipes se esquecendo desse tipo de prática, principalmente quando estão acostumadas a trabalhar com uma infraestrutura autogerenciada de CI/CD em zonas de rede internas. Embora todas essas práticas sejam importantes em suas redes internas, elas se tornam ainda mais cruciais ao usar um serviço gerenciado, pois isso amplia ainda mais a superfície de ataque e o raio de impacto.
Avalie
-
A segurança da cadeia de suprimentos de software tornou-se uma preocupação comum entre as equipes de entrega, refletida no crescente número de ferramentas e técnicas no espaço, várias das quais já abordamos anteriormente no Radar. A crescente popularidade de ferramentas baseadas em GenAI como auxiliares no processo de desenvolvimento de software introduziu um novo vetor de ataque à cadeia de suprimentos de software: alucinações de pacotes. Acreditamos que é importante que as equipes que usam essas ferramentas GenAI em seu processo de desenvolvimento fiquem vigilantes contra esse risco. Para garantir isso, as equipes podem realizar verificações de saúde de dependências para combater alucinações de pacotes: olhar a data de criação, o número de downloads, os comentários e as notas atribuídas, número de colaboradores, histórico de atividade e assim por diante antes da decisão final de adoção da ferramenta. Algumas dessas verificações podem ser realizadas em repositórios de pacotes e no GitHub, e ferramentas como deps.dev e Snyk advisor que também podem fornecer informações adicionais. Embora não seja uma técnica nova, ela está ganhando de volta a sua relevância à medida que as equipes experimentam cada vez mais ferramentas GenAI em seu processo de desenvolvimento de software.
-
Em um ambiente de desenvolvimento de produto em ritmo acelerado, onde as necessidades das pessoas usuárias estão em constante evolução, o design é uma área que está sempre em desenvolvimento. Isso significa que os inputs sobre as decisões de design continuarão a ser necessários. Adotando a ideia de documentar decisões de arquitetura por meio de ADRs (Architecture Decision Records), começamos a adotar um formato semelhante — registros de decisão do sistema de design — para documentar decisões do sistema de design com a respectiva justificativa, percepções de pesquisa e resultados de experimentos. Comunicar decisões do sistema de design de forma eficaz parece ser uma necessidade emergente das equipes de desenvolvimento de produtos; fazer isso de maneira leve também é recomendado pelo zeroheight. Essa técnica nos ajudou a reduzir o tempo de onboarding, a avançar as conversas e a alinhar os fluxos de trabalho que compartilham o mesmo sistema de design.
-
GitOps é uma técnica de implantação de aplicações usando o padrão control loop. Um operador mantém a aplicação implantada sincronizada com a configuração, geralmente um repositório Git. Quando escrevemos pela última vez sobre GitOps, a comunidade ainda não havia chegado a um acordo sobre uma definição do termo. Na época, estávamos preocupadas com interpretações comuns da técnica que incluíam abordagens como branch por ambiente para configuração, o que pode levar a snowflakes como código. Além disso, a mensagem sobre GitOps como uma alternativa à entrega contínua era confusa. Desde então, os quatro princípios do GitOps especificam o escopo e a natureza da técnica. Quando você retira a expectativa exagerada e a confusão, GitOps é uma técnica útil que aproveita a funcionalidade de um cluster Kubernetes e cria oportunidades para separação de conceitos entre a configuração de uma aplicação e a implementação do processo de implantação. Algumas de nossas equipes implementaram o GitOps como parte da estruturação do seu processo de entrega contínua e tiveram experiências positivas, razão pela qual recomendamos avaliá-lo.
-
À medida que o desenvolvimento de modelos de linguagem de grande porte (LLMs) continua, o interesse em construir agentes de IA autônomos é forte. AutoGPT, GPT-Engineer e BabyAGI são todos exemplos de agentes autônomos impulsionados por LLM que fomentam um LLM subjacente para entender o objetivo que lhes foi dado e trabalhar para alcançá-lo. O agente lembra de quanto progresso fez, usa o LLM para raciocinar sobre o que fazer a seguir, toma ações e entende quando o objetivo foi alcançado. Isso é frequentemente conhecido como raciocínio de cadeia de pensamento — e pode realmente funcionar. Uma de nossas equipes implementou um chatbot de atendimento ao cliente como um agente autônomo. Se o bot não conseguir atingir o objetivo da cliente, ele reconhece sua própria limitação e redireciona a cliente para um humano. Essa abordagem está definitivamente no início de seu ciclo de desenvolvimento: agentes autônomos frequentemente sofrem de uma alta taxa de falha e incorrem em taxas de serviços de IA caras, e pelo menos uma startup de IA se afastou de uma abordagem baseada em agente.
-
Com a adoção generalizada da engenharia de plataforma, estamos vendo uma nova geração de ferramentas que vão além do modelo tradicional de plataforma como serviço (PaaS) e oferecem contratos publicados entre equipes de plataforma e pessoas desenvolvedoras. O contrato pode envolver o provisionamento de ambientes de nuvem, bancos de dados, monitoramento, autenticação e muito mais em um ambiente diferente. Essas ferramentas garantem os padrões organizacionais enquanto concedem às pessoas desenvolvedoras acesso self-service a variações por meio de configuração. Exemplos desses sistemas de orquestração de plataforma incluem Kratix e Humanitec Platform Orchestrator. Recomendamos que as equipes de plataforma avaliem essas ferramentas como uma alternativa a reunir sua própria coleção única de scripts, ferramentas nativas e infraestrutura como código. Também notamos uma semelhança com os conceitos do Open Application Model (OAM) e seu orquestrador de referência KubeVela, embora o OAM afirme ser mais focado na aplicação do que no workload.
-
Modelos de linguagem de grande porte (LLMs) geralmente requerem infraestrutura significativa de GPU para operar, porém há uma forte imposição para fazê-los funcionar em um hardware mais modesto. A quantização de um modelo de grande porte pode reduzir os requisitos de memória, permitindo que um modelo de alta fidelidade seja executado em hardware de custo menor ou até mesmo em uma CPU. Esforços como o llama.cpp tornam possível executar LLMs em hardware, incluindo Raspberry Pis, laptops e servidores de commodities. Muitas organizações estão implantando LLMs auto-hospedados. Isso geralmente ocorre devido a preocupações de segurança ou privacidade, ou, às vezes, à necessidade de executar modelos em dispositivos de borda. Exemplos de código aberto incluem GPT-J, GPT-JT, e Llama. Essa abordagem oferece melhor controle do modelo durante o ajuste fino para um caso de uso específico, segurança e privacidade aprimoradas, bem como acesso offline. Embora tenhamos ajudado alguns de nossos clientes a hospedar LLMs de código aberto para completar código, recomendamos que você avalie cuidadosamente as capacidades organizacionais e o custo de executar esses LLMs, antes de tomar a decisão de hospedá-los.
Evite
-
O top 10 da OWASP é há muito tempo uma referência de consulta para os riscos de segurança mais críticos para aplicações web. Apesar de ser bem conhecida, já escrevemos sobre ela ser subutilizada no processo de desenvolvimento de software e alertamos contra ignorar o top 10 da OWASP. O que não é muito conhecido é que a OWASP também publica listas semelhantes de top 10 para outras categorias. A lista de top 10 da OWASP para LLMs, cuja primeira versão foi lançada no início de agosto, destaca riscos como injeção de prompt, manipulação insegura de saída, envenenamento de dados de treinamento e outras que as pessoas desenvolvedoras e as equipes que criam aplicações LLM fariam bem em estar cientes. A OWASP também lançou recentemente a segunda versão de sua lista de top 10 da OWASP para API. Dada a amplitude de cobertura, qualidade e relevância das listas top 10 da OWASP (aplicações web, APIs, LLMs e mais) para o panorama de segurança em constante mudança, estendemos nossa recomendação anterior e alertamos as equipes contra ignorar as listas de top 10 da OWASP.
-
Desde que os mencionamos pela primeira vez em 2014, os Web Components se tornaram populares e, em geral, nossa experiência tem sido positiva. Da mesma forma, defendemos a renderização de HTML no servidor, alertando contra SPA por padrão e incluindo frameworks como Next.js e htmx além de frameworks tradicionais de back-end. No entanto, embora seja possível combinar ambos, isso também pode se mostrar profundamente problemático. É por isso que sugerimos evitar Web Components para aplicações web renderizadas do lado do servidor (SSR). Por ser uma tecnologia de navegador, não é trivial usar Web Components no servidor. Frameworks surgiram para tornar isso mais fácil, às vezes até usando um motor de navegação (browser engine), mas a complexidade ainda existe. Pior do que os problemas para a experiência da pessoa desenvolvedora é a experiência da pessoa usuária: o tempo de carregamento da página é impactado quando os Web Components personalizados precisam ser carregados e renderizados no navegador, e mesmo com pré-renderização e ajustes cuidadosos do componente, um lash de conteúdo sem estilo ou algum deslocamento de layout é quase inevitável. A decisão de abster-se de Web Components pode ter consequências abrangentes, como uma de nossas equipes comprovou quando precisou mover seu sistema de design para longe do Stencil, que é baseado em Web Components.
- Novo
- Modificado
- Sem alteração
Não encontrou algo que você esperava achar?
Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.
Não encontrou algo que você esperava achar?
Cada edição do Radar inclui blips que refletem nossas experiências nos seis meses anteriores. Talvez já tenhamos falado sobre o que você procura em um Radar anterior. Às vezes, deixamos coisas de fora simplesmente porque há muitas a serem abordadas. Também pode faltar um tópico específico porque o Radar reflete nossa experiência, não se baseando em uma análise abrangente do mercado.