Nodejs OpenShift Do
improve this page | report issueComponente Nodejs odo de Mobile Foundation
OpenShift Do (odo) es la herramienta de la CLI para desarrolladores, basada en Red Hat, que permite crear y desplegar microservicios rápidamente. Puede obtener más información sobre odo aquí.
El componente Node.js odo de Mobile Foundation proporciona un entorno de Node.js para que los desarrolladores creen microservicios de fondo o Backend for Frontend para aplicaciones móviles. Este componente proporciona a los desarrolladores de microservicios las API fáciles de utilizar que permiten consumir servicios de Mobile Foundation, tales como Notificaciones push, Mobile Foundation Analytics y Live Update. Por ejemplo, se puede desencadenar una notificación push desde el servicio de fondo Nodejs basada en el valor de la compra del cliente para un pedido realizado desde el cliente móvil.
Requisitos previos para utilizar el componente odo
- Descargar e instalar la CLI oc.
- Instalar la CLI odo.
- Instalar Docker.
Crear un proyecto odo con la imagen de docker de Nodejs odo de Mobile Foundation
-
Importe la imagen de docker para el componente utilizando el mandato siguiente.
oc import-image mobile --from=docker.io/ibmcom/nodejs-mobile-foundation:odo-latest --confirm
Aquí puede utilizar un nombre de su elección, en lugar de “mobile”.
-
Cree una nueva carpeta en su sistema de archivos e iníciela utilizando la CLI odo. Por ejemplo,
mkdir mf-mobile-backend cd mf-mobile-backend odo create mobile --git https://github.com/{userName}/{repositoryName}
Esto inicializa un proyecto Node.js de Mobile Foundation con el archivo de configuración odo. Aquí el URL de GitHub debe contener la aplicación de nodo que utiliza los servicios de Mobile Foundation. Puede encontrar un ejemplo de este tipo aquí.
-
Una vez iniciado su proyecto, vaya a la carpeta del proyecto que ha creado y añada las variables de entorno necesarias al final del archivo
.odo/config.yaml
como se muestra abajo.Envs: - Name: MF_ENVVARS Value: '{"push":{"mf_url":"<MFSERVER>","mf_app_id":"<APPID>","username":"<UNAME>","password":"<PWD>"},"liveupdate":{"mf_url":"<MFSERVER>","mf_app_id":"<APPID>","username":"<UNAME>","password":"<PWD>"},"analytics":{"mf_url":"<MFSERVER>","mf_app_name":"<APPNAME>","username":"<UNAME>","password":"<PWD>"},"passport_filter":{"mf_url":"<MFSERVER>","username":"<UNAME>","password":"<PWD>"}}'
A continuación, se describe cada uno de los parámetros de la variable de entorno.
-
MFSERVER
El punto final de servicio completo de Mobile Foundation. Por ejemplo, https://mf-xxxxx-mfpserver.mf.cluster.svc.local:9080 (Tome nota de la dirección del servidor completa, incluido el puerto si es necesario). Si su servicio de Mobile Foundation se ejecuta en un clúster externo, proporcione la ruta de ingress completa.
-
APPID
Para aplicaciones Android, es el nombre de paquete de la aplicación y para iOS, es el ID de paquete. Por ejemplo, com.acme.myapp.
-
UNAME
El nombre de usuario confidencial del cliente. Por ejemplo, bffclient.
-
PASSWORD
La contraseña confidencial del cliente. Por ejemplo, bffclientpassword.
-
APPNAME
El nombre de visualización de la aplicación. Por ejemplo, Acme’s Awesome App.
De forma alternativa, puede proporcionar variables de entorno individuales cuando todos los servicios apunten a ún único servidor de Mobile Foundation y una única aplicación, como se muestra a continuación.
-Name:mf_url Value:<MFSERVER> -Name:mf_app_id Value:<APPID> -Name:push_mf_username Value:<PUSH_UNAME> -Name:push_mf_password Value:<PUSH_PWD> -Name:liveupdate_mf_username Value:<LIVEUPDATE_UNAME> -Name:liveupdate_mf_password Value:<LIVEUPDATE_PWD> -Name:analytics_mf_username Value:<ANALYICS_UNAME> -Name:analytics_mf_password Value:<ANALYTICS_PWD> -Name:pf_mf_username Value:<PASSPORT_FILTER_UNAME> -Name:pf_mf_password Value:<PASSPORT_FILTER_PWD>"
En el caso anterior, la variable de entorno debe ser la ruta de ingress de su pod. Si en su lugar, desea utilizar los URL internos, se requieren variables de entorno adicionales que especifiquen el URL de Mobile Foundation interno de cada servicio (push, liveupdate y Analytics) junto con el mf_url que contiene el URL de tiempo de ejecución del servidor de Mobile Foundation.
-Name:mf_push_url Value:<MFPUSHSERVER> -Name:mf_liveupdate_url Value:<MFLIVEUPDATESERVER> -Name:mf_analytics_rl Value:<MFANALYTICSSERVER>
Nota: Si utiliza los URL internos del servicio Mobile Foundation, solo debe especificar variables individuales. No puede utilizar el formato
MF_ENVVARS
de variable de entorno única para pasar variables de entorno. -
-
Utilice este mandato para crear una ruta pública para la aplicación que se ha inicializado.
odo url create --port 8080
-
Ahora se puede desplegar la aplicación utilizando el mandato siguiente
odo push
Esto despliega la aplicación, a la que ahora se puede acceder utilizando la ruta creada anteriormente.
Nota: La ruta de la aplicación se puede ver utilizando el mandato
odo url list
.
La imagen de docker que se ha de utilizar para este componente odo proporciona directamente las siguientes API.
API push proporcionadas
- sendNotification
- sendNotificationByTags
- sendNotificationByPlatform
- sendNotificationByDeviceId
- sendNotificationByUserId
API Live Update proporcionadas
- isFeatureEnabled
- toggleFeature
- enableFeature
- disableFeature
- getProperty
- setProperty
API de análisis proporcionadas
- sendCustomLogs
- sendNetworkTransactions
Además el contexto de usuario (datos específicos del usuario como, el nombre de usuario, detalles del dispositivo, etc.) está disponible para el desarrollador final, con la ayuda de la estrategia passport. Para obtener más información acerca de la estrategia passport, consulte aquí.
Esto se puede utilizar añadiendo un filtro mf.securityUtils.mfpAuth(scope) al punto final creado. Aquí el ámbito del parámetro determina los datos del contexto de usuario que se capturan. En la aplicación de ejemplo se proporciona un ejemplo.
La entrada del filtro passport está disponible mediante las variables de entorno, utilizando la clave passport_filter cuando se especifican las variables de entorno.
▲Nota: Para obtener información sobre las API disponibles, consulte aquí.
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.