ricco.dev.br

Wordpress Vs Jamstack

Comparar Jamstack com WordPress é um pouco estranho. O que é comparável é o fato de que ambos são caminhos diferentes para construir um site. Muito deste post vai manter isso em mente e comparar os dois dessa forma.

Por que eles não são diretamente comparáveis :

  • Jamstack é a descrição de uma filosofia arquitetônica que incentiva arquivos estáticos em CDNs e serviços acessados por JavaScript para quaisquer necessidades dinâmicas.
  • WordPress é um CMS que usa o stack LAMP (Linux + Apache + MySQL + PHP)

É como comparar maçãs com laranjas, olhando somente para o stack usado a comparação seria;

  • Hospedagem estática + serviços
  • LAMP

Um exemplo de hospedagem estática + serviços é usar o Netlify para hospedagem (que é estática) e usar serviços para fazer qualquer coisa dinâmica que você precisa fazer. Você pode usar os próprios formulários e funcionalidade de autenticação do Netlify e Hasura para armazenamento de dados.

Em um stack LAMP, você tem MySQL para armazenar dados, então você não irá usar um serviço externo pra isso. Você também tem PHP disponível. Portanto, com eles (além do software de código aberto), você tem o que precisa para autenticação. Isso não significa que você nunca buscará serviços externos; você só faz isso com menos frequência, pois tem mais tecnologia ao seu alcance a partir do servidor que já possui.

Um site WordPress auto-hospedado é executado em um servidor com um conjunto completo de tecnologias disponíveis. Faz sentido pedir o máximo possível desse servidor. Em uma abordagem Jamstack, o servidor é abstraído de você. Tudo o mais que você precisa fazer é dividido em serviços diferentes.

A abordagem do WordPress não significa que você nunca busque serviços externos. Em ambos stacks, você pode usar algo como Stripe para APIs de comércio eletrônico, Cloudinary para armazenamento e serviço de mídia e até mesmo o Jetpack do WordPress traz muito poder para um site WordPress auto-hospedado se comportando como um serviço de terceiros e removendo coisas como hospedagem de arquivos e motores de pesquisa de seus próprios servidores, transferindo-os para servidores em nuvem.

Nenhum stack é mais propenso a erros que o outro, todos os sites podem ter aquela metáfora “tão forte quanto o seu elo mais fraco” aplicado a eles. Se um plugin do WordPress vem de alguma forma corrompido no upload, ele pode quebrar o seu site. Se minhas chaves de API se tornarem inválidas para meu cms, meu site Jamstack pode ficar bloqueado até que eu resolva esse problema. Se o Stripe estiver fora do ar, não é possível vender nenhum produto em nenhum tipo de site que dependa dele até que volte a funcionar. Um ponto-e-vírgula ausente ou a mais pode afundar qualquer site.

Preços

O WordPress.com tem um plano gratuito e é um lugar onde qualquer um consegue construir um site. Mas você não tem acesso a ferramentas de desenvolvedor até que você esteja no plano de negócios de $ 25 por mês. O próprio WordPress é de código aberto e gratuito, mas você não vai encontrar um lugar para criar e hospedar um site WordPress gratuitamente. Começa barato e aumenta. Você precisa da hospedagem LAMP para executar o WordPress. Aqui está uma olhada em planos de hospedagem razoavelmente baratos:

  • Um plano Bluehost “compartilhado” começa em US$ 3,95/mês.
  • O plano mais baixo no Flywheel é de US$ 14/mês.
  • O serviço Pressable da Automattic tem um plano a partir de $25/mês.

Há dinheiro envolvido logo de cara.

Começar gratuitamente é muito mais comum com Jamstack, então você incorre em custos em pontos diferentes. Sendo Jamstack mais recente, parece um mercado que ainda está se descobrindo.

  • O Vercel é gratuito até que você precise de membros da equipe ou recursos como sites protegidos por senha. Um único site protegido por senha custa US$ 150/mês. Você pode usar autenticação básica em qualquer servidor com Apache sem nenhum custo adicional.
  • O Netlify é muito semelhante, desbloqueando recursos em planos superiores e oferecendo recursos avulsos por site, como analytics ($ 9/mês) e autenticação (5.000 usuários ativos custa $ 99/mês).
  • O AWS Amplify é iniciado gratuitamente, mas, como tudo no AWS, seu uso é medido em vários níveis, como minutos de construção, armazenamento e largura de banda. Eles têm um exemplo de cálculo de um aplicativo da web que tem 10.000 usuários ativos diariamente e é atualizado duas vezes por mês, o que custa $ 65,98/mês.
  • O Azure Static Web Apps ainda não disponibilizou os preços, mas é quase certo que terão uma camada gratuita ou uso gratuito de algum tipo.

