The api package is designed to run standalone, separated from the coordinator. The reason behind this is to support horizontal scaling, and to isolate the coordinator workload from the api.
We included the StateDB in order to provide info on the GET /health endpoint, the problem is that this requires the api to be run on the same machine of the coordinator/synchronizer.
Implementation
In general we're using Postgres as a message channel for coordinator ==> api communication. This is not the most elegant solution, but it allows us to:
Avoid repeated computation: since api instances can be replicated, we move the responsibility for repetitive and DB intense queries to the coordinator/synchronizer, this way we run it just once (check how GET /state is working)
Easy configuration: since the config of the node can be complicated, the api instances rely on the coordinator config instead of asking this to instantiate themselves. This way we have easy to instantiate APIs and at the same time avoid consistency problems among instances
Rationale
The
apipackage is designed to run standalone, separated from the coordinator. The reason behind this is to support horizontal scaling, and to isolate the coordinator workload from theapi.We included the
StateDBin order to provide info on theGET /healthendpoint, the problem is that this requires theapito be run on the same machine of the coordinator/synchronizer.Implementation
In general we're using
Postgresas a message channel forcoordinator==>apicommunication. This is not the most elegant solution, but it allows us to:apiinstances can be replicated, we move the responsibility for repetitive and DB intense queries to the coordinator/synchronizer, this way we run it just once (check howGET /stateis working)apiinstances rely on the coordinator config instead of asking this to instantiate themselves. This way we have easy to instantiate APIs and at the same time avoid consistency problems among instances