Spring o Node no son arquitecturas. Simplemente son bloques de construcción para uno.
Sin embargo, su razonamiento parece correcto, Spring puede entregar API REST seguras si se aplica correctamente. La ventaja de Node es una alta E / S completa con requisitos mínimos de recursos debido a su naturaleza asincrónica. Sin embargo, otras tecnologías pueden hacer lo mismo o cosas similares.
Para evaluar su arquitectura, nosotros (o usted) primero tendremos que tener una idea clara de qué tipo de problema está tratando de resolver. Tiene algunas pistas, pero se omiten partes importantes:
- Alguien me dijo que puedo usar C ++ para construir el backend, ¿cómo puede ser esto posible?
- ¿Cuáles son las mejores soluciones alojadas para el desarrollo front-end en la actualidad? Me gustaría aprender algo como Angular, pero quiero una plataforma alojada que gestione la base de datos y el código de fondo. Sé JavaScript muy bien.
- ¿Cuál es la arquitectura de back-end de FoodPanda?
- ¿Dónde puedo aprender desarrollo web front-end y back end para hacer un sitio web?
- Para el desarrollo web de back-end, ¿es mejor aprender PHP o Python?
- ¿Cuáles son los requisitos funcionales?
- ¿Cómo se ve el contexto del sistema?
- ¿Cuáles son los requisitos no funcionales (velocidad frente a corrección, tiempo de comercialización frente a robustez, alta disponibilidad frente a elasticidad y todas las demás compensaciones que debe realizar. No puede tenerlas todas …)
- Cual es tu horizonte de tiempo
- ¿Cuál es la capacidad de su equipo?
- Cual es tu presupuesto
- …
Una arquitectura solo puede ser sólida si todos los aspectos se consideraron con mucho cuidado. Podría ser un resultado que inicialmente pensó que Spring era una elección perfecta, pero en el curso de su evaluación, podría formular una decisión de Arquitectura de que un backend Java EE encajaría mucho mejor en su entorno (o viceversa). O puede descubrir que su equipo solo puede hacer Node.js muy bien, entonces es posible que desee deshacerse de Java por completo. Otro resultado podría ser que tiene una necesidad elevada de código robusto y seguro, entonces Node.js podría no ser la mejor opción.
Lo mismo se aplica para la comunicación síncrona vs asíncrona, o servicios distribuidos vs servicios monolíticos. Solo porque las tecnologías son populares hoy en día no significa que sean la mejor opción para su solución.
Espero que esto ayude 🙂