Não se pode fazer declarações genéricas como o Jamstack é mais barato. Isso é muito dependente do uso e das necessidades do site. Com alto uso e vários serviços premium, o Jamstack (assim como o Serverless em geral) pode ficar muito caro. Em Jamstack o custo escala junto com os recursos usados.

Em um site WordPress haverá também alguma necessidade de custos adicionais devido a serviços externos, como por exemplo o Cloudflare para ajudar a reduzir a largura de banda consumida pelo servidor e o Jetpack lidando com a hospedagem de mídia e funcionalidade de pesquisa, Mailchimp para envio de newsletter, o Wufoo para o gerenciamento formulários. Além disso provavelmente será necessário também plugins pagos como o Advanced Custom Fields Pro e alguns add-ons do WooCommerce. Isso não é tudo e nem é regra mas ajuda a ilustrar que o custo de um site WordPress também pode ser bastante alto.

Resumindo: não há nenhuma mudança radical nos preços acontecendo aqui.

Performance

80% do desempenho da web é responsabilidade do front-end.

Essa história é verdadeira, mas também é construída em sua base pelo servidor (representando os primeiros 20%). O front-end mais rápido do mundo não parece tão rápido se a primeira solicitação do servidor levar vários segundos para responder. Você precisa ter certeza de que a primeira solicitação será rápida se quiser um site rápido.

Sabe o que é super rápido? CDNs globais que servem arquivos estáticos. É isso que você quer em qualquer site, independente do stack usado. Embora essa seja a base do Jamstack (hospedagem estática entregue por CDN), isso não significa que o WordPress não possa fazer isso.

Você pega um index.html (arquivo com conteúdo estático), coloca no Netlify, e ele vai propagar super rápido. Talvez o seu gerador de site estático crie esse arquivo (que, vale a pena lembrar, poderia muito bem obter o conteúdo do WordPress - via api). Essa é uma base muito estável e robusta para se trabalhar.

Por padrão, o WordPress não cria arquivos estáticos que podem ser capturados em um CDN global. O WordPress responde às solicitações de uma única origem, executa o PHP, que pede informações ao banco de dados antes de uma resposta ser montada e só então a página é retornada. Isso pode ser muito rápido, mas é muito menos resistente do que um arquivo estático em um CDN global e é muito mais fácil sobrecarregar o servidor com solicitações simultaneas.

Os serviços de host para WordPress sabem disso e tentam resolver o problema no nível da hospedagem. Basta olhar para a abordagem do WP Engine. Sem você fazer nada, eles usam um cache de página para que o site possa essencialmente retornar um arquivo estático em vez de precisar executar o PHP ou acessar um banco de dados. Eles também empregam todos os outros tipos de cache, incluindo parceria com a Cloudflare para fazer o melhor cache possível.

Cloudflare é parte da bruxaria que pode tornar o WordPress mais rápido. Apenas colocá-lo na frente de seu site WordPress auto-hospedado já vai fazer um monte de trabalho para torná-lo rápido e confiável. Há uma espécie de ironia no fato de que o cache do WordPress significa fazer o cache de solicitações como HTML estático e arquivos estáticos e servir-los a partir de um CDN global que é essencialmente o que Jamstack é no final das contas.

Segurança

Existem muito mais histórias sobre sites WordPress sendo hackeados do que sites Jamstack. Mas é justo dizer que o WordPress é menos seguro? Bem, não é que o WordPress em si seja um software inseguro. É o que você faz com isso. Você tem senhas inseguras? Isso é inseguro, não importa a plataforma que você está usando. O próprio servidor é inseguro por meio de permissões de arquivo ou níveis de acesso? Isso não é exatamente culpa do software, mas você pode estar nessa posição por causa do software. Você está executando a versão mais recente do WordPress? O uso é fragmentado, na melhor das hipóteses, e quanto mais antiga for a versão, menos segura será.

