Web Development Project: led-lumina.pl

#O erro que não se pode repetir

Num catálogo há uma categoria de falhas que não existe em mais lado nenhum do projeto. Qualquer outro erro corrige-se e repete-se a operação. Um pagamento acontece uma vez, o seu resultado chega de fora, muitas vezes atrasado e por vezes duas vezes.

Começo por aqui porque foi este o ponto que definiu a forma como o resto do led-lumina.pl foi construído. A confirmação de uma encomenda não pode assentar no facto de alguém ter chegado à página de agradecimento. Chega ou não chega: fecha o separador, perde rede, carrega em retroceder. O estado da encomenda é decidido apenas pela notificação que chega do operador, e o tratamento dessa notificação tem de tolerar ser chamado mais do que uma vez, porque um operador em dúvida volta a enviar. Se não tolerar, um pagamento transforma-se em duas encomendas.

O mesmo raciocínio traça a fronteira no envio. O site conhece o peso e as dimensões do que está no cesto e consegue calcular um custo. Não conhece a capacidade atual da transportadora nem as suas limitações momentâneas, e não finge conhecer. Dizer essa fronteira em voz alta é mais útil do que uma estimativa que de vez em quando está confiantemente errada.

#O catálogo por baixo das fotografias

Retirando a fotografia, um catálogo de iluminação é uma tabela de números. Fluxo luminoso, temperatura de cor, índice de restituição cromática, ângulo de abertura, grau de proteção, classe energética, se a luminária admite regulação de intensidade e se o driver vem incluído. Dois produtos deste catálogo distinguem-se por esses valores e por muito pouco mais.

Daí decorre uma decisão que teve de ficar fechada logo na primeira semana. A descrição de um produto não pode ser um campo de texto onde alguém escreve a especificação em prosa. Tem de ser um conjunto de atributos separados, porque só assim se filtra por eles, se comparam entre si e se constroem listas de alternativas equivalentes. Prosa não se ordena. Quando os valores vivem dentro de frases, a única forma de responder a uma pergunta sobre todas as luminárias acima de determinado fluxo é ler todas as frases.

Por isso os atributos numéricos são guardados como números e admitem intervalos. As propriedades de valores fixos, como a cor da luz ou o grau de proteção, são taxonomias, de modo que uma etiqueta fica presa a muitos produtos e se corrige mais tarde num único sítio. A distinção parece administrativa e decide se um filtro por gama de potência é uma consulta à base de dados ou uma pesquisa de texto.

#Variantes sem duplicar a página

A mesma luminária existe em várias temperaturas de cor e vários níveis de potência. Para quem compra, são versões de uma coisa. Para o armazém, são linhas distintas com existências distintas. As duas leituras estão certas, e o modelo de conteúdo tem de servir ambas sem escolher um lado.

Se cada variante tiver o seu próprio registo, a página de produto multiplica-se numa dúzia de documentos quase idênticos, com as mesmas fotografias e quase o mesmo texto. Um motor de busca que olha para uma dúzia de documentos quase iguais escolhe um, e a escolha não é sua. Se as variantes não existirem de todo, não é possível mostrar disponibilidade. O que funcionou foi um registo principal com a descrição e a galeria, e variantes subordinadas que transportam apenas parâmetros e existências.

#Cache e existências puxam em sentidos opostos

Uma página é rápida quando sai pronta de uma memória intermédia, sem acordar o PHP e sem consultar a base de dados. Uma página é correta quando a disponibilidade ao lado do produto está certa neste momento, e a disponibilidade muda fora do site.

Se a cache guardar o documento uma hora, durante uma hora promete artigo que talvez já não exista. Se não guardar nada, cada visita paga a construção completa da página. Não há forma de ter as duas coisas enquanto a página for tratada como um objeto único.

A saída foi deixar de a tratar assim. Descrição, fotografias, dados técnicos e texto de apoio são estáveis durante semanas e podem ficar em cache de forma agressiva. Existências e disponibilidade são pedidas em separado, depois de a página já estar visível, e só elas decidem se o botão de encomenda está ativo. O documento que o browser recebe passa a ser igual para toda a gente, e o único elemento sensível ao momento está claramente delimitado.

#Quando o sistema externo deixa de responder

As existências e as alterações de sortido chegam por interface a partir de um sistema externo. Num desenho de arquitetura é uma seta. Em funcionamento é a parte cujo comportamento não se controla, e é precisamente por isso que existe uma camada própria entre o site e essa fonte.

O Redis serve aqui menos para acelerar consultas isoladas e mais para permitir que o site sobreviva à indisponibilidade de outra pessoa. Quando a fonte não responde, a camada intermédia devolve a última resposta conhecida em vez de uma zona vazia ou de uma mensagem de erro. Quem visita vê uma página que pode estar ligeiramente atrasada, não uma página que parece avariada, e a diferença entre essas duas coisas é a diferença entre uma encomenda adiada e uma encomenda perdida.

Os intervalos de atualização seguem a rapidez com que cada dado envelhece de facto, e não um valor único para tudo. A estrutura do catálogo e os parâmetros técnicos mudam raramente e podem vir numa passagem em bloco. As existências mudam em horas e seguem por um canal próprio e leve que toca apenas no campo de disponibilidade. Separar as duas coisas sai mais barato do que tornar uma importação grande mais rápida, porque não reduz o tempo de execução mas o volume do que é preciso calcular.

Há ainda uma regra que só se impõe ao fim de meses de operação: uma importação completa nunca pode sobrepor-se ao trabalho feito do lado do site. Textos comerciais, fotografias de ambiente, ligações a produtos relacionados e conteúdo orientado à pesquisa não vêm de um sistema de armazém. Se a importação não os poupar de forma explícita, mais cedo ou mais tarde come-os.

