Mobile API

Currently, there are some Mobile configuration settings that are handled by ebury-api-webapp repository, for example the MobileApiStatus model and DynamoDB table. However, it would be cleaner to have all Mobile configurations, existing and created in the future, in a different repository.

Problem description

The latest MobileApiStatus changes, that affected the API-Webapp both in code reviews and service deployments, showed an existing problem here. ebury-api-webapp is not supposed to handle Mobile configurations. The idea behind Webapp is to be a layer between Ebury Backend and the public API, and it was not supposed to contain logic. We added MobileStatus to Webapp because we required something to be able to modify the mobile minimum version until we had the proper place for it.

The new Mobile API service will not only handle MobileStatus. It will be the place for all Mobile-required functionality. Dividing into too many services can add a lot of complexity if done wrong, but the idea for the Mobile API is to be one microservice to handle all Mobile functionality to be exposed. If we mix it with Webapp, we would be mixing unrelated topics for the sake of reducing services, as the Mobile API is not a customer-related API.

Also, many of the endpoints from MobileAPI will be used only for internal/administration purposes (i.e. the MobileStatus endpoints themselves, that are only used by the Management Panel), which also goes against the Webapp focus and breaks modularity.

Background

MobileApiStatus lets us configure the minimum and latest versions for the Mobile application, so that the user is prompted with a new update if the latest version is a different one from the one installed, and is forced to update if the min version is greater than the one installed.

This is currently the only mobile-related configuration that we need, but once the number of Mobile services starts growing, it is possible that we start needing more parameters to configure.

Solution

We need a new service to handle all these configurations without impacting the API team. The service structure will be similar to the already existing webapp repository, with a Python API that will use Pynamo to connect to the DynamoDB tables where the configuration is stored. The endpoints will allow for the configuration to be accessed (publicly) and edited (privately, through Ops Portal), so we can efficiently modify the minimum version for the Mobile App, amongst other things.

To do that we would need:

  1. Configure the new MobileApiStatus table so it doesn't fall under the API team (it is currently in the ebury-api domain).
  2. Generate a new Kubernetes repository ebury-mobile-api.
  3. Configure the MobileApiStatus model and endpoints.
  4. Get the service running and working properly.
  5. Remove all currently existing Mobile configurations inside API Team sided projects.

The ebury-mobile-api service will use Fast API to handle the different endpoints, and pynamo to handle the database operations, similarly to how we already do it in webapp.

For now, the service will only have two endpoints:

  • GET /health-status, which returns the current information about the Mobile application versions and configuration stored in Dynamo:
app_name='default',
app_min_version='0.3.14',
app_last_version='0.0.9',
maintenance_mode=False,
retry_in_sec=300,
  • PUT /health-status/app-name, which allows us to modify the Dynamo stored configuration of the mentioned app_name.

These endpoints will then be used in the Operations Portal. However, we are already configuring them now that they are in ebury-api-webapp, so the only real impact this will have is to change URLs and authentication processes to match the new service.

The GET endpoint is also used by the Mobile Application to check if a new version update is required in the user's mobile device.

Once these endpoints are implemented, which will be the first endpoints contained in MobileAPI, they can be removed from Ebury-Webapp so the modularity it had before is recovered.

Service Ownership

New Service Service Name Service Owner
Yes Mobile API MOB Team

Caveats

In order to avoid client-side errors, we need to do this process so that the new ebury-mobile-api project is completely finished before removing anything from the API configuration (Dynamo table, ebury-api-webapp endpoints...). Otherwise the application would run into problems. Same goes with the data currently stored in the Staging and Production environments databases: we need to pass the information to the new table before deleting the previous one.

Operation

Mobile-API will be deployed in 'Ebury Core' Kubernetes cluster.

Access will be achieved through the app-proxy. No authentication will be required for the GET endpoint, but the PUT will require Keycloak authentication.

Security Impact

The app version configuration will trigger a new download depending on the value of the installed version and the one returned by GET /health-status. This requires that the configuration stored in the dynamo table through PUT /health-status/app-name is not messed with. We need to make sure that access for write operations is only achieved through a specific group of people through the Management Panel Keycloak configuration.

Performance Impact

Creating a different service from ebury-api-webapp will require more resources than it does currently.

However, this also means that Mobile operations are now issolated from ebury-api-webapp, so that service will only answer API-related requests. Apart from being cleaner, this means fewer points of failure for the API service, fewer requests, and fewer required deployments.

Developer Impact

We need to replicate all MobileApiStatus operations in the new service and remove them from the previous one, making it seamless to the users.

Data Contracts

The new service, ebury-mobile-api, will have access to the new Dynamo table ebury-mobile-<env>-mobile-api-status, which will be a clone of the current ebury-api-env-mobile-api-status. Then we will remove the API table and its endpoints from ebury-api-webapp.

Deployment

Deployment of this application will be required in Kubernetes Staging and Production through the usual Python service pipelines, but also in the EBOX/Mobile environment, as the application testing is currently done in that environment. For that environment, the table is mocked locally, so we don't require a Dynamo table in that case.

Dependencies

No dependencies. The idea of the service is, in fact, to avoid them.