Pode ser mais interessante pensar sobre vetores de segurança. Ou seja, em que pontos é possível ser hackeado. Se você tiver um arquivo estático em uma hospedagem estática, acho que é seguro dizer que existem poucos vetores de ataque. Mas ainda assim, existem alguns:

  • Sua conta de hospedagem pode ser hackeada
  • Seu repositório Git pode ser hackeado
  • Sua conta Cloudflare pode ser hackeada
  • Seu nome de domínio pode ser roubado

Isso também é verdade em um site WordPress, mas existem vetores de ataque adicionais, como:

  • Código do lado do servidor: XSS, plug-ins inválidos, execução remota etc.
  • Vulnerabilidades de banco de dados
  • Executar uma versão mais antiga e desatualizada do WordPress
  • O sistema de login está no próprio site, por exemplo, hackers podem tentar usar o próprio /wp-login.php como vunerabilidade

Acho que é justo dizer que existem mais vetores de ataque em um site WordPress, mas existem vetores em qualquer site. A conta de hospedagem de qualquer site é um grande vetor. Qualquer coisa que esteja na cadeia DNS. Quaisquer serviços de terceiros com logins. Qualquer coisa com uma chave API.

Dimensionamento

O dimensionamento de qualquer uma das abordagens custa dinheiro. Em um plano Netlify Business (600 GB de tráfego por US$ 99, depois US$ 20 por 100 GB adicionais), essa matemática chega a US$ 979. Todos os hosts cobrarão pela largura de banda e terão limites com taxas de sobreuso. A Amplify cobra US$ 0,15/GB acima de um limite mensal de 15 GB. Flywheel cobra com base no limite mensal de visitantes e acima disso, é de $1 por 1000.

A história com o dimensionamento do WordPress é:

  • Use um host que possa lidar com isso e que tenha sua própria estratégia de armazenamento em cache.
  • CDN em tudo (o que geralmente significa colocar Cloudflare na frente dele).

A história do dimensionamento Jamstack é:

  • O host e os serviços são desenvolvidos em escala.
  • Você tem que pensar em escalar menos, pensar mais "como este serviço pode lidar com isso ou eu tenho que mudar?"
  • Você tem que pensar em escalar mais olhando para o fato de que cada aspecto de cada serviço terá um preço que você precisa ficar de olho.

Mover um site WordPress não é trivial, mas é muito mais fácil do que mover de outros CMSs. Por exemplo, se você construir um site Jamstack em um CMS Headless que se torna muito caro, o custo da mudança é um tempo de trabalho maior nesse processo do que somente a troca de hosts.

Existem outros tipos de “dimensionamentos” também. Funcionalidades menos óbivias como o número de usuários por exemplo. Isso é algo que todos os tipos de serviços usam para faixas de preços, o que é uma métrica compreensível. Mas isso é grátis no WordPress. Você pode ter quantos usuários com as permissões de nuances que desejar. Isso é apenas o CMS, portanto, adicionar outros serviços ainda pode cobrar por usuário. O Vercel ou o Netlify cobram por pessoa nas contas de time. O Contentful começa em US$ 489/mês para times. Mesmo o GitHub custa US$ 4/usuário se você precisar de algo que a conta gratuita não entrega.

Separando o Front do Back

Esta é uma das grandes coisas que deixa os desenvolvedores empolgados com o Jamstack. Se toda a funcionalidade e conteúdo do meu site estiverem por trás de APIs, isso libera o front-end para ser feito como você quiser.

  • Quer construir um site totalmente estático? OK, acesse a API durante o processo de construção e faça isso.
  • Quer construir um site renderizado pelo cliente com React ou Vue ou qualquer outro? Tudo bem, vá para API do lado do cliente.
  • Quer dividir o meio, pré-renderizar alguns, renderizar alguns no cliente e outros no servidor? Legal, é uma API, você pode acertá-la do jeito que quiser.

Essa flexibilidade é excelente em construções novas, mas as pessoas estão igualmente entusiasmadas com a flexibilidade teórica do futuro. Se toda a funcionalidade e o conteúdo forem orientados por API, você dividirá totalmente o front e o back, o que significa que pode alterar qualquer um no futuro com mais flexibilidade.

  • Contanto que suas APIs continuem exibindo o que o front-end espera, você pode redesenhar o back-end sem incomodar o front-end.
  • Contanto que você esteja obtendo os dados de que precisa, pode redesenhar o front-end sem incomodar o back-end.