#O peso está nas imagens

Uma luminária vende-se pela fotografia, e fotografar luminárias é exigente e caro de transmitir. Costumam existir várias vistas, muitas vezes sobre fundo escuro, por vezes num ambiente montado. Um catálogo com algumas centenas de referências é, por isso, uma biblioteca de imagens com um site agarrado, e o markup ao lado disso é uma quantidade residual.

O trabalho de desempenho foi para onde estava a massa. Os ficheiros são processados no carregamento para exatamente os tamanhos que aparecem no site: miniatura na listagem, vista média na ficha de produto, resolução completa na ampliação. A miniatura nunca é o ficheiro da ampliação reduzido no browser, porque reduzir no browser poupa pixels e não bytes, e são os bytes que quem visita espera.

A distribuição passa por uma camada de CDN. As imagens não mudam depois de carregadas, portanto podem permanecer muito tempo nos nós de borda, e uma segunda visita a uma listagem não chega sequer ao servidor de origem. O lado alojado em AWS suporta o que não se entrega a partir da borda: armazenamento dos ficheiros originais, cópias de segurança e as operações de processamento que são dispendiosas mas acontecem uma única vez.

#Filtrar sem perder o endereço

A interface carrega resultados de forma assíncrona para que mudar um filtro não recarregue a página inteira. É uma melhoria discreta e traz consigo uma armadilha em que muitos catálogos desta época caíram.

Se uma lista de resultados filtrada não tiver endereço próprio, não pode ser guardada nos favoritos, não pode ser enviada a outra pessoa e não pode ser indexada. A camada dinâmica passa a trabalhar contra a visibilidade que o resto do projeto está a tentar construir. Por isso o estado dos filtros fica refletido no endereço mesmo sem recarregamento, e quem abre esse endereço a frio recebe a mesma lista de quem lá chegou aos cliques.

A operação pelo teclado pertence ao mesmo ponto, tal como a ligação entre as células de cabeçalho e as células de dados numa tabela de especificações. Sem essa ligação, um leitor de ecrã lê a especificação como uma sequência de números sem etiqueta, e a especificação é o conteúdo desta página, não o enfeite à volta dele.

#Visibilidade quando o texto é de toda a gente

Um site editorial escreve os seus textos. Um site de comércio herda-os. As descrições do fabricante seguem para todos os revendedores, as mesmas frases ficam numa dúzia de páginas concorrentes, e um motor de busca escolhe um documento entre uma dúzia de quase iguais. O mais pequeno do grupo raramente ganha.

A resposta está na camada que nenhum fabricante fornece. As vistas de categoria e de filtro recebem textos introdutórios próprios, escritos contra a pergunta que quem compra faz mesmo: em que difere a luz branca quente da branca neutra numa sala onde se está à noite, a partir de quando o grau de proteção conta de facto, o que significa uma especificação que nada diz sobre regulação de intensidade. Nada disto existe num ficheiro de fabricante, porque um fabricante descreve um produto e quem compra está a tomar uma decisão.

Os dados estruturados descrevem o produto numa forma legível para um motor de busca, e o HTML5 semântico organiza o documento para que os dados técnicos sejam uma tabela e não linhas dispostas a fingir que o são.

#Segurança na camada onde é barata

A proteção está no código e no servidor, e não numa extensão que promete segurança. A razão é mecânica e não ideológica: uma extensão de segurança corre no mesmo processo PHP que o resto do site, portanto só reage quando o pedido já chegou a esse processo. Limitar o ritmo de pedidos e filtrar na camada de borda trava o mesmo pedido mais cedo e por menos.

Dentro da aplicação conta o que se faz com os dados que entram. Os formulários são validados no servidor, porque validar no browser é comodidade para quem preenche e não um controlo. As operações que alteram estado estão protegidas contra serem desencadeadas a partir de outro sítio. As consultas à base de dados são parametrizadas, de modo que texto escrito por quem visita nunca passa a fazer parte da sintaxe da consulta.

#Manutenção depois do arranque

O acompanhamento corrente incluiu atualizações do núcleo, do tema e das extensões, revisão dos registos e cópias de segurança regulares. A lista soa a rotina, por isso vale a pena dizer em que difere, numa loja, da mesma lista num site de apresentação.

Uma atualização num catálogo ligado a um sistema externo não é uma operação de um clique. Uma alteração no núcleo pode tocar no comportamento da interface, e isso só se revela na sincronização seguinte. As alterações passaram por um ambiente de testes com uma cópia de dados reais, e não por uma instalação limpa com tema de demonstração. Um catálogo com centenas de referências e várias integrações comporta-se de forma completamente diferente de um WordPress vazio, e os casos de fronteira só aparecem sobre uma distribuição de dados realista.

As cópias de segurança têm aqui um papel de que se fala menos. O que vale numa loja não são os ficheiros mas a base de dados com as encomendas, portanto a reposição tem de ser ensaiada e não apenas afirmada. Uma cópia que ninguém nunca repôs é uma hipótese.

#O que passa para o projeto seguinte

O método passa: separar dados estáveis de dados que mudam depressa, tratar atributos como campos e taxonomias em vez de prosa, colocar uma camada intermédia à frente de qualquer sistema externo e testar contra uma cópia da produção. Estas decisões têm o mesmo aspeto em qualquer catálogo, seja qual for o ramo.

O modelo de conteúdo e as integrações não passam. Foram construídos à volta dos dados de um cliente e de um pedido da categoria Strony www, num projeto entregue em 2012 e desenvolvido ao longo de cerca de seis semanas. Um conjunto de atributos de iluminação não significa nada fora da iluminação, e a forma de uma troca de dados depende do que está do outro lado. O trabalho seguinte começa por uma análise do âmbito, e o orçamento vem depois dela e não antes.