Skip to content

Latest commit

 

History

History
39 lines (24 loc) · 2.83 KB

NOTES.md

File metadata and controls

39 lines (24 loc) · 2.83 KB
Raw

Notes

Invenio RDM

Rate Limits

The rate limits for OAI-PMH identifier lists is per minute.

The rate limits for OAI-PHM records is per hour.

The rate limits for REST API records appear to be 500 per minute and 5000 per hour with a distant reset.

CrossRef/DataCite mapping

https://doi.org/10.3847/1538-4357/acacf5 ApJ https://doi.org/10.3847/2041-8213/ac8e5f ApJL https://doi.org/10.1063/PT.3.5157 Physics Today, Failure to pick up day https://doi.org/10.1016/j.chemgeo.2022.121272 Article number, Bogus issue number, fails to pick up art no https://doi.org/10.1186/s40854-022-00444-4 https://doi.org/10.1038/s41746-022-00738-y No article number, All APS titles https://doi.org/10.1103/PhysRevD.106.124045

Extending RDM's JSON API with PostgREST

Invenio RDM is uses Postgres as it's primary metadata data store. While RDM's JSON API is rich it is also significantly rate limited. It is also undesirable to remove those limits as we may wish to use them via JavaScript for specific client side interactions.

PostgREST can present an alternative JSON API leveraging RDM's current SQL implementation generated by Invenio's ORM. The primary challenge is that Postgres powering Invenio RDM in our deployments runs in a container. We'd need to change the container rules and allow an external connection to the host environment to make the Postgres content available via PostgREST. An additional challenge is the PostgREST documentation shows providing access and control of PostgREST actions happens via Postgres SCHEME. Invenio RDM uses the global schema as far as I can tell. Documenting the permission and user settings allowing PostgREST to function will need to be included in extending Invenio RDM's to support an alternative JSON API. Initial experiments using a copy of RDM's Postgres database seems to establish this approach is possible.

A significant about of RDM's table definitions relies on JSON columns. SQL Views gives us the option of re-organizing these in to a traditional table relationship or combine tables JSON columns into aggregations. Views should allow is a means of easy reference to rich data structures via JSON API. It also ensures consistent queries through URL end points (e.g. You don't have to make sure your app is using the same "select" query syntax/options if you are retrieving the data via a view).

Reference

  • PostgREST, provides a JSON API "out of the box" for databases hosted in Postgres.
  • GraphQL Go packages
    • graphql-go, server implementation, focus on easy of use, scheme based approach
    • eggql an easy GraphQL server library that can be implemented without schema
    • gqlgen a Go GraphQL generator