Cómo utilizar más de un idioma en mi back-end para diferentes propósitos

A2A

Debe tener una muy buena razón para usar diferentes idiomas que se ejecutan en el mismo sistema, ya que generalmente la sobrecarga de hacer que los diferentes procesos se comuniquen entre sí es grande.

La elección de un idioma (o varios idiomas) suele ser uno de los dilemas más difíciles para los desarrolladores. Podrías escribir libros sobre este tema solo.

Sugeriría comenzar con un lenguaje de fondo que conozca mejor. Luego agregue C o C ++ solo si:

(a) absolutamente necesita rendimiento y sabe que escribir y mantener algunas partes del sistema en C o C ++ le costará menos que recursos de alojamiento adicionales.

(b) sabes cómo interactúa tu lenguaje principal con C o C ++ (en realidad es más a menudo C que C ++).

La interacción entre lenguajes de alto nivel, como Python y JavaScript, es mucho más costosa en términos de rendimiento, ya que es probable que utilice algún IPC de gran peso estándar, como memoria compartida o canalizaciones.

Todavía es posible usar diferentes lenguajes de alto nivel en el mismo sistema si su interacción es mínima. Por ejemplo, tiene Python o Node.js que atienden solicitudes HTTP, luego Java realiza algunos cálculos en segundo plano en la base de datos. En este caso, se podría decir que los procesos interactúan a través de la base de datos, lo que no es tan malo. Pero, de nuevo, no veo por qué no usarías un idioma para ambas tareas.

Espero que esto aclare algo.

Gracias por la A2A

Usaría una interfaz REST http en cada servidor.

Hay muchas razones por las que puede desear varios idiomas para el back-end, pero uno principal: los diferentes idiomas hacen cosas diferentes (velocidad, facilidad, interfaz, …)
Es mejor hacerlo explícito desde el principio y simplemente llamarlos servidores diferentes.
Azzie y Jeff Bezos tienen razón: no hagas ni dejes que los servidores se comuniquen entre sí más de lo que cualquier otro servidor autorizado puede hacerlo.

Una razón es que si el nodo c ++ es para el rendimiento, algún día terminará en una máquina de aspecto muy diferente al nodo php, cualquier cosa menos el acoplamiento flojo de los dos procesos es como reservar dos semanas de programación para usted o un miembro del equipo en algún momento en el futuro.

Hay muchos, pero otra razón fundamental es que un backend de rails es fácil como hacer cosas complejas, como lo es un backend php o un backend node.js.
Al usar estos sistemas, un servidor se apoya en los hombros de los gigantes.
Con demasiada complejidad, un servidor corre el riesgo de pararse en un puente giratorio atado a los collares de las camisetas de la versión 1.9.2 de los gigantes

Los sistemas actuales se basan en SOA (Service Oriented Architecture).
Por ejemplo, una aplicación como quora necesita tener una base de datos en algún lugar o un almacén de datos persistente (término generalizado).
Ahora, para exponer los datos debe tener el servicio electrónico, el servicio web REST más preferido.
Y en la parte de presentación, podría ser web, móvil, escritorio, consola, televisión, etc.
Ahora, vamos en representación física de la “arquitectura”.
El almacén de datos puede ser relacional / sql, oracle, mssql, mysql, cualquier otra cosa, o no-sql, mongo, docoumentdb, cualquier otra cosa.
Api podría desarrollarse con node.js, php, aspdotnet, cualquier otra cosa.
Aplicación de iOS con ObjectiveC, Swift, Html, cualquier otra cosa, el mismo Android con Java como diferencia, Windows Phone con C # como diferencia.
Web usando PHP, ASPdotNet, Ruby, Python, cualquier otra cosa.

Jeff Bezos resolvió este problema técnico por ti

• Todos los equipos en adelante expondrán sus datos y funcionalidad a través de interfaces de servicio.
• Los equipos deben comunicarse entre sí a través de estas interfaces.
• No habrá ninguna otra forma de comunicación entre procesos permitida: sin enlaces directos, sin lecturas directas del almacén de datos de otro equipo, sin modelo de memoria compartida, sin puertas traseras. La única comunicación permitida es a través de llamadas de interfaz de servicio a través de la red.
• No importa qué tecnología utilicen.
• Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para ser externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores del mundo exterior. Sin excepciones.