Design Proper API for Data Access

[keenanjohnson]

No description provided.

[spestana]

I don't have a background in databases or data management, but do have some thoughts on this. This might be more complicated and maybe for something later down the line, but rather than designing an API, I think there are a couple options that would make the use of Ribbit Network easier and adopted more quickly. 1) We could try to contribute data to an existing air quality or similar database, or 2) we could implement an already existing API standard.

• Orgs like OpenAQ have methods for contributing data from partner organizations/networks. They do not have anyone contributing CO2 observations yet. And OpenAQ is already has a community of data users. A benefit of this is being able to focus on the low-cost frog sensors and leave the data management/distribution to someone else.
• FLUXNET, and it's Americas component Ameriflux, is a network of independently owned/operated eddy flux stations (measuring CO2, H2O, CH4... concentrations and 3d winds). I am not sure if they would be interested in hosting ribbit network data (it would be very cool though if they were interested), but regardless they would be a good group to talk to anyways.
• Similar to FLUXNET, I wonder if the ESRL GML would be interested in citizen science collaboration like this?
• the Open Geospatial Consortium has specs for different standards, I'm not so familiar beyond what I typically work with (imagery)

[keenanjohnson]

FYI we made a start at an API design here: https://github.com/Ribbit-Network/api

[fosteman]

Hm, @keenanjohnson, why was Go chosen as the language to go ahead with ?
No judgement, just curious.

My thoughts would be to spin up a kubernetes cluster of 1-2 containers running the code. Code itself, since it's a simple API, may be nothing particularly interesting.

Also, in relation to Dashboard codebase, it'll be nice to have our own API instead of relying on DB connector right there.

[fosteman]

Yeah, there's a way to contribute to OpenAQ -
https://github.com/openaq/openaq-info/blob/master/FAQ.md#contributing-data-sources-1

[keenanjohnson]

Hey @fosteman ! The decision for Go was made by the original API author and I'm not sure why that was made.

[keenanjohnson]

@abhinavtripathy and I discussed this a bit today that there are two primary use-cases for the API.

• The front-end website reading the data from the database to render the plots and the map.
• The Frog sensors publishing data to the database