Suppose you have a web application where users need to log in to access personalized data stored in a MySQL database. The authentication process involves Firebase, and every time a user makes a request to fetch or modify data, it goes through the following steps:
The client sends an authentication request to the Firebase server to verify the user's identity and obtain the necessary tokens (access and refresh tokens).
Once authenticated, the client uses the Firebase access token to request data from the MySQL server.
The MySQL server receives the request, processes it, and sends the data back to the client.
In this example, the communication flow is as follows: Client -> Firebase Server -> MySQL Server -> Client.
The concern here is that the client has to make two separate network requests for each operation—one to Firebase for authentication and token retrieval and another to MySQL for the actual data. This adds an extra layer of latency and potential points of failure in the communication chain.
The potential impact on connection speed arises from the fact that each request involves interactions with two different servers, which may be located in different geographical locations, leading to increased round-trip times and overall response times for the client.
Is this true in my thinking?
Would I have to consider implementing the auth system/service within the MySQL server?
What are my options on what I should do?
Firebase's own services typically keep a cache of recently decoded ID tokens. This means they only hav to decode an ID token the first time they receive it, and after that can use the cached value (until the ID token expires of course).