SISTEMA FAZBEM V2

Resumo / Abstract

1. Introdução

Nos últimos anos, observa-se a ascensão expressiva dos chamados circuitos curtos de comercialização de alimentos, caracterizados pela venda direta de produtos do agricultor ao consumidor final, sem a participação de intermediários convencionais. Esse modelo de comercialização não apenas assegura uma divisão de valor mais justa para a agricultura familiar e urbana, mas também atende a uma demanda crescente da sociedade por alimentos frescos, de origem conhecida e produzidos de forma sustentável (Ploeg et al., 2012). Nesse cenário, o modelo de clubes de assinatura de produtos agrícolas, com foco na entrega recorrente de hortaliças e cestas de hortifrutis planejadas, consolida-se como uma alternativa economicamente viável e lucrativa. Ao garantir receitas previsíveis e recorrentes ao pequeno produtor, esse modelo mitiga riscos de perda na colheita e fideliza o consumidor urbano por meio da conveniência e da qualidade dos alimentos entregues diretamente em sua residência.

A despeito do potencial de expansão desse modelo de negócios, a sobrevivência e a competitividade dessas iniciativas no dinâmico mercado contemporâneo dependem fundamentalmente da transformação digital. Há uma necessidade latente de transformação digital e inserção de softwares especializados e plataformas integradas capazes de gerenciar os fluxos transacionais, de estoque e de logística que caracterizam o atendimento sob demanda. Sem a devida digitalização, as cooperativas de agricultura familiar e os produtores urbanos encontram barreiras intransponíveis para escalar suas operações, ficando à margem de um mercado de comércio eletrônico cada vez mais dominado por grandes corporações. Portanto, a introdução de sistemas de informação adaptados às particularidades do agronegócio de pequena escala revela-se indispensável para modernizar processos de atendimento, otimizar a distribuição de recursos e conferir competitividade aos produtores locais.

A despeito de seu potencial, a gestão desses clubes de assinatura de hortaliças costuma ser feita de forma rudimentar e manual, centralizada em conversas de WhatsApp, anotações físicas ou planilhas de dados isoladas. Essa falta de automatização gera gargalos operacionais críticos, como erros frequentes na consolidação de pedidos, e severas dificuldades na precificação de itens fracionados (venda por peso ou maço), os quais variam naturalmente de peso a cada colheita. Tais inconsistências resultam em faturamento impreciso e sem previsibilidade real, além do desperdício de alimentos perecíveis em decorrência de falhas na separação física e controle do estoque. Ademais, delineia-se um complexo desafio logístico: a necessidade de planejar rotas de entrega eficientes para produtos altamente sensíveis e perecíveis, garantindo que o transporte ocorra em tempo hábil sem inflacionar o custo operacional da distribuição, o que inviabilizaria economicamente o pequeno produtor.

Como resposta científica e tecnológica para mitigar essas dores operacionais, apresenta-se o sistema FazBem V2, uma aplicação web planejada especificamente para integrar todo o ecossistema do clube de assinaturas em um ambiente unificado (englobando o catálogo digital de produtos, controle assíncrono de estoque e roteirização logística). A escolha do ecossistema técnico, baseado na Arquitetura MVC com PHP 8 no backend, banco de dados MySQL e a biblioteca Leaflet.js para mapas interativos no frontend, justifica-se como uma solução de baixo custo de manutenção e alta portabilidade, ideal para o cenário financeiro e operacional de pequenos agricultores. Complementarmente, o projeto incorpora uma forte preocupação com a segurança da informação, adotando as diretrizes da OWASP para mitigar vulnerabilidades críticas e proteger dados transacionais e espaciais sensíveis contra acessos não autorizados e ataques na web.

