2

I'm setting up a project with React Admin and GraphQL (powered by https://github.com/rmosolgo/graphql-ruby). By the looks of it, I should implement my own data provider.

Looking through the docs, it appears the v3 way to do it is to return an object composed of Promises, eg:

const dataProvider = {
  getList: (resource, params) => Promise,
  getOne: (resource, params) => Promise,
  getMany: (resource, params) => Promise,
  getManyReference: (resource, params) => Promise,
  create: (resource, params) => Promise,
  update: (resource, params) => Promise,
  updateMany: (resource, params) => Promise,
  delete: (resource, params) => Promise,
  deleteMany: (resource, params) => Promise,
};

However, looking at the GraphQL data provider examples, it appears they are using the v2 methodology. I'm unsure if that is because GraphQL data providers have to use the v2 way, or if they simply have not been updated.

Simplistically, I am wondering why not just return an object as above and perform the queries using Apollo within each method and format / return the results.

Am I missing something? This way (I think) would not run the introspection query, so maybe there's a downside to it that I am unaware of.

Any pointers would be appreciated :)

  • Facing a similar quest. Any updates on this? – Nicu Tofan May 01 '21 at 07:19
  • I created a dataProvider as above. Where exactly are you stuck? – Dan Jebamony May 02 '21 at 13:33
  • I do have a custom data provider that talks to the REST api and I am thinking about switching to GraphQl because it can retrieve the information that you need for an edit page for a contract in a single query. But the react-admin architecture doesn't seem to map nicely to the GraphQl way of doing things. Going with the edit page example, you know that you need the contract number, contract sign date and contract items. The natural way is to store this query along with the edit page. Same with the list, where you only require the number and date. – Nicu Tofan May 02 '21 at 18:27
  • What it all boils down to is that, from what I can tell, you loose the flexibility provided by the GraphQl because of the dataProvider implementation. You may need to retrieve various subsets of the resource but react-admin confines you to a single subset. Sure, you can define a distinct resource for each subset but feels somehow hackish. – Nicu Tofan May 02 '21 at 18:32
  • 1
    Sorry I missed this. In case you (or anyone else) are wondering, yes - you do lost a lot of the flexibility of GraphQL. The main advantage in my case was that my customer-facing app could also use GraphQL using the same endpoints so I did not have to build or maintain a REST API. That's big if you're lucky enough to have a pure GraphQL backend. – Dan Jebamony Oct 01 '21 at 10:18

0 Answers0