We have said in Chapter 4, Designing Runnerly, that a safe approach to designing microservices is to avoid creating new ones without a good reason.
The database that holds user data is served by the DataService microservice, which is used by the Celery workers. The first option that comes to mind is to have a single Flask application, which manages that database, and serves both our end users with its HTML and JS content and other microservices with its JSON APIs.
The benefit of this approach is that we do not need to worry about implementing yet another network interaction between the dashboard and DataService. Moreover, besides the ReactJS app, there's not a lot we need to add on top of DataService to make it usable for both use cases.
However, by doing this, we are not benefiting from one of the advantages of microservices. Each microservice focuses on doing a single thing.
While it is always safer to start with a conservative approach, let's think for a minute how a split would impact our design. If the dashboard is on its own, it needs to drive DataService to create and change users' info in DataService. This means that DataService needs to expose some HTTP APIs to do this. The biggest risk of exposing a database via HTTP is that whenever it changes, the API might get impacted.
However, that risk can be limited if the exposed endpoints hide the database structure as much as possible, the opposite of CRUD-like APIs.
For example, the API to create a user in DataService could be a POST that just asks for the user's Strava token and e-mail, and returns some user ID. This information should rarely change, and the dashboard can simply act as a proxy between the users and DataService.
A significant benefit of having the Dashboard app isolated from the DataService is stability. When building an application like Runnerly, developers often reach a point where the core of the application is stable, and then they iterate a lot on the User Interface (UI) and User Experience (UX). In other words, the dashboard is probably going to evolve a lot while the DataService app should reach a stable point quite fast.
For all those reasons, having two separate apps for the dashboard and DataService sounds like a low risk.
Now that the design decision is made, let's look at how to perform the OAuth2 dance with Strava.