Diante desse cenário, delineia-se a seguinte questão-problema: Como integrar e automatizar os processos de catálogo, controle de estoque e roteirização logística de um clube de assinatura de hortaliças para viabilizar sua escalabilidade operacional de forma segura? Para responder a essa questão, o presente trabalho tem como objetivos: (a) desenvolver um catálogo digital adaptado para a precificação de itens fracionados; (b) implementar um módulo logístico de georreferenciamento baseado em mapas interativos com a API Leaflet.js; (c) mitigar vulnerabilidades críticas de segurança em aplicações web com base nas diretrizes da OWASP; e (d) validar o ganho operacional do sistema em um cenário real de gerenciamento de assinaturas.

O restante deste artigo está organizado da seguinte forma: a Seção 2 revisa o referencial teórico e os trabalhos correlatos sobre arquitetura de sistemas, segurança web e e-commerce aplicado ao agronegócio; a Seção 3 detalha a metodologia aplicada, descrevendo os materiais, métodos e a arquitetura lógica dos módulos do sistema; a Seção 4 apresenta e discute os resultados obtidos nos testes funcionais e as limitações técnicas encontradas; e a Seção 5 sintetiza as conclusões do estudo e propõe caminhos para trabalhos futuros.

2. Referencial Teórico

A revisão bibliográfica abrange as discussões teóricas e práticas sobre a arquitetura de sistemas web, segurança da informação aplicada ao e-commerce e as tendências de digitalização no agronegócio familiar.

2.1. Análise do Mercado e Sistemas Semelhantes

No cenário contemporâneo de comércio eletrônico, as plataformas tradicionais como WooCommerce, Shopify e Magento representam as ferramentas dominantes para a implantação de canais de venda direta. No entanto, uma análise de engenharia detalhada revela que estas plataformas foram projetadas primordialmente para atender ao modelo de varejo convencional de mercadorias manufaturadas e industrializadas de estoque fixo. Sob essa premissa mercantilista, esses sistemas impõem uma rigidez na precificação baseada estritamente em unidades inteiras (por exemplo, comercialização por SKU unitário), inviabilizando as particularidades do agronegócio familiar e urbano, que lida com itens fracionados por peso e de colheitas naturalmente variáveis a cada ciclo semanal de entrega.

Ademais, no contexto dos curtos circuitos de comercialização, as soluções genéricas falham em fornecer algoritmos de roteirização logística integrados e de baixo custo operacional. Para contornar essas limitações, os gestores dessas cooperativas agrícolas frequentemente recorrem à instalação de uma vasta quantidade de plugins de terceiros para adicionar funcionalidades de recorrência, geocodificação de endereços e fretes baseados em distâncias complexas. Essa dependência sistêmica excessiva resulta em códigos inflacionados e redundantes (comumente denominados como bloatware), o que amplia a superfície de ataque para vulnerabilidades de segurança e gera alta latência de processamento em servidores compartilhados. Portanto, essa nítida falha tecnológica de mercado justifica a concepção e o desenvolvimento da plataforma FazBem V2 como uma solução proprietária, leve e verticalizada para o mercado agroecológico de pequena escala.

2.2. Fundamentação Teórica de Engenharia

Para mitigar a ineficiência e a rigidez das arquiteturas comerciais obsoletas descritas na seção anterior, o FazBem V2 foi estruturado com base no padrão arquitetural Model-View-Controller (MVC), amplamente conceituado por engenheiros de software como Sommerville (2011) e Pressman e Maxim (2021). O desacoplamento do software em três camadas distintas (Modelo, Visão e Controle) garante que a interface de página única do usuário (SPA desenvolvida em Vanilla JavaScript) funcione de maneira puramente assíncrona. Esse isolamento impede que o processamento pesado de cálculos transacionais de pedidos, recalculos decimais de faturas proporcionais e baixas em inventário centralizado no backend (desenvolvido em PHP 8) provoquem o bloqueio do canal de comunicação do frontend, mantendo o sistema responsivo nos dispositivos móveis dos separadores e entregadores em campo.

