Saltar al contenido principal

Tutorial completo de aplicaciones web


Este es un tutorial general rápido para ayudarlo a comprender cómo debe diseñar una aplicación que tenga múltiples componentes.

¡Digamos que queremos crear una versión de aplicación web de HOTDOG o NOT HOTDOG!

Descripción de la aplicación

Supongamos que queremos crear una aplicación web que muestre una lista de fotos con una línea que describa si la imagen es un hot dog o no, algo como esto:

  • <IMAGE> Etiquetas: Hotdog, Fecha de subida: 2017-11-12
  • <ANOTHER IMAGE> Etiquetas: NO Hotdog, Fecha de carga: 2017-07-08
  • <ANOTHER IMAGE> Etiquetas: Hotdog, Fecha de subida: 2017-07-07
  • ....

Cualquiera puede cargar imágenes y nuestra muy inteligente Inteligencia Artificial etiqueta esa imagen con HOTDOG o NOT-HOTDOG, luego guardamos esa imagen en el servidor y también guardamos la fecha de carga y las etiquetas en la base de datos.

Arquitectura de la aplicación

Para crear esta aplicación, supongamos que decidimos tener los siguientes componentes:

  • NodeJS WebApp: (incluidos activos estáticos, aplicación frontend y API)
  • PHP Aplicación de carga de imágenes: donde podemos realizar una solicitud POST para guardar una foto en el disco
  • MongoDB donde podemos almacenar información de carga (etiquetas, fecha de carga, etc.)
  • PYTHON Un servicio de Reconocimiento de Imágenes donde podemos realizar una solicitud POST para saber si la imagen es un HOTDOG o NO HOTDOG
+---------------------+
| |
| NodeJS Webapp |
| |
+---------------+------------+--------+-----------------+
| | |
| | |
| | |
| | |
| | |
+-------v-----------+ +----------v----------+ +-----------v---+
| | | | | |
| PHP File Uploader | | Python ImageDetector| | MongoDB |
| | | | | |
+-------------------+ +---------------------+ +---------------+

Persistencia o no

CapRover te permite indicar si tu aplicación/database/service tiene datos de persistencia o no. Las aplicaciones persistentes pueden tener "directorios persistentes". Estos directorios se conservarán si su aplicación falla y Captain inicia una nueva instancia de esa aplicación. Todos los demás directorios se borrarán y restablecerán a su estado predeterminado si la aplicación falla y Captain inicia una nueva instancia de la aplicación. En nuestro ejemplo:

  • WebApp: NO tiene/necesita persistencia.
  • Aplicación de carga de imágenes: necesita un directorio persistente donde las imágenes se guardan en el disco (por ejemplo, /uploaded_files)
  • MongoDB. Por supuesto, esto necesita persistencia (donde almacenamos información), no queremos perder la base de datos, solo porque nuestro MongoDB falló o nuestro servidor se reinició.
  • Aplicación de reconocimiento de imágenes PYTHON. Este no necesita guardar ningún dato en el disco. Simplemente recibe una imagen, la procesa y le informa al cliente si la imagen era HOTDOG o NO HOTDOG.

Creando servicios:

  • NodeJS Aplicación web: después de escribir esta aplicación, simplemente crea una aplicación web y le asigna el nombre my-webapp en Captain, NO marca la casilla de persistencia e implementa su aplicación.
  • Aplicación de carga de imágenes: similar a la aplicación web descrita anteriormente, pero marcaremos la casilla de persistencia al crear la aplicación. Nombra esta aplicación image-uploader. Después de eso, vamos a la página de detalles de la aplicación y agregamos un directorio persistente, la ruta del directorio es donde su aplicación almacena las imágenes. Esto depende de su aplicación; en nuestro ejemplo, supongamos que es /uploaded_files
  • MongoDB: usaremos el instalador de aplicaciones de un solo clic para crear una instancia de MongoDB. Llamaremos a este contenedor my-mongodb. Cuando se crea el contenedor (base de datos), puede ir a la página de detalles y verá que Captain asignó automáticamente algunos directorios persistentes a este contenedor. Aquí es donde MongoDB guarda sus datos.
  • Python Aplicación de reconocimiento de imágenes: nuevamente, cree una nueva aplicación en Captain. No necesitamos configurar la persistencia para esta aplicación ya que no guarda ninguna información en el disco. Llamemos a esta aplicación image-processor.

Acceso interno

Su aplicación web necesita comunicarse con las aplicaciones de MongoDB, carga y procesamiento de imágenes. Las aplicaciones del mismo clúster de CapRover pueden usar el nombre de la aplicación de destino como nombre de host. Por ejemplo, conéctese desde Node.js a la aplicación my-mongodb mediante:

mongoose.connect("mongodb://my-mongodb/mydatabase");

Por supuesto, puede agregar nombre de usuario y contraseña al URI, consulte aquí por ejemplo.

La misma regla se aplica a otros servicios. Por ejemplo, puede acceder a la aplicación de carga de imágenes mediante http://imageuploader. Las aplicaciones actualizadas desde versiones de CapRover anteriores a 1.15 también pueden usar el alias de red heredado srv-captain--APP_NAME.