GraphQL needs a good server side library. But for e.g. C# I've found only libraries that can't be called stable. With stability I also mean who is developing and maintaining the code? If it's just one person effort it can't be called stable. I have understood it's much better in Java side, so perhaps if you can start your backend with Java/kotlin/Scala you are good to go.
REST in Peace. Long Live GraphQL
71–80 of 94 posts
Re: REST in Peace. Long Live GraphQL
#72Earlier quoted context omitted.
Right but then you have to build a custom http api for each and every new view. Oh, and now you altered the view a tiny bit and need some more fields? Add yet another api. Oh, you did a redesign and you only need a tiny bit of data now? Either add another api again, or deal with the fact that you're wasting bandwidth by sending a bunch of unnecessary data.
or you can pass the fields you want in your request, and then realizing it would be simplier to fetch all your data in only one endpoint to avoid multiple roundtrips, create a giant request-parsing-data-fetching logic to respond with some kind of nested data, yeah GraphQL is useless because we can build a new one from scratch for each of our projects ;)
...at which point you reinvented the wheel and it's very likely that the GraphQL library for your language works better and maybe faster.
winks>
Re: REST in Peace. Long Live GraphQL
#73I've often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn't perfect, but it has been reliable for a long time 3) Why we didn't increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly? Ok, there are a lot of reasons. I worked on a project once that was essentially a "da…
Why "never really took off"? It's quite widespread in MS-related enterprise world. And it provides a lot of value there. It's just it wasn't adopted widely by the others because of different reasons
Re: REST in Peace. Long Live GraphQL
#74I've often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn't perfect, but it has been reliable for a long time 3) Why we didn't increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly? Ok, there are a lot of reasons. I worked on a project once that was essentially a "da…
about exposing databases directly, https://postgrest.com comes quite close to what you are describing
Sure does, and that is one project I have been watching for a while :) Thanks for sharing it!
Re: REST in Peace. Long Live GraphQL
#75I've often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn't perfect, but it has been reliable for a long time 3) Why we didn't increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly? Ok, there are a lot of reasons. I worked on a project once that was essentially a "da…
Why "never really took off"? It's quite widespread in MS-related enterprise world. And it provides a lot of value there. It's just it wasn't adopted widely by the others because of different reasons
Well, I suppose that's a relative judgement. I agree it is more widely used in the MS-related world.
In my thinking, "taking off" would have been if the rest of the ecosystem had embraced it. OData is shared as an open standard (http://www.odata.org), but there is something about it where I still haven't seen the broader ecosystem embrace it (although certainly many have adopted some of the style of OData REST endpoints). That said, compared to where it was when it first came out, OData is still getting a lot of attention. I think opening up the tech is what kept it alive, to be honest.
Just for kicks, I did a Google trends comparing OData nd GraphQL, kind of interesting: https://trends.google.com/trends/explore?q=odata,graphql
Re: REST in Peace. Long Live GraphQL
#76"who in their right mind would use XML over JSON today?" Lost me already... there are lots of reasons to still use XML today. And since someone is going to ask, here are some: * you want to use xpath * you want to communicate with an enterprise app (salesforce, magento, etc) * you need strongly-typed message-passing in a human-readable well-understood format (rules out messagepack, etc) * nobody actually documented t…
I read that too and assumed the author was confining that to the type of development they do. Either way it comes off a ignorant and even a little rude.
Re: REST in Peace. Long Live GraphQL
#77REST is certainly not dying anytime soon, GraphQL is just solving the data fetching problem in a different way. My intro to GraphQL came from researching GitHub's move towards it. For those interested, I chatted in detail with API manager there on my podcast. Transcription is also available for those who want to skim. https://www.heavybit.com/library/podcasts/jamstack-radio/ep-...
Re: REST in Peace. Long Live GraphQL
#78I guess this makes me sad. Apparently REST has come to mean such a small and specific thing that a REST vs. GraphQL comparison makes sense.
There actually shouldn't be anything contradictory about choosing the GraphQL interface for a REST API.
Also, before anyone jumps in head first on this, keep in mind the downside to things like GraphQL. Your data API is a promise to your clients and GraphQL presents a flexible, unbounded API. This puts a heavy burden on the data service: it's going to have to handle all the valid queries and perform well doing it.
Further, there are a lot of things that will have an impact on this, such as how/where the data is persisted and what the data model is, how the service needs to scale, etc. These will all be impacted by using GraphQL as your data interface. It's a lot to commit to, especially if you aren't sure how these things will change over time.
Re: REST in Peace. Long Live GraphQL
#79Earlier quoted context omitted.
Not sure how magical your automatic optimizations are - but my experience does not at all mirror yours. i've certainly had to hand-optimize queries to improve performance, on top of the query already being automatically optimized. Removing unused data, tying across custom relations and moving things into different forms of caching are all quite manual efforts I've done plenty of. So, not sure how "less common than yo…
Mostly i'm referring to the methodology I followed here: https://dev-blog.apollodata.com/optimizing-your-graphql-requ... I haven't looked into optimising other types of architecture (eg GraphQL server talking directly to the database), but there seem to be plenty of solutions that people are happy with.
That doesn't touch upon the N + 1 query problem at all.
Re: REST in Peace. Long Live GraphQL
#80Not sure what you're using for your api framework, but you can definitely fetch only particular fields on your get requests with Django Rest Framework.
Also, you can definitely version nicely. You just have to document it well. If you're supporting different api version in you're bound to add more code, not sure what that argument is about, since I assume (could be wrong) you'd have to define a new schema and add new logic to handle the queries in the translating layer, correct?
Also, the author makes a bold title and then goes ahead and mellows it in the first few paragraphs. Stick to it or don't do it at all.