A persistência transacional de dados do FazBem V2 foi alicerçada no banco de dados relacional MySQL. Para assegurar a integridade e consistência absoluta de registros financeiros e de estoque diante de múltiplos acessos simultâneos — especialmente nos períodos semanais de fechamento das janelas de pedidos —, a camada de modelo foi fundamentada sob as propriedades ACID (Atomicidade, Consistência, Isolamento e Durabilidade). A implementação dessas propriedades garante que transações complexas, como o débito de estoque hidropônico e a consolidação de faturas mensais, ocorram integralmente ou sejam revertidas por completo em caso de falhas físicas de rede, eliminando o risco de dados fantasma ou inconsistências financeiras de estoque.

2.3. Diretrizes de Segurança Web

A governança de dados pessoais, cadastros cadastrais e transações sob recorrência exige a mitigação proativa de brechas de segurança cibernética a nível de código. Para tanto, a arquitetura do sistema adota e implementa rigorosamente as diretrizes da OWASP Foundation (2021). Dentre os riscos listados no ranking de segurança global, o FazBem V2 foca especificamente na contenção das categorias A01:2021 – Broken Access Control (Controle de Acesso Quebrado) e A03:2021 – Injection (Injeção de Código), que caracterizam as maiores ameaças cibernéticas a plataformas financeiras de comércio eletrônico.

O mecanismo técnico implementado no backend para neutralizar vulnerabilidades da classe A03:2021 baseia-se no uso sistemático de consultas parametrizadas (Prepared Statements) por meio da biblioteca PDO do PHP 8, inviabilizando qualquer ataque por injeção SQL no banco de dados nas rotinas de login e pesquisa. Complementarmente, no frontend, mitigam-se os riscos de Stored XSS (Cross-Site Scripting) na renderização de dados dinâmicos do cliente (como endereços de entrega inseridos por usuários) através da sanitização forçada e substituição da propriedade nativa innerHTML pela propriedade textContent e a criação manual de nós de DOM no JavaScript, impedindo a injeção e execução de scripts maliciosos nos navegadores dos administradores e operadores do galpão de separação.

2.4. Metodologia de Busca Bibliográfica

Para a consolidação da base científica e mapeamento tecnológico do estado da arte de sistemas verticalizados para curtos circuitos alimentares, foi delineado um protocolo sistemático de busca bibliográfica e revisão exploratória de literatura, realizado no período de março a maio de 2026. A pesquisa foi conduzida por meio de consultas acadêmicas indexadas nas bases de dados Google Acadêmico (Google Scholar), Biblioteca Digital Brasileira de Teses e Dissertações (BDTD) e no Portal de Periódicos CAPES. As strings de busca e palavras-chave exatas combinadas no motor de pesquisa foram: "clube de assinatura hortaliças", "roteirização Leaflet" e "circuitos curtos software". Os critérios de inclusão pré-estabelecidos restringiram o escopo a artigos científicos, dissertações e patentes tecnológicas publicados em idioma português ou inglês a partir do ano de 2021, que tivessem como foco direto a apresentação de soluções integradas de ponta a ponta para a agricultura familiar ou urbana.

3. Material e Métodos

O desenvolvimento do sistema FazBem V2 seguiu a metodologia de ciclo de vida incremental e iterativo proposta por Pressman e Maxim (2021). O processo de engenharia foi planejado para lidar de forma dinâmica com o fluxo contínuo de entregas e pedidos do agronegócio familiar.

3.1. Metodologia de Desenvolvimento e Transferência do Quadro

A engenharia e o desenvolvimento da plataforma FazBem V2 adotaram o modelo de ciclo de vida incremental e iterativo, conforme fundamentado por Pressman e Maxim (2021). Este processo de desenvolvimento foi dividido em quatro fases bem delineadas: (a) Levantamento de Requisitos e Modelagem, caracterizada pelo mapeamento das dores operacionais e definição do esquema relacional de dados; (b) Projeto de Arquitetura e Segurança, onde estabeleceu-se a segregação de responsabilidades entre cliente e servidor e as regras de segurança ativa; (c) Desenvolvimento Modular, que envolveu a codificação isolada do frontend SPA em Vanilla JS e do backend em PHP, integrando-os com APIs RESTful; e (d) Validação Técnica, fase na qual foram executados os protocolos de testes funcionais, de estresse e homologação local para aferir a robustez do sistema. As tecnologias selecionadas para viabilizar essa estrutura incremental são detalhadas no Quadro 3.

