Desenvolvimento e-commerce: pluginfinance.com

#Distribuir código é distribuir risco

pluginfinance.com apresenta e distribui plugins para o setor financeiro. A implementação começou em 2012, incluiu também a identidade visual, e a primeira versão demorou cerca de seis semanas. A plataforma foi mantida e modernizada desde então, e por isso assenta hoje em PHP 8 e MySQL 8, com o WordPress como camada de conteúdo e de comércio e uma interface em React que fala com ele por REST e GraphQL.

Vale a pena começar pelo risco, porque foi ele que ordenou a arquitetura. Um site que vende ferramentas para o setor financeiro é um alvo atraente por dois motivos ao mesmo tempo: processa pagamentos e distribui código que os clientes instalam nos seus próprios sites. O segundo é o mais grave, porque um ficheiro de atualização comprometido propaga-se automaticamente para todas as instalações que o descarregam.

Daí resulta a ordem das defesas. Os pagamentos não passam pelo site, passam pelo prestador de pagamentos, portanto os dados do cartão nunca chegam ao nosso servidor e a loja guarda apenas um identificador de transação. Os ficheiros de lançamento são assinados e só são entregues depois da verificação de licença, e o acesso ao painel de publicação está separado da administração corrente de conteúdos. A segurança é tratada no código e na configuração do servidor, e não com mais um plugin de proteção: um plugin desse tipo corre dentro do PHP, ou seja, depois de o pedido já ter arrancado a aplicação, cobra um custo em cada pedido e torna-se com frequência, ele próprio, uma vulnerabilidade.

Existe ainda uma camada de proteção de dados que não se contorna numa loja que emite chaves de licença. Uma conta de cliente liga um endereço de correio à lista de domínios onde as licenças correm, isto é, a informação sobre a infraestrutura dessa empresa. Não são dados sensíveis na aceção legal, mas uma fuga tem consequências reais para o cliente, porque mostra a um atacante que ferramenta está em que site. O acesso a essa lista é restringido ao nível da API tal como o acesso aos dados de encomenda, e os registos guardam deliberadamente identificadores abreviados em vez de chaves completas.

Nesta secção costuma aparecer uma tabela de resultados. Não aparece nenhuma: os números de vendas pertencem ao cliente e não a uma ficha de projeto no nosso site. O que se mostra com honestidade são as decisões e as suas consequências.

#A venda é o início da relação

A camada comercial assenta em WooCommerce, alargado com subscrições e licenças. É aqui que está a parte mais difícil do projeto, porque no momento da compra a loja começa a trabalhar em vez de terminar.

A chave de licença gerada depois do pagamento é apenas o princípio. A instalação do cliente consulta o serviço à procura de atualizações, ou seja, a loja é simultaneamente um servidor de atualizações. Isso significa que os pedidos não vêm só de pessoas com um navegador, mas de centenas de instalações de WordPress a verificar em segundo plano segundo o seu próprio calendário, independentemente do tráfego de visitantes. Esse tráfego é invisível nas estatísticas de visitas e muito visível na carga do servidor, se ninguém o tiver previsto.

A solução separa os dois mundos. O endpoint que verifica licença e versão responde o mais brevemente possível, lê do Redis e não arranca o ciclo completo de construção da página. O ficheiro de atualização é entregue a partir da periferia da rede, porque é um ficheiro estático e não o resultado de uma consulta à base de dados. Separar a verificação de permissões da entrega do ficheiro é o essencial: a verificação tem de ser barata e exata, enquanto a transferência é cara e deve acontecer o mais longe possível da aplicação.

Por baixo disto existe uma regra que soa a direito e acaba em código. Uma licença expirada não pode desativar um plugin instalado. O cliente pagou por software que continua a funcionar; a expiração retira o direito a atualizações e a apoio, não o direito de uso. O estado da licença e o estado de funcionamento têm, portanto, de ser dois valores independentes. Quem os confunde deixa o cliente, na primeira renovação atrasada, com um módulo desativado em produção e uma avaria causada pela loja.

#Uma página de produto que é uma ficha técnica

Um plugin financeiro compra-se por parâmetros e não por uma fotografia. O comprador quer saber com que versões de WordPress e de PHP o produto funciona, que dependências externas traz, se funciona numa instalação multilingue, o que faz exatamente com dados de pagamento e como é o caminho de apoio depois da compra. Nada disto cabe num parágrafo corrido, porque tudo isto tem de ser filtrável e comparável.

