Create a proper react-admin dataProvider around the open-balena-api OData api

[shaunco]

While #20 will likely be a quick fix, longer term, being directly dependent on the Balena DB schema is quite fragile.

For most ob-ui functionality, an OData react-admin dataProvider (or here) that wraps the Balena API would be far more stable since open-balena-api maintains backwards compatibility on v1, v2, v3, v4, v5, and v6 calls. (mapping them internally to the current v7 calls).

There might still be a few ob-ui features that require direct database/registry/s3 calls, like deleting releases (with all the nested image/storage cleanup).

[dcaputo-harmoni]

@shaunco This is a great idea and something I have had on my list for a long time. It would be a huge upgrade to openbalen-admin, providing all of the benefits of the SBVR rules / validation as well. The pinejs package can even handle database connection management / pooling. Just need to find a way to make days a bit longer to squeeze it in....

[shaunco]

I'll tinker with this over the next few weeks and see if I can come up with a first pass at an OData dataProvider

[dcaputo-harmoni]

Awesome. Just FYI - and I mention this because I was just tinkering with this code last week when we implemented a read/write split postgres cluster - I think the relevant line is here. We would need to initialize pinejs (which is passed a database config as well as the SBVR rules), and then invoke it for the various resources like this example for device types. The alternative is to use the exposed api of open-balena-api directly, but the issue there is that they don't actually expose api endpoints for things we need such as users.

[shaunco]

Thanks! Will take a look at those, but I'd like to avoid pinejs if possible 😬

My plan was to simply translate the resource types/ids/data and query strings that come into the dataProvider methods into OData requests. I've recently done a bunch of this in go and shell scripts (we have a nightly shell script that removes old/unused releases). There is pretty decent overlap between the two interfaces ... I might fall flat on my face and end up the pinejs route though, haha.

[dcaputo-harmoni]

Ok, that would be a lot simpler for sure! Good luck

[mkrenzke]

@shaunco I'd highly appreciate to get rid of Postgrest entirely. From my point of view it's not quite handy.

For those features not supported through the API, we could also implement new endpoints in the express-server which I'd prefer rather than working with pinejs. I'd be glad to help if support is needed.

[shaunco]

I'll try to post a pass in the next few days, but will need to iterate on it in a branch to avoid disrupting the main branch.

[dcaputo-harmoni]

@shaunco Just FYI, we are using API for some automation pipelines that move devices between openbalena environments, and I'm finding some pretty steep limitations - for example, users can only view their own API keys, including the global admin user. Not sure how we will get around this if using API as the dataprovider source, but just want to flag it - might need a database supplement.