Plantas artificiais de elevada qualidade - sztuczne-rosliny.pl

#sztuczne-rosliny.pl, loja online de plantas artificiais de alta qualidade

Há um tipo de produto nesta loja que quebra a regra sobre a qual assenta qualquer catálogo: a ideia de que um produto é um objeto com um preço e um stock. Uma parede verde tem uma área, é montada a partir de módulos e a sua disponibilidade resulta da disponibilidade das peças. Um arranjo em vaso é um conjunto de várias plantas e de um recipiente, vendido como um todo e armazenado às peças. Decidir como tratar estes casos foi a primeira questão de arquitetura do projeto.

A empresa importa e distribui plantas artificiais, funciona também como grossista e fornece composições de verde para escritórios, hotéis, restaurantes, centros comerciais e stands de feira, com montagem e aconselhamento no local. A sede fica em Varsóvia e existe uma delegação em Białystok. O sortido inclui árvores, ervas, flores e vasos, com variantes ignífugas e resistentes a radiação ultravioleta, além de paredes verdes (fonte: sztuczne-rosliny.pl).

A implementação demorou cerca de seis semanas. A camada técnica é WordPress com um modelo de produto próprio, cache de objetos em Redis, HTML5, CSS3 e SASS na interface, AJAX na pesquisa, armazenamento de ficheiros em S3 com CDN à frente e monitorização após o lançamento. O layout e a colocação dos elementos vieram do cliente.

#Produtos compostos e onde traçar a fronteira

Existem dois caminhos para tratar um conjunto, e a escolha entre eles não é um detalhe. O primeiro trata o conjunto como um registo próprio, com descrição e stock independentes dos componentes. É simples e aguenta enquanto os conjuntos forem poucos; parte no momento em que um componente é descontinuado, porque o conjunto continua a parecer disponível. O segundo descreve o produto como composição e calcula a disponibilidade a partir das peças. É mais correto e mais caro, porque cada listagem passa a ter de calcular mais do que está escrito no registo.

A fronteira ficou onde costuma fazer sentido: o que se compra de prateleira é um registo, e o que é feito à medida é um pedido, com ficha informativa e conversa. Fingir que uma parede verde com área definida é um produto com botão de compra termina numa encomenda que não se consegue executar sem um telefonema. Nesse caso é melhor prever o telefonema no desenho do site do que justificá-lo depois.

Há ainda um efeito prático desta separação. Ao manter o feito à medida fora do carrinho, o carrinho pode ser simples e previsível, e as regras de stock, prazos e transporte não precisam de acomodar casos que na prática são sempre negociados. Um checkout que tenta cobrir tudo acaba por cobrir mal o caso mais frequente.

#Os ficheiros não pertencem ao servidor de aplicação

Neste sortido a fotografia carrega quase todo o peso da página e isso não se resolve retirando imagens, porque é pela imagem que o comprador avalia a folha e o assentamento no vaso. A pergunta, portanto, não é quantas fotografias existem, mas onde ficam guardadas.

Ficam em S3 e são entregues por CDN, e não a partir do sistema de ficheiros do servidor de aplicação. As razões são práticas. O servidor de aplicação deve montar páginas e não enviar gigabytes de imagens, porque as duas coisas disputam os mesmos processos. A cópia de segurança deixa de crescer ao ritmo do catálogo, por isso um ambiente de testes fica de pé em minutos e não numa hora. E uma mudança de servidor deixa de arrastar uma montanha de ficheiros, porque os ficheiros não estão presos à máquina.

O compromisso faz parte da descrição. Extensões que esperam encontrar as imagens diretamente no disco deixam de funcionar por inércia, e a geração de miniaturas passa a ser uma decisão consciente. O segundo custo é a invalidação de cache: uma imagem substituída no mesmo endereço não chega ao navegador que já a guardou, por isso uma versão nova recebe um nome de ficheiro novo. Sem essa regra, a redacção corrige uma fotografia, continua a ver a antiga e perde a confiança no backoffice.

Numa listagem o que decide não é o peso de uma imagem mas a soma. Uma página de categoria com cinquenta produtos carrega cinquenta ficheiros, por isso as miniaturas são geradas no tamanho em que aparecem e não reduzidas pelo navegador a partir do ficheiro da ficha de produto.

#Dois armazéns por trás de uma ficha

Varsóvia e Białystok significam que a mesma mercadoria pode estar em dois sítios. No retalho isso é indiferente, porque conta a soma. No negócio de projeto não é: quarenta unidades distribuídas por duas localizações dão uma data de montagem diferente de quarenta unidades no mesmo sítio.

Daqui resulta que o stock é mantido por localização mesmo quando a ficha mostra um total. O total calcula-se a partir das partes a qualquer momento; as partes nunca se recuperam a partir do total. É a mesma regra que antes determinou guardar parâmetros em campos e não em texto corrido: os dados guardam-se na forma mais detalhada que faça sentido e simplificam-se apenas na apresentação.

