4 ms·

I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning

by throwaway2016a 10y ago

I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning curve I love the flexibility. But in my opinion, the answer is: write code once, expose both interfaces. Here's what I mean... I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API. Then I also expose the GraphQL interface. So users that want to use GraphQL can. It's a win-win and it didn't take me any more time to develop than just REST. As an added bonus, the GraphQL code is inherently easier to unit test by nature. GraphQL has a lot of flaws (for one it has nothing to do with graphs -- nearest I can tell the name is only because it was first used for Facebooks graph database) and things like pagination and error handling have no standard way to do them. But it is very flexible.

brandur 10y ago
> I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning curve I love the flexibility. It's good to hear that there are some REST people that are open to potential alternatives :) > I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API. I'd certainly agree there. This could change in a year or two, but right now REST-ish APIs are still indisputably dominant. If you want to maximize your developers' experience, it's still too early to _require_ that they use GraphQL because there are going to be a lot of shops out there that are just not set up for it. Of course there is still the option of providing your own libraries and tooling for your users to go through, and if you go with that then the API's implementation is much less important.
ruslan_talpa 10y ago
If the answer is: "expose both interfaces" then my implementation is exactly it :) GraphQL & REST API for your database (https://subzero.cloud/ https://subzero.cloud/) At the core sits PostgREST (https://postgrest.com/ https://postgrest.com/)
- alnitak 10y ago
  What is your business model here? Is this (subzero) projected to be an open source product supported by paid services and support, or is it entirely a cloud offering a la graphcool, parse or firebase?
  - ruslan_talpa 10y ago
    It's going to be commercial, possible with access to source. You could run it on your infrastructure or have it hosted. Sort of like atlassian
  - PierreRochard 10y ago
    No reason it couldn't be a mix of both.
- _ar7 10y ago
  I hope you didn't just throw https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.
  - ruslan_talpa 10y ago
    Words can hurt you know ... :) https://github.com/begriffs/postgrest/graphs/contributors?from=2015-08-31&to=2017-03-31&type=a https://github.com/begriffs/postgrest/graphs/contributors?fr... It uses postgrest but not postgraphql, actually not even the graphql-js reference implementation
  - PierreRochard 10y ago
    Why? You don't think managing infrastructure composed of open source components is providing a valuable service?
paulddraper 10y ago
> for one it has nothing to do with graphs It can readily convey graph information, e.g. what are the first and last names of the friends of the friends of user 123? But yes, there's nothing really graph specific. If it bothers you that "Graph Query Language" is too specific, just remember that "Structured Query Language" is too general :)

brandur 10y ago

> I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning curve I love the flexibility. It's good to hear that there are some REST people that are open to potential alternatives :) > I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API. I'd certainly agree there. This could change in a year or two, but right now REST-ish APIs are still indisputably dominant. If you want to maximize your developers' experience, it's still too early to _require_ that they use GraphQL because there are going to be a lot of shops out there that are just not set up for it. Of course there is still the option of providing your own libraries and tooling for your users to go through, and if you go with that then the API's implementation is much less important.

ruslan_talpa 10y ago

If the answer is: "expose both interfaces" then my implementation is exactly it :) GraphQL & REST API for your database (https://subzero.cloud/ https://subzero.cloud/) At the core sits PostgREST (https://postgrest.com/ https://postgrest.com/)

alnitak 10y ago
What is your business model here? Is this (subzero) projected to be an open source product supported by paid services and support, or is it entirely a cloud offering a la graphcool, parse or firebase?
- ruslan_talpa 10y ago
  It's going to be commercial, possible with access to source. You could run it on your infrastructure or have it hosted. Sort of like atlassian
- PierreRochard 10y ago
  No reason it couldn't be a mix of both.
_ar7 10y ago
I hope you didn't just throw https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.
- ruslan_talpa 10y ago
  Words can hurt you know ... :) https://github.com/begriffs/postgrest/graphs/contributors?from=2015-08-31&to=2017-03-31&type=a https://github.com/begriffs/postgrest/graphs/contributors?fr... It uses postgrest but not postgraphql, actually not even the graphql-js reference implementation
- PierreRochard 10y ago
  Why? You don't think managing infrastructure composed of open source components is providing a valuable service?

paulddraper 10y ago

> for one it has nothing to do with graphs It can readily convey graph information, e.g. what are the first and last names of the friends of the friends of user 123? But yes, there's nothing really graph specific. If it bothers you that "Graph Query Language" is too specific, just remember that "Structured Query Language" is too general :)