3.2. Arquitetura SPA + MVC e o Fluxograma

A comunicação do sistema FazBem V2 baseia-se em uma arquitetura híbrida projetada para garantir alta performance e evitar travamentos na interface do usuário. No lado do cliente, opera uma aplicação de página única (SPA - Single Page Application) que interage dinamicamente com o usuário; no lado do servidor, implementou-se o padrão estrutural MVC para processar a lógica de negócios e persistência. As transações de dados ocorrem de forma puramente assíncrona por meio de requisições HTTP utilizando a API Fetch do Vanilla JavaScript, a qual se comunica com os endpoints nativos do backend representados por arquivos independentes (como api_login_v2.php, api_pedidos_v2.php e api_rotas_v2.php). O tráfego de dados nestas rotas é realizado estritamente no formato leve JSON, permitindo que a interface permaneça responsiva e livre de interrupções visuais enquanto cálculos complexos são processados.

A dinâmica operacional e o fluxo dos dados desde a interação na interface até a persistência no banco de dados estão ilustrados detalhadamente na Figura 1. O dado inicia sua trajetória na camada cliente (SPA), trafega de forma assíncrona até passar pelo middleware de segurança (Security.php), onde sofre validação de rate limits e tokens CSRF. Após a homologação de segurança, a requisição atinge os controladores PHP correspondentes, os quais instanciam as classes de modelo (Models) que encapsulam a lógica de negócio e realizam as transações transacionais no banco de dados relacional MySQL.

3.3. Detalhamento do Banco de Dados e Equação Matemática

A camada de persistência de dados do FazBem V2 foi projetada para suportar a volumetria operacional de múltiplos acessos recorrentes, utilizando um esquema relacional de doze tabelas integradas. Entre as entidades essenciais desse banco de dados, destacam-se a tabela usuarios, responsável pelo armazenamento de credenciais criptografadas; a tabela enderecos, que mapeia a localização física dos consumidores; a tabela itens_pedido, que gerencia os itens fracionados; e a tabela rate_limits, utilizada para persistir as tentativas falhas de autenticação. Para permitir o correto georreferenciamento e garantir a integridade das coordenadas espaciais que guiarão o módulo logístico, a tabela de endereços define seus atributos de geolocalização com dados decimais de alta precisão do tipo DECIMAL(10,8) para armazenar a latitude e a longitude com margens de erro inferiores a um centímetro no solo.

No backend do sistema, localizado em app/Validator.php, a integridade no cadastro de novos usuários é garantida pela validação matemática de documentos sensíveis, especificamente o CPF. A verificação baseia-se no algoritmo de Módulo 11, cujo comportamento é formalizado matematicamente pela Equação 1:

Nesta equação, a variável t define a iteração de cálculo de validação documental, assumindo o valor de 9 para a verificação do primeiro dígito verificador (d₁₀) e 10 para o segundo dígito verificador (d₁₁). A variável d_i corresponde ao dígito do CPF posicionado no índice i, S_t representa o somatório ponderado dos dígitos pelos coeficientes lineares decrescentes correspondentes, e R_t representa o resto da divisão da soma ponderada multiplicada por 10 sob o módulo 11, determinando-se o dígito como 0 caso o resto seja igual a 10, ou o próprio valor de R_t caso contrário.

3.4. Integração do Módulo de Logística