Neste sortido acresce um pormenor. Plantas de duas remessas diferem visivelmente no tom de verde, por isso uma receção precisa de quarenta unidades do mesmo lote e não de quarenta unidades vindas de onde calhar. Essa informação pertence à página, caso contrário é perguntada em cada pedido e a resposta é sempre a mesma.

#O catálogo é trabalho diário

Uma loja com este sortido não fica pronta no dia do lançamento. A oferta muda a cada entrega e quem trata do catálogo trabalha no backoffice todos os dias. Se acrescentar uma planta exigir um programador, o catálogo afasta-se da realidade numa única época, por muito bem que parecesse no dia da entrega.

O modelo de produto assenta por isso em tipos de conteúdo próprios e campos personalizados. Altura, material, cor, tipo de vaso, fabricante e a indicação de variante ignífuga ou resistente a ultravioleta são valores na base de dados e não frases numa descrição. A redacção preenche um formulário em vez de escrever um texto em que é preciso lembrar a ordem das informações, e cada registo fica igual, porque o aspeto é tarefa do template e não de quem introduz dados.

A loja apresenta a oferta também em inglês, o que obriga a uma decisão antes da primeira tradução: cada versão linguística tem endereço próprio, ou o mesmo endereço troca de conteúdo conforme uma definição. Só a primeira hipótese serve para motores de busca, porque um endereço cujo conteúdo muda com um cookie não pode ser ligado, indexado nem colocado em cache de forma útil. A seguir decide-se que páginas têm sequer correspondência: uma ficha tem, uma categoria tem, um resultado de filtro de preferência não, sob pena de o número de endereços crescer com cada combinação nas duas línguas.

Para a redacção há uma consequência agradável. Como os campos mensuráveis são neutros em relação à língua, na segunda versão resta traduzir texto, e um artigo sem tradução é visível como um campo vazio numa lista. Lacunas em listas fecham-se; omissões silenciosas não.

#O que fica visível depois do lançamento

A monitorização fez parte da implementação e não é um extra vendido à parte, e vigia três coisas distintas. Primeiro a disponibilidade, a pergunta mais simples de todas, se o site responde. Depois os erros de aplicação, que numa loja raramente derrubam tudo e costumam estragar um único caminho: uma actualização pode desafinar o passo de envio enquanto o resto funciona, e então ninguém comunica nada durante uma semana. Por fim o tempo de resposta nas vistas que realmente custam, ou seja a lista de categoria com filtros activos e não a página inicial.

A carga é sazonal, e isso muda o que vale a pena medir. A procura concentra-se nas semanas em que as empresas preparam espaços, antes das festas ou depois de obras, pelo que uma média mensal esconde exactamente o momento que interessa. Um gráfico útil mostra a pior hora do dia e não o dia inteiro. Nessa hora decide sobretudo quantos pedidos chegam à aplicação, já que as imagens são entregues pela CDN e a cache de objetos em Redis encurta a montagem das páginas.

A segurança resume-se a gestos aborrecidos e regulares: actualizações do núcleo, do tema e das extensões, leitura de logs, controlo de acessos e teste de cada alteração numa cópia antes de ir para produção. Onde passam transacções reais por um formulário, uma actualização feita diretamente em produção é um risco operacional e não uma poupança de tempo.

#As nossas ações

Do nosso lado esteve a implementação da loja a partir do layout fornecido pelo cliente: o modelo de produto com campos paramétricos, as vistas de catálogo e de ficha, a pesquisa com filtragem, o armazenamento de ficheiros em S3 com entrega por CDN, a camada de cache, a preparação do catálogo para indexação e a monitorização após o arranque. O requisito que organizou as restantes decisões era manter o catálogo sem programador e encurtar o caminho entre a entrada e o produto certo.

Vale a pena acrescentar o que isto significa para os pedidos de projeto. Altura total e diâmetro do vaso, execução ignífuga e resistência a ultravioleta estão em campos próprios porque são exactamente os critérios pelos quais um arquiteto ou um hotel decide. Tê-los como filtros não é conforto: é a pré-selecção que de outro modo o comercial faria por email, pedido a pedido.

#Resumo

Três decisões definiram a qualidade desta implementação e nenhuma delas pertence à camada gráfica. Parâmetros guardados como campos, e não como frases, dão a filtragem e a pré-selecção de que vivem os pedidos de projeto. A saída dos ficheiros para S3 com entrega por CDN retira ao servidor de aplicação trabalho que não lhe compete e mantém as cópias de segurança pequenas. A monitorização apontada aos caminhos que custam encurta o tempo entre a falha de um passo e a sua descoberta. Não tenho medições do efeito destes trabalhos, por isso não apresento nenhuma.

Para um projeto seguinte transita a camada técnica e o método: WordPress com modelo de produto próprio, Redis, S3 com CDN, monitorização e testes de filtros e pagamentos numa cópia de produção. Não transita o dicionário de atributos desta loja nem as suas integrações, porque nasceram para um sortido concreto e formatos de dados concretos. Um segundo projeto começa por uma análise de âmbito, e a proposta vem a seguir.