Solución:
Cloud Functions (CF) y Google App Engine (GAE) son herramientas diferentes para diferentes trabajos. Utilizar la herramienta adecuada para el trabajo suele ser una buena idea.
Clavar un clavo con unos alicates podría sea posible, pero no será tan conveniente como usar un martillo. De manera similar, construyendo una aplicación compleja usando CF podría sería posible, pero construirlo usando GAE definitivamente sería más conveniente.
Los CF tienen varias desventajas en comparación con GAE (en el contexto de la construcción de aplicaciones más complejas, por supuesto):
- están limitados a Node.js, Python, Go, Java, .NET Core y Ruby. GAE admite varios otros lenguajes de programación populares
- están realmente diseñados para ser livianos, ser único piezas de funcionalidad, intentar construir aplicaciones complejas usando tales componentes se vuelve rápidamente “incómodo”. Sí, el contexto de interrelación para cada solicitud individual también debe restaurarse en GAE, solo GAE se beneficia de medios más convenientes para hacer lo que no está disponible en los CF. Por ejemplo, gestión de sesiones de usuario, como se discutió en otros comentarios.
- Las aplicaciones GAE tienen un contexto de aplicación que sobrevive a través de solicitudes individuales, los CF no lo tienen. Dicho contexto hace que el acceso a ciertos servicios de Google sea más eficiente / de rendimiento (o incluso posible) para las aplicaciones GAE, pero no para los CF. Por ejemplo memcached.
- la disponibilidad del contexto de la aplicación para las aplicaciones GAE puede admitir bibliotecas de cliente más eficientes / de rendimiento para otros servicios que no pueden operar en CFs. Por ejemplo, acceder al almacén de datos mediante el
ndbLa biblioteca de cliente (solo disponible para las aplicaciones de Python de GAE env estándar) puede ser más eficiente / de rendimiento que usar la biblioteca de cliente del almacén de datos genérico. - GAE puede ser más rentable ya que tiene un precio “mayorista” (basado en horas de instancia, independientemente de cuántas solicitudes atienda una instancia en particular) en comparación con el precio “minorista” de los CF (donde cada invocación se cobra por separado)
- tiempos de respuesta podría ser más corto para las aplicaciones GAE que para los CF, ya que normalmente la instancia de la aplicación que maneja la solicitud ya se está ejecutando, por lo tanto:
- el contexto de la aplicación GAE no necesita ser cargado / restaurado, ya está disponible, los CF necesitan cargarlo / restaurarlo
- el código de manejo ya está cargado (la mayoría de las veces), el código de los CF aún debe cargarse. No estoy seguro de este, aunque supongo que depende de la implementación subyacente.
App Engine se adapta mejor a las aplicaciones, que tienen numerosas funciones que se comportan de varias formas interrelacionadas (o incluso no relacionadas), mientras que las funciones en la nube son más específicamente funciones de un solo propósito que responden a algún evento y realizan alguna acción específica.
App Engine ofrece numerosas opciones de idioma y más opciones de administración, mientras que las funciones de la nube son limitadas en esas áreas.
Podrías replicar fácilmente Cloud Functions en App Engine, pero replicar una aplicación de App Engine a gran escala usando un montón de funciones Could discretas sería complicado. Por ejemplo, el backend de Spotify está basado en App Engine.
Otra forma de decirlo es que para una aplicación significativamente grande, comenzar con un sistema más complejo como App Engine puede llevar a una base de código que sea menos compleja, o al menos, más fácil de administrar o comprender.
En última instancia, ambos se ejecutan en una infraestructura subyacente similar en Google, y depende de usted decidir cuál funciona para la tarea en cuestión. Además, no hay nada que le impida mezclar elementos de ambos en un solo proyecto.