Nodejs OpenShift Do

improve this page | report issue

Mobile Foundation Nodejs odo component

OpenShift Do (odo) is the CLI tool for developers built by Red Hat for rapidly building and deploying micoservices. You can read more about odo here.

The Mobile Foundation Node.js odo component provides a Node.js environment for developers to build backend or backend-for-frontend microservices for mobile apps. This component provides microservice developers with easy to use APIs to consume Mobile Foundation services such as Push Notifications, Mobile Foundation Analytics and Live Update. As an example, a push notification can be trigerred from the Nodejs backend based on the customer’s purchase value for an order placed from the mobile client.

Prerequisites to use the odo component

Creating an odo project with the Mobile Foundation Nodejs odo docker image

  1. Import the docker image for the component using the following command.

     oc import-image mobile --from=docker.io/ibmcom/nodejs-mobile-foundation:odo-latest --confirm
    

    You can choose a name of your choice instead of “mobile” here.

  2. Create a new folder in your file system and initialize it using the odo CLI. For example,

     mkdir mf-mobile-backend
     cd mf-mobile-backend
     odo create mobile --git https://github.com/{userName}/{repositoryName}
    

    This initializes a Node.js Mobile Foundation project with odo config file. Here the GitHub URL should contain your node app that uses Mobile Foundation services. Such a sample can be found here.

  3. After your project has been initialized, navigate into the created project folder and add the required environment variables at the end of the .odo/config.yaml file as shown below.

     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>"}}'
    

    Each of the parameter in the environment variable is explained below.

    • MFSERVER

      The fully qualified Mobile Foundation service endpoint. For example, https://mf-xxxxx-mfpserver.mf.cluster.svc.local:9080 (Note the complete server address including the port is necesssary). If your Mobile Foundation service is running in an external cluster, provide the fully qualified ingress route.

    • APPID

      For Android applications, it is the package name of the app and for iOS applications, it is the bundle ID. For example, com.acme.myapp.

    • UNAME

      The confidential client username. For example, bffclient.

    • PASSWORD

      The confidential client’ password. For example, bffclientpassword.

    • APPNAME

      The application’s display name. For example, Acme’s Awesome App.

    Alternatively, you can provide individual environment variables when all your services are pointing to a single Mobile Foundation server and a single application, like the following.

     -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>"
    

    In the above case, the environment variable must be the ingress route of your pod. If you instead wish to use the internal URLs, then additional environment variables are needed that specify each service’s (push, liveupdate and analytics) internal Mobile Foundation URL along with the above mf_url having the Mobile Foundation server’s runtime URL.

     -Name:mf_push_url
     Value:<MFPUSHSERVER>
     -Name:mf_liveupdate_url
     Value:<MFLIVEUPDATESERVER>
     -Name:mf_analytics_rl
     Value:<MFANALYTICSSERVER>
    

    Note: If using the internal Mobile Foundation service URLs then you have to specify individual variables only. You cannot use the single environment variable MF_ENVVARS format of passing environment variables.

  4. Use this command to create a public route for the app has been initialized

     odo url create --port 8080
    
  5. Now the app can be deployed using the following command

    odo push
    

    This deploys the app and can now be accessed using the route created above.

    Note: The route for the app can be viewed using odo url list command.

The docker image to be used for this odo component directly provides the below APIs.

Push APIs provided

  • sendNotification
  • sendNotificationByTags
  • sendNotificationByPlatform
  • sendNotificationByDeviceId
  • sendNotificationByUserId

Live update APIs provided

  • isFeatureEnabled
  • toggleFeature
  • enableFeature
  • disableFeature
  • getProperty
  • setProperty

Analytics APIs provided

  • sendCustomLogs
  • sendNetworkTransactions

Additionally user context (user specific data like username, device details etc) is made available to the end developer with the help of the passport strategy. To know more about passport strategy, see here.

This can be used by adding a filter mf.securityUtils.mfpAuth(scope) in the created endpoint. Here the parameter scope determines the user context data that is fetched. An example of this is provided in the sample app.

The input for the passport filter is made available through the environment variables using the key passport_filter while specifying the environment variables.

Note: For information on the available APIs, see here.

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.
Last modified on July 02, 2020