Esse tipo de divisão parece future-proof para sites de um determinado tamanho e escala. Não consigo definir exatamente quais são esses números de escala, mas eles estão lá.

Se você já fez qualquer grande re-arquitetura de site apenas para acomodar um lado ou outro, mudar para um sistema onde você dividiu o back-end e o front certamente parece uma jogada inteligente.

Você também pode fazer isso em um site WordPress, mas por padrão, o WordPress possui uma abordagem integrada onde o front end é construído a partir de temas em PHP usando APIs muito específicas do WordPress. O front-end e o back-end não são realmente separados.

DX (Developer Experience)

O Jamstack fez um bom trabalho priorizando fortemente a experiência do desenvolvedor (DX). Já ouvi alguém chamá-lo de “local first”, o que significa que o Jamstack foi projetado em torno da experiência de desenvolvimento local.

  • Você deve trabalhar localmente. Você trabalha em seu próprio ambiente de desenvolvimento confortável (local, rápido, personalizado).
  • Git é um dos pilares aqui. Você envia seu branch de produção para então o processo de build ser executado, seguido do deploy do site. Você ainda obtém uma URL de visualização de como será o site no ambiente de produção para cada solicitação de envio (Pull Request) no repositório, o que é um recurso impressionante.
  • Use as ferramentas que desejar. Você quer construir um site em Hugo? Vá em frente. Aprendeu create-react-app? Use isso. Quer experimentar Svelte pra ver se o hype é real? Vai nessa. Há muita liberdade para construir como você quiser, aproveitando a liberdade de poder executar o build e fazer o deploy de qualquer pasta que desejar do seu repositório.
  • O que você não precisa fazer também é importante. Você não precisa lidar com HTTPS, não precisa lidar com cache, não precisa se preocupar com permissões de arquivo, não precisa configurar um CDN. Mesmo os desenvolvedores avançados amam ter que fazer menos.

Não é que o WordPress não considere a experiência do desenvolvedor, mas o DX não parece ser o núcleo do projeto para mim.

  • Executar o WordPress localmente é complicado, exigindo que você execute um stack (X)AMP de alguma forma, o que envolve software de terceiros - notoriamente exigentes.
  • O que deve ir no Git? Até hoje, eu realmente não sei, mas em grande parte decidi pela /wp-content (pasta inteira). Parece estranho para mim não haver orientação ou melhores práticas óbvias.
  • Você está totalmente por conta própria para implantação. Mesmo os hosts específicos do WordPress não acertam aqui. É basicamente apenas: aqui estão suas credenciais SFTP .
  • Mesmo se você tiver um bom ambiente de desenvolvimento local e um pipeline de implantação configurado, isso realmente não ajuda a lidar com a movimentação do banco de dados, então você também está por conta própria.

Tudo isso tem solução e a comunidade do WordPress é tão grande que você encontrará informações sobre ela, mas acho que é justo dizer que o WordPress não tem DX no núcleo. Ainda é um ambiente bem selvagem, mesmo depois de todos esses anos.

Na verdade, descobri que, como o incentivo a um ambiente de desenvolvimento local saudável é tão marginalizado, muitas pessoas simplesmente não têm um. Ok, isso é anedótico, mas já me vi envolvido diversas vezes em sites desenvolvidos por outras pessoas (agencias grandes inclusas) que foram projetados apenas para o ambiente de produção. Isso não seria grande coisa se eles fossem sites muito simples e com comportamento amplamente padrão mas nem sempre é o caso. Alguns são muito complicados, envolvendo logins de usuários públicos, assinaturas pagas, criadores visuais de páginas, códigos de acesso personalizados, CSS personalizados e um monte de partes móveis. Isso me assusta até hoje. Editar um PHP ao vivo para fazer as coisas funcionarem é um dos pilares do Extreme Go Horse. Um erro de sintaxe e tudo pode ir pro espaço.

O fato de que o WordPress impulsiona uma área tão grande da web sem um DX particularmente bom é muito curioso. Por outro lado, não há Jamstack sem DX. É uma coisa totalmente focada no desenvolvedor. Com o WordPress, provavelmente não é esperado um desenvolvedor na maioria dos sites. Ele é instalado (ou apenas ativado, no caso do WordPress.com) e o dono do site o pega de lá. O proprietário do site é como um desenvolvedor no sentido de que tem muito poder, mas talvez não escreva nenhuma linha de código.