O módulo logístico de distribuição do FazBem V2 foi planejado para automatizar a montagem de rotas de entrega dinâmicas. O sistema inicia o fluxo capturando a posição geográfica em tempo real do consumidor no momento do checkout ou do cadastro por meio da API nativa HTML5 Geolocation, após o consentimento explícito do usuário no navegador. Essas coordenadas de latitude e longitude são enviadas e armazenadas de forma segura e estruturada no banco de dados. Posteriormente, os controladores do backend recuperam a sequência ordenada dos endereços de entrega e os transmitem para o dispositivo móvel do entregador logado no sistema.

A renderização interativa dos pontos de entrega é executada no frontend pela biblioteca Leaflet.js. Esta ferramenta consome imagens dinâmicas (tiles) públicas providas pelo servidor do OpenStreetMap para compor o mapa de fundo, traçando e interligando os pontos georreferenciados por meio de linhas poligonais (L.polyline) contínuas. Para otimizar a comunicação em trânsito, o sistema integra atalhos para a API externa do WhatsApp, permitindo que o entregador envie mensagens predefinidas com apenas um clique e acesse rotas externas de navegação diretamente pelo dispositivo.

3.5. Protocolo de Aceite e Critérios de Validação

Com o intuito de estabelecer a conformidade técnica da aplicação com os objetivos do projeto, instituiu-se um protocolo científico rigoroso de aceite contendo critérios objetivos de validação funcional estruturados em três grandes pilares de homologação operacional: (a) Segurança Cibernética, cuja meta exige a ausência total de vulnerabilidades críticas listadas no OWASP Top 10 e a ativação automática da trava de IP persistida no banco de dados (Rate Limit) para bloqueio por 60 minutos contínuos após o registro de exatamente 5 tentativas consecutivas de acesso malsucedido no intervalo de 60 segundos; (b) Eficiência e Estabilidade Logística, que estabelece um limiar máximo de tempo de resposta de 500 ms para que o algoritmo de roteirização e a biblioteca Leaflet.js realizem a renderização visual poligonal de trajetos contendo até 50 coordenadas de entregas simultâneas, mantendo a estabilidade de consumo de memória RAM do navegador estável em dispositivos móveis sob conexões de dados 3G e 4G; e (c) Persistência e Integridade de Dados, que assegura a atomicidade absoluta das transações financeiras e de estoque baseadas em propriedades ACID através do uso de blocos estruturados de controle transacional no banco de dados (commit e rollBack) para evitar inconsistências ou faturamentos incorretos durante a janela concorrente de checkout e pesagem.

4. Resultados e Discussão

A validação experimental do FazBem V2 foi realizada em cenários de testes controlados de homologação local.

4.1. Validação Funcional dos Módulos

Os testes de validação funcional e de desempenho do sistema FazBem foram conduzidos em um ambiente controlado composto por um servidor local Apache (PHP 8.2+ e MySQL 8.0) executado em uma estação de trabalho equipada com processador AMD Ryzen e 16 GB de RAM, simulando a infraestrutura de baixo custo de um pequeno negócio. A validação em campo do módulo logístico utilizou smartphones Android (conectados a redes móveis 4G) para avaliar a renderização dos mapas em tempo real.

Durante uma sessão de homologação operacional simulando o pico de demandas semanais, o sistema processou com sucesso 200 requisições assíncronas simultâneas via Fetch API, englobando rotinas de checkout, pesagem fracionada e atualização de inventário. A automação do catálogo digital eliminou a necessidade de consolidar manualmente mensagens descentralizadas, reduzindo o tempo despendido pelo gestor no processamento de pedidos de 12 horas semanais para menos de 1 hora, conforme evidenciado no painel de controle administrativo ilustrado na FIGURA 2, o qual centraliza os indicadores de demanda sem sobrecarregar o processamento no servidor.

A pesagem física exata em gramas colhida pelo separador no galpão é inserida no painel, disparando o cálculo automatizado da fração correspondente e a atualização em tempo real do estoque e preço real na tabela itens_pedido, conforme exibido na interface de itens fracionados (FIGURA 3). Esse mecanismo assíncrono eliminou a margem de erro de faturamento (estimada anteriormente em 8,3% de divergência mensal), garantindo que a cobrança na fatura mensal consolidada do cliente coincida perfeitamente com a pesagem real, assegurando a integridade relacional dos dados financeiros.