Os produtos são por isso descritos com tipos de conteúdo próprios e campos personalizados assentes em Advanced Custom Fields. Um parâmetro técnico é um campo, não uma frase. O ganho evidente é a filtragem e a ordenação. O menos evidente aparece na manutenção: quando sai uma nova versão principal do WordPress, atualizar a compatibilidade de todo o catálogo é uma operação sobre um campo e não a leitura de várias dezenas de descrições à procura da frase que menciona uma versão. Um catálogo que guarda a compatibilidade em prosa está a mentir em metade das entradas ao fim de dois anos, e ninguém repara.

As tabelas comparativas dependem desta disciplina mais do que de qualquer outra coisa. Quem avalia ferramentas financeiras costuma reduzir a dois ou três candidatos e quer vê-los lado a lado, atributo contra atributo. Uma comparação vale o que valem os campos preenchidos: se metade dos produtos tiver o campo de compatibilidade vazio, a tabela engana com mais eficácia do que ajuda. Os campos que sustentam a comparação são por isso obrigatórios na publicação e não opcionais.

As análises, os casos de cliente e os artigos técnicos são tipos de conteúdo distintos, e a documentação do produto também. A documentação tem versões: o guia de instalação da versão do ano passado não pode desaparecer no momento em que sai uma nova, porque parte dos clientes permanece deliberadamente num ramo mais antigo.

#Interface separada do núcleo e o que isso custa

A interface é uma aplicação no navegador, com o WordPress a servir conteúdo e lógica comercial por trás. A escolha teve aqui uma justificação concreta, e não a recomendamos por reflexo a qualquer loja.

A justificação é a filtragem em várias dimensões. Os compradores reduzem o catálogo por tipo de integração, por compatibilidade de versão, por modelo de licença e por outros atributos, mudando de ideias pelo caminho. No modelo clássico, cada mudança de filtro é um recarregamento de página e uma construção completa no servidor. Num catálogo com muitos atributos isso significa mais de uma dezena de consultas à base de dados por clique numa caixa de seleção. Uma interface separada procura apenas a lista de resultados e não a vista inteira.

Os custos são reais e merecem ser ditos. Conteúdo gerado no navegador pode ser mais difícil de ver para um rastreador, por isso as páginas que devem trazer tráfego de pesquisa, ou seja, as páginas de produto e o material editorial, são construídas no servidor e entregues em HTML já pronto. Apenas a operação do catálogo é feita no cliente. O segundo custo é a própria camada de API, que passa a ser mais uma fronteira a manter e a proteger. O GraphQL resolve parte do problema, porque uma consulta traz exatamente os campos de que a vista precisa em vez de três chamadas REST a devolver dados a mais, mas exige limites cuidadosos à complexidade das consultas. Um endpoint GraphQL público sem limite de profundidade é um convite a esgotar o servidor com um único pedido.

#Onde a cache de periferia tem de parar

O Redis trata da cache de objetos e das sessões, a Cloudflare fica à frente, e há ainda cache de páginas no servidor. Três camadas parecem excesso até se escrever que tipo de pedido cai onde.

Uma loja divide o tráfego em duas metades desiguais. As páginas de catálogo e o material editorial são iguais para todos os visitantes, logo podem ser servidos da periferia e nunca tocam no PHP. O carrinho, a conta de cliente, o histórico de encomendas e a lista de chaves de licença são pessoais e não podem ser guardados em lado nenhum a não ser no navegador do respetivo dono. A fronteira entre estes dois mundos é a origem mais frequente de defeitos graves em lojas online: um cabeçalho mal configurado e a periferia começa a servir o carrinho de um cliente a outro.

A regra é por isso absoluta e não está sujeita a otimização: a presença do cookie de sessão de compra exclui o pedido da cache de periferia, sem exceções. Isso custa desempenho aos clientes autenticados e é um custo aceite conscientemente, porque a alternativa é a fuga de dados de encomenda. Os fragmentos que dependem da sessão, como o contador do carrinho no cabeçalho, são obtidos por um pedido separado depois de a página carregar, o que mantém a estrutura da página comum a todos e ainda passível de ser guardada em cache.

#Regras fiscais que chegam ao carrinho

