¿Qué debo considerar al diseñar una aplicación web?

A2A

Lo más importante es su comprensión de lo que está construyendo (propósito, forma, escala …). La arquitectura de un producto que cambiará mucho durante su desarrollo debe ser muy diferente de una arquitectura adaptada a especificaciones bien definidas. La segunda cosa más importante es el equipo que lo construirá. Trataré de ilustrar con dos ejemplos.

Caso 1 : usted es el cofundador técnico de una empresa joven. No conoce muy bien su mercado y, francamente, no está seguro de qué características quieren o no quieren sus clientes, pero debe comenzar a trabajar en un producto. Necesita algo que pueda mostrar a los primeros inversores y prospectos, y utilizar para validar las suposiciones sobre su negocio.

En esas circunstancias, lo que debe optimizar es la velocidad de iteración a corto plazo. Si desea cambiar algo o agregar una función, debería poder hacerlo rápidamente.

Debería buscar una solución en la que no tenga que preocuparse demasiado por el alojamiento o la administración, algo que simplemente pueda poner en Heroku o ese VPS suyo en unos minutos, y que le permita implementarlo fácilmente varias veces al día. Debería optar por una arquitectura monolítica (aunque todavía esté bien modularizada), y cualquier idioma que conozca mejor, siempre que sea adecuado para un desarrollo web rápido (tiene suficientes bibliotecas de código abierto, etc.). Puede elegir SQL si tiene una experiencia significativa con él o una base de datos NoSQL para la flexibilidad (PostgreSQL es un buen término medio).

Caso 2 : el producto del caso 1 ha sido exitoso, ahora tiene un millón de usuarios. El equipo técnico ha crecido hasta 40 personas. Tienes problemas:

  • Hay problemas de rendimiento y parece que su arquitectura se desmoronará en el siguiente orden de magnitud de crecimiento.
  • Se ha mudado de su PaaS por razones de costo. Ahora tiene varios servidores y un “equipo de operaciones”; se quejan de lo difícil que es su trabajo.
  • Todos sus desarrolladores trabajan en la misma base de código y les resulta problemático. Nadie es claramente responsable de nada. Hay partes de la base de código que nadie conoce.
  • Ese esquema de base de datos se está convirtiendo en un monstruo que ya nadie entiende completamente.

Decides conseguir una reescritura. Este es un caso en el que diría que SOA tiene mucho sentido: divida el monolito en bloques separados con interfaces bien definidas. Deben ser verificables de forma independiente, y usted debe organizar su equipo en equipos alrededor de esos servicios.

Los servicios pueden estar en diferentes lenguajes de programación si tienen diferentes requisitos. Puede haber varias bases de datos más simples en lugar de una grande. La velocidad de iteración sigue siendo un objetivo (casi siempre lo es) pero ya no es el único.

Debes apuntar a:

  • partes escalables independientemente;
  • operaciones y depuración más fáciles en la producción;
  • estabilidad, redundancia, copias de seguridad confiables …

Finalmente, me gustaría agregar tres cosas:

  • Como dijo Lon Hosford, siempre tenga en cuenta dicha seguridad (y auditabilidad cuando alcance una cierta escala).
  • No abogo necesariamente por pasar del paso 1 al paso 2 mediante una reescritura. Puede (y debe) intentar evolucionar gradualmente del caso 1 al caso 2. Pero a veces las personas no hacen eso, dejan que el sistema del caso 1 crezca demasiado hasta que sea demasiado tarde, y luego es mejor comenzar desde una hoja limpia.
  • Si aún no ha visto este video, debe verlo:

En un nivel amplio, repasaría estos puntos como viñetas:

  • El alojamiento es una gran cosa importante a considerar en primer lugar.
  • Escalabilidad
  • Actuación
  • Redundancia
  • Modularidad
  • Tolerancia a fallos con servicios
  • Bloqueo de punto final de API

En un nivel más práctico y de implementación:
Considere usar marcos que rimen con la naturaleza de su aplicación web.

Si está utilizando algunos servicios específicos en toda su aplicación, intente comprender las deficiencias de Web Frameworks:
En caso de que esté usando Ruby On Rail: Obtenga más información sobre Rails y sus deficiencias y qué tan rápido puede avanzar cuando está escalando y agregando características.

Si su aplicación web contiene contenido para compartir medios, es importante pensar en cómo distribuirá los medios.

La mayoría de las veces puedes elegir entre:
1- Self host mi servicio?
2- ¿Comprar los servicios como plataforma?
3- O no lo necesito ahora, usemos un servicio alternativo.

Cuando realiza ajustes y pruebas de rendimiento, su diccionario de todos los trucos es su registro.
Intenta tener todos los registros en alguna parte, sin importar qué.
El análisis de registros en diferentes niveles puede ser muy bueno para el comportamiento de su aplicación.

Es bueno considerar algunas pruebas A / B en el camino, porque si está haciendo algo nuevo significa que podría estar entrando en territorios no identificados, lo cual es peligroso.

Es bueno considerar buscar en los servicios de cola para procesos largos y que consuman mucha memoria, le ahorrará mucho dolor de cabeza.

Error y excepciones es una gran parte de la creación de un entorno limitado de guardado para sus usuarios cuando crea una aplicación web, asegúrese de controlar los problemas principales con excepciones antes de que las cosas se salgan de control.

Seguridad, Seguridad, Seguridad.

Seguro y simple