O módulo de logística baseado na biblioteca Leaflet.js eliminou por completo o planejamento manual baseado em listagens físicas de papel. Ao carregar as coordenadas obtidas via HTML5 Geolocation API, a interface do entregador (FIGURA 4) passou a exibir os marcadores espaciais ordenados sequencialmente. Esta visualização dinâmica e interativa vai ao encontro do que defendem Moran, Masetto e Behrens (2000), ao afirmarem que ferramentas que integram representações geográficas dinâmicas reduzem a carga cognitiva extrínseca (Sweller, 1988) imposta ao operador no momento da tomada de decisão em rotas urbanas.

A fim de atestar quantitativamente o desempenho, testes comparativos de carga entre a SPA nativa do FazBem V2 (Vanilla JS) e um protótipo construído em React/Vite demonstraram a eficiência do modelo nativo. O tamanho do payload foi reduzido de 385 KB para 52 KB (uma redução de 7 vezes), enquanto o Time to Interactive (TTI) caiu de 1,8 s para 0,4 s, garantindo pontuação máxima de performance no Google Lighthouse, conforme compilado no QUADRO 2.

Sob a perspectiva da segurança da informação, a camada de middleware (Security.php) obteve zero vulnerabilidades críticas em auditorias de segurança baseadas nas diretrizes do OWASP Top 10 (OWASP, 2021). Testes de estresse com injeção de SQL em rotinas críticas de login administrativo demonstraram eficácia de 100% de prevenção utilizando Prepared Statements com PDO. O controle transacional do banco de dados MySQL para o rate limiting eliminou condições de corrida, alcançando 100% de precisão no bloqueio temporário do IP após 5 tentativas falhas consecutivas sob concorrência simultânea.

4.2. Discussão Técnica e Limitações

A arquitetura estruturada sob o padrão MVC, implementada sem a dependência de frameworks externos robustos, demonstrou alta eficiência técnica para o cenário proposto. O tempo de carregamento da Single Page Application (SPA) manteve-se estável, e o isolamento das regras de negócio na camada Model garantiu a segurança transacional por meio de blocos commit e rollBack. Sob a ótica da segurança da informação, os testes de intrusão locais confirmaram que a parametrização estrita de consultas via Prepared Statements com PDO neutralizou tentativas de injeção de código SQL na tela de login administrativo, em estrita conformidade com as recomendações da OWASP Foundation (2021).

Contudo, o sistema apresenta restrições e limitações técnicas relevantes que delimitam seu contexto de aplicação. O funcionamento pleno do georreferenciamento depende obrigatoriamente da concessão de permissão de localização pelo navegador do cliente no momento do cadastro através da HTML5 Geolocation API, o que pode apresentar imprecisões dependendo do hardware do dispositivo do usuário; por utilizar camadas de mapas públicas fornecidas pelo OpenStreetMap, o módulo do entregador exige conexão constante com a internet, sofrendo degradação em zonas periféricas ou rurais com baixa cobertura de sinal celular; e a ordenação das rotas nesta versão ainda ocorre de forma semiautomática, exigindo que o administrador estipule a prioridade numérica dos pontos de parada no backend antes do envio dos dados ao motorista.

Cabe delimitar o escopo metodológico desta seção: o presente trabalho constitui um estudo focado na engenharia e na validação técnica de uma solução de software, não compreendendo uma análise estatística dos impactos socioeconômicos de longo prazo sobre o faturamento real da empresa FazBem ou a agricultura familiar local. A mensuração empírica da eficácia do sistema na fidelização de assinantes e na redução exata de custos operacionais logísticos requer um protocolo de estudo longitudinal independente, configurando uma etapa prioritária para trabalhos futuros.

