Ya he tenido que considerar esto para un proyecto de inicio propio. Cualquier red social tiene las mismas restricciones construidas sobre ella. Debe poder manejar una gran cantidad de solicitudes sin romper el banco en la CPU y la memoria. Debe ser reactivo y permitir actualizaciones en múltiples flujos de datos sin una forma perfecta para el usuario. Debería permitir una aplicación móvil y notificaciones push para actualizaciones consideradas cruciales para el usuario. También debe ser capaz de comenzar de a poco y poder escalar a voluntad. Elegimos las colas Node.js, Socket.io, Backbone.js, MongoDB y Redis. Las tecnologías en sí mismas no son necesariamente tan importantes como el papel que desempeñaron. Los discutiré un poco más abajo.
Node.js : Elegimos Node.js debido a su escalabilidad debido a E / S asíncrona, efectividad en el procesamiento de solicitudes de WebSockets y naturaleza controlada por eventos. En una aplicación reactiva, el uso de WebSockets reduce la sobrecarga asociada a enviar datos basados en eventos a los clientes. El bucle de eventos asíncrono basado en E / S de Node.js le permite maximizar la utilización de los recursos del procesador y la memoria sin agregar una tonelada de complejidad a la aplicación. La naturaleza impulsada por eventos de Node.js le permite reaccionar a los eventos de datos del usuario, que es la base de una aplicación reactiva. He descubierto muchos otros marcos asincrónicos basados en bucles de eventos de E / S como Twisted in Python (lenguaje de programación), Play Framework en Scala (lenguaje de programación), eventmachine en Ruby (lenguaje de programación), Icicle.io en PHP (lenguaje de programación) y Probablemente hay más que me he perdido. Lo importante no es el lenguaje, sino la funcionalidad.
Socket.io : Elegimos Socket.IO debido a su fácil integración con Node.js, así como a su capacidad de abandonar WebSockets a métodos heredados como sondeos largos e IFrames cuando sea necesario. Esto abstrajo el transporte entre el cliente y el servidor con una biblioteca probada.
- ¿Por qué mi jefe no me deja reescribir todos nuestros backends actuales en Node.js?
- Como novato total en el desarrollo web backend, ¿debería aprender PHP y MySQL o debería aprovechar mi conocimiento de Javascript y usar Javascript node.js en el backend para interactuar con la base de datos MySQL?
- ¿Cuáles son algunas de las habilidades de configuración y desarrollo de servidores que necesito aprender para convertirme en un desarrollador de back-end?
- Dado que la gente odia PHP para back-end, ¿qué es un mejor lenguaje de programación de back-end?
- ¿Cómo funcionan juntas las tecnologías front-end y back-end?
Backbone.js : Backbone.js fue nuestra elección, ya que permitía una aplicación de una sola página con componentes reutilizables simples. También usamos RequireJS para hacer que el código sea modular y más comprobable. Si volviera a hacer esto hoy, optaría por React (biblioteca de JavaScript) ya que implementa la estrategia que elegimos de forma estandarizada con un mejor rendimiento gracias al DOM de sombra.
MongoDB : MongoDB fue elegido por dos razones, era la única base de datos consultable que estaba bien respaldada por Node.js en ese momento y está construida en indexación espacial y geoespacial 2D que rápidamente nos permitió consultar y ordenar entidades en función de la ubicación. Otro factor clave para MongoDB es que puede comenzar con una base de datos simple y agregar rápidamente miembros del clúster y particiones más tarde según sea necesario. Muchas bases de datos hacen que ese proceso sea difícil, si no imposible, después del hecho.
Colas de Redis : las colas de Redis se utilizaron para permitir la activación de eventos de datos de usuario en los servidores y el procesamiento fuera de banda. Era importante encontrar un mecanismo para garantizar que el Usuario A en el Servidor 1 pudiera actualizar fácilmente el Usuario B en el Servidor 2. Las colas proporcionan esa funcionalidad y Redis proporciona una facilidad de administración y flexibilidad que era esencial. También utilizamos colas para el procesamiento fuera de línea. En lugar de conectar directamente servicios con API, los conectaríamos con colas. Esto proporcionó la encapsulación de nivel de servicio. Los servicios ni siquiera sabían de la existencia de otros servicios. Simplemente sabían que si producían un tipo de datos, deberían colocarlos en un lugar en la cola para esos datos. Si consumieran un tipo de datos, lo sacarían de una cola. Cualquier sistema de colas funcionaría y podría elegir RabbitMQ, pero eso dependería de la situación y el soporte de idiomas. Lo importante sobre el uso de colas es que introduce una cantidad mínima de complejidad por adelantado, pero proporciona una gran cantidad de flexibilidad y escalabilidad durante la vida del proyecto.