CMS e a UX do usuário final

WordPress é um CMS muito bom. Por mais que eu não goste, há um monte de gente que gosta e os números falam por si. O que você ganha, quando decide construir um site com WordPress, é uma grande ajuda na capacidade de construir praticamente qualquer tipo de site que você quiser sem a necessidade de conhecimento técnico - obviamente nos casos onde a qualidade técnica não é prioridade.

Isso é um grande negócio. se observado que as pessoas que usam o WordPress são uma história maior do que as necessidades de um desenvolvedor.

O WordPress pode fazer uma tonelada de coisas:

  • Blog (ou qualquer tipo de site de estilo CMS orientado por conteúdo) …
    • Com visualizações personalizadas de conteúdo, o que é possível mas mais complicado no Jamstack
  • Lidar com usuários / permissões …
    • no nível de administrador / CMS
    • no nível de usuário (comentários , assinaturas , etc.)
  • Ecommerce
  • Processamento de Formulários
  • Lidar com plug-ins

O Jamstack também pode fazer todas essas coisas, mas agora é o Jamstack que ainda está no meio da selva. Quando você olha os tutoriais sobre como armazenar dados, eles geralmente envolvem a explicação de como escrever funções CRUD para um banco de dados em nuvem. Isso resume todo o material necessário, o que pode ser muito poderoso para um desenvolvedor, mas está muito longe dos poucos cliques em alguns botões que é o que o WordPress parece ser na maior parte do tempo.

Usando Ambos

Essa é a bola que eu vejo sendo levantada a algum tempo. Até o próprio Netlify diz "Não há Versus".

Aqui está o meio termo:

  • O “A” em “Jam” significa APIs. Use APIs para construir seu site previamente ou do lado do cliente.
  • Os sites WordPress, por padrão, têm uma API REST (e também podem ter uma API GraphQL).
  • Então, acesse a API com os dados CMS em seu site Jamstack.

Sim, isso funciona e as pessoas fazem isso.

Mas…

  • Executar um site WordPress em algum lugar além do site Jamstack significa que você está executando um site WordPress além do seu site Jamstack. Há um débito técnico e de custos nisso.
  • Muitas vezes você não está obtendo todo o valor do WordPress. Acessar uma API para dados pode ser tudo de que você precisa, mas esta é uma abordagem muito diferente para construir um site do que construir um tema WordPress. Você não está recebendo nenhum outro valor do WordPress. Eu penso em situações como esta: você encontra um plug-in bacana que adiciona um bloco de Gutenberg sofisticado ao seu site. Isso “apenas funcionará” em um site WordPress, mas provavelmente terá algum comportamento de front-end especial que não funcionará se tudo o que você estiver fazendo for aproveitar o HTML da API. Provavelmente, será necessário alguns scripts e estilos adicionais que você ficará por conta própria para descobrir como incorporar onde seu front-end está hospedado e por conta própria para manter as atualizações.

Aqui estão algumas ferramentas que têm uma abordagem única para “usar os dois”:

  • Frontity: um framework React para WordPress. Parece que você pode executá-lo com um servidor Node para que as páginas sejam renderizadas do lado do servidor ou como um gerador de site estático. De qualquer forma, o WordPress é o CMS, mas você está construindo o front-end com React e obtendo dados da API REST.
  • WP2Static: um plug-in WordPress que cria uma versão estática do seu site e pode implantá-la automaticamente quando são feitas alterações.
  • Strattic: Eles hospedam o site WordPress dinâmico para você (que eles chamam de “teste”) e você trabalha com o WordPress normalmente lá. Em seguida, você opta por implantar, e eles hospedam uma versão estática do seu site para você.

Usando nenhum

Caso isso não esteja claro, existem muitas maneiras de construir sites. Se você está construindo um site Ruby on Rails, não é Jamstack ou WordPress. Você poderia argumentar que é mais parecido com um site WordPress no sentido de que requer um servidor e você o usará para fazer o máximo que puder. Você também pode argumentar que é mais parecido com Jamstack no sentido de que embora não seja hospedagem estática, incentiva o uso de APIs e serviços.

Comments powered by Talkyard.