Qualquer loja que venda bens digitais para fora da fronteira encontra uma exigência que não é trabalho posterior de contabilidade, mas uma condição dentro do processo de compra. Um serviço eletrónico prestado a um consumidor noutro país da União é tributado à taxa do país do comprador, e a venda a uma empresa com número de identificação fiscal válido é liquidada de forma diferente da venda a um particular. A loja tem de estabelecer o estatuto do comprador antes de mostrar um preço final, validar o número no registo e conservar prova da localização do comprador.

Isso chega ao carrinho e ao modelo de fatura. Toca também na cache de uma forma que costuma apanhar as equipas desprevenidas: um preço que depende do país do visitante não pode ser fixado numa página guardada para toda a gente. No catálogo os preços aparecem numa forma base definida, e o valor final dependente do país é resolvido no carrinho, onde o pedido já está de qualquer maneira fora da cache de periferia.

#Desempenho, monitorização e manutenção

A camada visível é a parte barata deste projeto. Os recursos são compilados, os pacotes divididos e o código carregado apenas nas páginas que o usam; as imagens são processadas uma vez no carregamento em vez de a cada apresentação. Os ficheiros estáticos passam pela Cloudflare, o que com clientes espalhados por vários continentes é a maior poupança isolada disponível. Nada disto ajuda a parte cara, porque a parte cara é um pedido que tem de chegar à aplicação por definição.

Essa parte é o endpoint de licença. Quem o consulta não são pessoas com um navegador, são centenas de instalações de clientes a correr o seu próprio calendário, de madrugada tanto como ao meio-dia. O tráfego não aparece em nenhuma estatística de visitas e aparece inteiro na carga do servidor. Uma página inicial lenta custa conversões, e isso é mau de uma maneira previsível. Um endpoint de licença que deixa de responder é mau de outra maneira: faz centenas de instalações reportarem um erro de atualização no mesmo minuto e enche o apoio de pedidos sobre uma avaria que não aconteceu do lado do cliente. Por isso tem alarme próprio, separado da monitorização geral de disponibilidade.

A manutenção cobre atualizações de núcleo, tema e extensões, revisão de registos, cópias de segurança cuja reposição é efetivamente ensaiada e as alterações funcionais que a evolução da oferta traz. Uma loja de software acrescenta um ponto que o comércio comum não tem: cada atualização do WordPress do lado da loja tem de ser conciliada com a compatibilidade declarada pelos produtos vendidos. Uma loja que corre a versão mais recente enquanto vende extensões marcadas como compatíveis com uma versão de há dois anos desvaloriza o seu próprio catálogo. Os testes correm contra uma cópia da produção e não contra uma instalação vazia, e aqui a razão é literal: uma instalação vazia não tem uma única licença ativa, portanto a lógica de renovação, expiração e verificação de versão passa qualquer teste por não ter nada que fazer. Só um conjunto real, com licenças expiradas, licenças renovadas a meio do período e alguma que o cliente mudou de domínio sem avisar, mostra se as regras se comportam como as condições de venda descrevem.

#Resumo

O WordPress aguenta a distribuição de software desde que seja tratado como camada de conteúdo e de comércio e não como a aplicação inteira. Fora dele ficam as peças com condições duras de tempo ou de segurança, que aqui são duas: a verificação da licença e a entrega do ficheiro. O resto assenta onde um sistema de gestão de conteúdos é forte. O catálogo, a documentação com versões, o material editorial e o carrinho vivem na mesma instalação sem se atrapalharem.

Quatro decisões transitam para qualquer projeto do mesmo tipo. Dados de produto estruturados em vez de prosa, a separação entre direito de uso e direito a atualizações, uma fronteira explícita à volta daquilo que pode ser guardado em cache e a divisão entre verificação de licença e entrega de ficheiros.

O que não transita é o modelo de conteúdos deste catálogo nem as suas regras de licenciamento, escritos para uma oferta e um conjunto de condições. Vale a pena dizer a quem é que este desenho serve. Serve a equipa de apoio, que deixa de responder a perguntas sobre chaves já expiradas porque a conta do cliente mostra o estado sem intermediários. Serve o programador do lado do cliente, que recebe atualizações sem abrir um pedido. E serve quem vier a seguir nesta loja, porque a implementação seguinte começa por uma pergunta em vez de um modelo: o que compra exatamente o cliente e por quanto tempo.