Come up with plan for getting ooni/data served to end users

[hellais]

No description provided.

[hellais]

I have started working on an API which is to be implemented inside of ooni/data directly, see: https://github.com/ooni/data/blob/main/oonidata/dataviz/web.py.

I think the best way forward in terms of getting this to end users is that we should either expose the OONI Data host directly or setup a reverse proxy to forward requests from api.ooni.io.

That's because we would like to keep the experimental oonidata codebase running on a separate dedicated machine/database instance to minimise the risk of compromising the production database that is critical path WRT measurement submission.

@FedericoCeratto what are your thoughts on this?

[hellais]

I think we now have a plan for this.

It will entail implementing:

1. API endpoint that serve OONI/data tables in an way that's compatible with list_measurement: Create list_observations API endpoint data#35
2. API endpoint which is compatible with the aggregate views Create aggregate_observations endpoints data#36
3. Add support to OONI Explorer to switch between querying fastpath tables and observation tables
4. Implement nginx proxy in front of OONI/data to forward requests to api.ooni.io to the oonidata host
5. Deploy all into prod 🚀