Conectando Lemmid Store con cocinas

Resumen

Para la app de pedidos de comida que estoy desarrollando, necesitaba diseñar una forma fiable de conectarla con sistemas externos. Esos sistemas escapan a mi control directo e incluyen distintas cajas registradoras, sistemas de gestión de cocina e impresoras de tickets. Sigue leyendo para saber más sobre cómo diseñar para lo desconocido y poco fiable.

Texto completo

App para pedir comida

La app que estoy desarrollando es Lemmid Store, una app fácil de usar con la que la gente puede hacer (y pagar) pedidos de comida para llevar. Aquí tienes todos los artículos sobre Lemmid Store.

Sistemas externos

La necesidad de conectar con sistemas externos viene del deseo de integrar la app de pedidos en los procesos de negocio del servicio de reparto de comida. Piensa en cosas como:

• volcar los datos de los pedidos en registros administrativos (por ejemplo, la contabilidad)
• enviar los pedidos a las cocinas, donde se preparan y se empaquetan las comidas
• dar acceso fácil a la información de ruta, que muestra adónde hay que llevar la comida
• programar los pedidos que son para entregar más tarde

Los retos de conectar con sistemas externos

Quizá no te lo imagines, pero conectar con sistemas externos puede ser complicado. Si piensas en la app de pedidos como una especie de "motor" (como el de tu coche), lo que quieres es acoplar ese motor a piezas externas. Como puedes imaginar, no todas las piezas caben igual de bien bajo el capó, por así decirlo. Y para complicarlo aún más: no sabes con certeza lo fiables que son esas piezas externas. Tienes que diseñar la integración de modo que sea fácil conectar piezas externas distintas y que el rendimiento no dependa de lo fiables que sean.

Igual que con un motor de combustión, al integrar tu software con sistemas externos hay que tener en cuenta la compatibilidad y la fiabilidad. No puedes dar por hecho que el software externo:

• encaja a la perfección
• es siempre coherente
• está siempre disponible
• es de fiar

Para diseñar con esta visión bastante sombría de las conexiones externas, me pareció buena idea que el servidor backend principal de mi app de pedidos delegara la responsabilidad de conectar con sistemas externos en un 'servidor conector' hecho a propósito. El servidor conector se conecta entonces por su cuenta al sistema externo. Así, el servidor principal solo se comunica con piezas y sistemas 'propios', y se reducen los riesgos de incompatibilidad y de posibles caídas.

En la práctica, esto significa que el 'servidor conector' es en realidad otra máquina, con su propio conjunto de software. Esta separación tiene varias ventajas importantes:

• seguridad: el servidor conector no guarda un registro completo de todos los pedidos; solo mantiene temporalmente en memoria los que hay que reenviar a un sistema externo. Un posible problema de seguridad en un sistema externo solo dejará expuesta una cantidad mínima de datos.
• se adapta a todo: el servidor conector admite muchos protocolos y formas de conectar con sistemas externos. Añadir una conexión es como si el servidor 'aprendiera un idioma nuevo'. Como ya es 'políglota', sumar un dialecto o un idioma suele ser fácil. Conectar con distintas API externas resulta más sencillo cuando ya tienes todas las piezas para (re)estructurar los datos.
• absorbe la falta de fiabilidad: un sencillo mecanismo de colas en el servidor conector le permite gestionar con elegancia las posibles caídas y los problemas de las conexiones externas. Al registrar y poner en cola por servicio externo, se puede reducir al mínimo el impacto en el resto de piezas y conexiones cuando un servicio se cae.

Conclusión

Por tentador que sea añadir sin más piezas nuevas y vistosas a tu app, tienes que pensar bien la arquitectura para asegurarte de que funcione de forma fiable.

Diseñar software de servidor backend que se conecte con API externas es un reto. ¡Hay que esperar lo mejor, pero diseñar para lo peor!