I’ve been using PostgREST as an ORM for about two years now. I know it may sound unconventional, but it’s definitely worth a try, especially if you’re building HTTP APIs. Here’s an example query:

    /investors?select=name,investments(id,founders(name,address(city,country)))&investment.exit=gt.1000000.00

https://postgrest.org

BlueChip is specifically for managing this data on the client. It is fetch and API agnostic. As soon as implement plugins normalization you could use postgREST with BlueChip.

I really like the look of that (the less moving parts and work I have to do the better).

The problem is data transformation in an API. Quite often it's not as simple as just taking data out and putting data into a table. I suppose some of that could occur in SQL and some moved client side though. Would be pretty slick to eliminate the whole framework in between.

wow thanks! I will be using this instead.

Just and FYI BlueChip and PostgREST serve different purposes.

Hey this looks great. So this would work out of the box for something like daptin[1] on server side ? It exposes http://jsonapi.org/ compliant CRUD APIs. If so, I would suggest getting it listed at http://jsonapi.org/implementations/ by sending them a PR

[1] https://github.com/daptin/daptin

I will check that out today and add it to the list of integrations if it does (it should if it complies with JsonAPI)

Check out OrbitJS - https://github.com/orbitjs/orbit . They've built something similar.

I'll just throw these out there as an alternative, or in addition to:

https://www.apollographql.com/docs/link/links/rest.html

https://www.apollographql.com/docs/link/links/state.html

The "apollo-link-rest" API makes it very easy to map, then query, your JSON APIs as a GraphQL service. So, no more mangling different query approaches for a client.

Then, simply add "apollo-link-state" to query/mutate local data using GraphQL as well.

This allows you to have 1 query/mutation language for both remote and local client state. This is much easier to deal with than adding yet another API to access your data.

Another positive is that you just might find yourself with the ability remove some redux boilerplate too as your local state can now be managed via Apollo's HOCs.

So, after writing this... What would be nice is to perhaps have the BlueChip API have an adapter layer that would allow it to read from something like the Apollo cache. This would allow for the implementation of resolvers on the client side to allow more fine grained control of the data being returned in a query (query parameter for filtering, cursoring and the like).

Thanks! I will check those out.

Abstracting the adapter layer is in the roadmap both for the specs (GraphQL, JsonAPI, nested or custom) and for the state managment (Redux, Mobx, Unstated, React setState, Pain JS Object, etc.)

Looks good! I've been using json-api-normalizer[1] and redux-object[2] to do something similar. The ORM functionality is a nice difference though, I'll have to try it out.

  [1] https://github.com/yury-dymov/json-api-normalizer 
  [2] https://github.com/yury-dymov/redux-object

this just makes me wonder why we don't just pass in SQL on the API calls, ala graphql.

The library is fetch agnostic so the api calls are not under the umbrella. The differentiator here is that you can take GraphQL payloads and/or JsonAPI (and in the future, custom payloads), normalize them into a store and select from them using the ORM. This allows you to use this setup with basically any JS state management system that opens and API to the client side store.

Because then you’re building your database schema into your public API, making it difficult to vary either.

Conversely, if your API isn't public, tightly coupling your stack together may be worth the tradeoff of brittleness vs. development speed.