Ligar o Lemmid Store às cozinhas

App de pedidos de comida

A app que estou a construir chama-se Lemmid Store, é uma app fácil de usar que permite às pessoas fazer (e pagar) pedidos de comida para levar. Podes encontrar todos os artigos sobre o Lemmid Store aqui.

Sistemas externos

A necessidade de ligar a sistemas externos nasce do desejo de integrar a app de pedidos nos processos de negócio do serviço de entrega de comida. Pensa em coisas como:

• recolher os dados dos pedidos em registos administrativos (por exemplo, a contabilidade)
• encaminhar os pedidos para as cozinhas, onde as refeições são preparadas e embaladas
• dar acesso fácil a informação de rotas, mostrando onde a comida deve ser entregue
• agendar pedidos de comida destinados a entregas posteriores

Desafios de ligar a sistemas externos

Pode ser que não te apercebas, mas ligar a sistemas externos pode ser complicado. Se pensares na app de pedidos como uma espécie de "motor" (como no teu carro), no fundo queres integrar este motor com peças externas. Como podes imaginar, nem todas as peças servem igualmente bem debaixo do capot, por assim dizer. Para tornar as coisas ainda mais difíceis: não sabes ao certo quão fiáveis são as peças externas. Tens de desenhar a tua integração de forma a que diferentes peças externas se possam ligar com facilidade e a que o desempenho não dependa da fiabilidade dessas peças.

Tal como num motor de combustão, tens de pensar no encaixe e na fiabilidade quando integras o teu software com sistemas externos. Não podes assumir que o software externo:

• encaixa na perfeição
• é sempre consistente
• está sempre disponível / presente
• é de confiança

Para desenhar tendo em conta esta visão bastante sombria das ligações externas, achei boa ideia deixar o servidor principal (backend) da minha app de pedidos delegar a responsabilidade de ligar a sistemas externos num "servidor conector" feito de propósito. O servidor conector liga-se então, de forma independente, ao sistema externo. Assim, o servidor principal só comunica com peças e sistemas "de primeira mão", o que minimiza os riscos de encaixes falhados e de possíveis períodos de inatividade.

Na prática, isto significa que o "servidor conector" é, na verdade, uma máquina diferente, com a sua própria pilha de software. Esta segmentação tem algumas vantagens importantes:

• segurança: o servidor conector não guarda um registo completo de todos os pedidos, apenas os pedidos que têm de ser encaminhados para um sistema externo ficam temporariamente em memória. Um possível problema de segurança num sistema externo só expõe uma quantidade mínima de dados.
• encaixa em tudo: o servidor conector pode acomodar muitos protocolos e formas diferentes de ligar a sistemas externos. Adicionar ligações a sistemas externos é um pouco como o servidor "aprender uma nova língua". Como já é um "poliglota", acrescentar um novo dialeto ou língua costuma ser fácil. Ligar a diferentes APIs é mais simples quando tens todos os blocos de construção prontos para (re)estruturar dados.
• acomodar a falta de fiabilidade: um mecanismo simples de filas no servidor conector permite-lhe lidar com elegância com possíveis períodos de inatividade e problemas nas ligações externas. Ao registar e pôr em fila por serviço externo, é possível minimizar o impacto nas outras peças e ligações quando um serviço falha.

Conclusão

Por mais tentador que seja acrescentar à tua app peças novas e vistosas, tens de pensar com cuidado na tua configuração para garantir que funciona de forma fiável.

Desenhar software de servidor backend para ligar a APIs externas é um desafio. Tens de esperar o melhor, mas desenhar para o pior!