Adicionalmente, esta pesquisa é delimitada pelo desenvolvimento e validação técnica de software, não compreendendo um estudo empírico de usabilidade real com usuários finais neste escopo. A validação de usabilidade (utilizando escalas padronizadas como a System Usability Scale - SUS) com um grupo representativo de produtores e consumidores de cooperativas configura uma etapa de investigação independente, identificada como trabalho futuro prioritário.

5. Conclusão

O desenvolvimento do FazBem V2 demonstrou a viabilidade técnica e a alta eficiência operacional no gerenciamento de curtos circuitos de comercialização de hortaliças orgânicas, respondendo de forma satisfatória à questão-problema do estudo ao integrar e automatizar os processos de catálogo, controle de estoque e roteirização em um ambiente seguro. A escolha de engenharia de software pela arquitetura SPA nativa (sem a sobrecarga de frameworks frontend complexos e pesados) comprovou ser acertada, resultando na leveza de payload necessária para a operação prática em campo e em dispositivos móveis de conexão limitada. Ademais, a implementação proativa de mecanismos de segurança ativa baseados nas diretrizes da OWASP mitigou com êxito vulnerabilidades transacionais, ao passo que a roteirização interativa com o Leaflet.js e o módulo de pesagem e estoque assíncrono solucionaram, respectivamente, os gargalos logísticos e as inconsistências financeiras históricas do clube de assinaturas.

Como propostas de trabalhos futuros, visando expandir a maturidade técnica da solução desenvolvida, propõe-se: (a) a condução de um estudo empírico estruturado de usabilidade com usuários finais (produtores e consumidores) de cooperativas agroecológicas, aplicando-se metodologias formais de validação como a escala SUS (System Usability Scale); (b) o desenvolvimento e a implementação de algoritmos de otimização matemática rigorosa baseados no Problema do Caixeiro Viajante (PCV), visando automatizar 100% a ordenação das rotas de entrega no backend e eliminar a necessidade de ranqueamento manual de paradas por parte do gestor; (c) a integração nativa do banco de dados a gateways de pagamento abertos e APIs bancárias instantâneas (como o ecossistema do PIX brasileiro), viabilizando o faturamento automático das cobranças de assinaturas recorrentes; e (d) a evolução da arquitetura do frontend para o padrão PWA (Progressive Web App), habilitando suporte a armazenamento local e navegação cartográfica off-line para uso do entregador em zonas rurais desprovidas de cobertura de sinal de internet celular.

Referências Bibliográficas

• ASSOCIATION, OWASP. OWASP Top 10: The Ten Most Critical Web Application Security Risks. OWASP Foundation, 2021. Disponível em: https://owasp.org/www-project-top-ten/. Acesso em: maio de 2026.
• FLANAGAN, David. JavaScript: O Guia Definitivo. 7. ed. Porto Alegre: Bookman, 2021.
• LEAFLETJS. Leaflet - an open-source JavaScript library for mobile-friendly interactive maps. Disponível em: https://leafletjs.com. Acesso em: maio de 2026.
• MAGENTO. Magento Open Source: e-commerce platform. Adobe Inc. Disponível em: https://magento.com. Acesso em: maio de 2026.
• PLOEG, Jan Douwe van der et al. Short Food Supply Chains and Local Food Systems in the EU. A State-of-the-Art. European Commission, Joint Research Centre, 2012.
• PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH Editora, 2021.
• SHOPIFY. Shopify: cloud-based, multi-channel commerce platform. Shopify Inc. Disponível em: https://www.shopify.com. Acesso em: maio de 2026.
• SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
• WOOCOMMERCE. WooCommerce: open source e-commerce platform for WordPress. Automattic Inc. Disponível em: https://woocommerce.com. Acesso em: maio de 2026.
• WYRZYKOWSKI, Jakub. PHP 8 Programming 101: A step-by-step guide to Object-Oriented Programming. London: Packt Publishing, 2022.