Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is GraphQL the Next Frontier for Web APIs?

brandur.org

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Is GraphQL the Next Frontier for Web APIs?

#51

Post by jondubois »

dragonwriter wrote: post #50
jondubois wrote: post #49

Earlier quoted context omitted.

GraphQL and REST solutions will almost certainly be much faster than any CRDT solution. I think that the REST solution should be more efficient than the GraphQL solution but it probably won't be a drastic difference. The essence of the REST philosophy is to deal with data as small atomic building blocks - I think that this is one of the most important and well-tested ideas in software engineering so on that basis, I…

> The essence of the REST philosophy is to deal with data as small atomic building blocks It's actually not ; that seems to be something imposed after the fact by association of REST with a thin layer over a normalized DB model. REST is neutral about both the size and atomicity of resources.

Only when you read a filtered list of resources but not for CRUD operations (CRUD operations make sure you deal with a single resource at once). My main point is that writes are atomic.

Re: Is GraphQL the Next Frontier for Web APIs?

#52

Post by djmashko2 »

irq-1 wrote: post #28
brandur wrote: post #3

It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integrate with APIs more quickly and more safely. I'm interested to hear about what people think about the subject. (I'm the author.)

Thinking about the problems with client-side SQL seems informative[0]: * Security; allowing evaluation rather than a describing results. * DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries. * Performance; Stored Procedures (server-side) pr…

I cover a lot of these thoughts in my post about misconceptions about GraphQL coming from REST here: https://dev-blog.apollodata.com/graphql-the-next-generation-...

Re: Is GraphQL the Next Frontier for Web APIs?

#53

Post by mercer »

bigmanwalter wrote: post #35
njharman wrote: post #33

Earlier quoted context omitted.

How are your RPC examples not REST? RPC would involve client lib. And may or may not even use HTTP as transport. api.get_product(id=1) api.add_product(details)

I thought we were talking about RPC over HTTP. My RPC examples don't qualify as "proper" REST where you are only supposed to GET and POST singular resources at a time. In order to post multiple, you need a collection identifier. In REST, you can't GET "items", you can get "item1" and "item2" or you can get "collection1" to which "item1" and "item2" belong. Maybe a clearer example around running a script: REST: POST /…

Interesting. It sounds rather similar to me as the way the difference between functional and OO programming is often described (verbs-first vs nouns-first). Is there anything to that or am I comparing apples with non-apples?

Re: Is GraphQL the Next Frontier for Web APIs?

#54

Post by ruslan_talpa »

jondubois wrote: post #49
FractalNerve wrote: post #42

Earlier quoted context omitted.

This list is very interesting! Which one performs the best in: • Raw Performance • Proven Architecture • Robustness & Congestion Tolerance • Backward & forward compatibility • Customizability Is ASN.1 by Fabrice Bellard the fastest serialization format? http://bellard.org/ffasn1/ Here's a lits of all formats: https://en.wikipedia.org/wiki/Comparison_of_data_serializati...

GraphQL and REST solutions will almost certainly be much faster than any CRDT solution. I think that the REST solution should be more efficient than the GraphQL solution but it probably won't be a drastic difference. The essence of the REST philosophy is to deal with data as small atomic building blocks - I think that this is one of the most important and well-tested ideas in software engineering so on that basis, I…

GraphQL should not deal with that at all imo (authorization). the underlying service (rest/database) should be responsible for that. What GraphQL implementation should do is "tell" the underlying service who is making the request and let it handle authorization. And endpoints/fields in GraphQL schema should not be "hidden" based on who is currently logged in.

Just like in sql you are free to see all the available tables in the databases and do "select * from secret_table" it does not mean you will get back any data. The same way you should be able to query any field in graphql but get an error in case you are trying to access data that you are not supposed to.

Re: Is GraphQL the Next Frontier for Web APIs?

#56

Post by alnitak »

ruslan_talpa wrote: post #38
throwaway2016a wrote: post #27

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 in…

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

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?

Re: Is GraphQL the Next Frontier for Web APIs?

#57

Post by _ar7 »

ruslan_talpa wrote: post #38
throwaway2016a wrote: post #27

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 in…

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

I hope you didn't just throw https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.

Re: Is GraphQL the Next Frontier for Web APIs?

#58

Post by ruslan_talpa »

_ar7 wrote: post #57
ruslan_talpa wrote: post #38

Earlier quoted context omitted.

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

I hope you didn't just throw https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.

Words can hurt you know ... :) https://github.com/begriffs/postgrest/graphs/contributors?fr...

It uses postgrest but not postgraphql, actually not even the graphql-js reference implementation

Re: Is GraphQL the Next Frontier for Web APIs?

#59

Post by ruslan_talpa »

alnitak wrote: post #56
ruslan_talpa wrote: post #38

Earlier quoted context omitted.

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

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?

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

Re: Is GraphQL the Next Frontier for Web APIs?

#60

Post by PierreRochard »

_ar7 wrote: post #57
ruslan_talpa wrote: post #38

Earlier quoted context omitted.

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

I hope you didn't just throw https://github.com/postgraphql/postgraphql and https://postgrest.com/en/v0.4/ behind some closed source code and called it a business.

Why? You don't think managing infrastructure composed of open source components is providing a valuable service?
Post reply on HN