Over the years REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them.
GraphQ...
For further actions, you may consider blocking this person and/or reporting abuse
No. It's complicated.
In my most of scenarios, it's good enough to use the normal RESTful API and it can resolve most of requirements.
REST is everywhere so I'm quite used to it. A few days ago I tried playing around with HashNode's GraphQL API and to be honest I struggled. To me, it looks like that the learning curve for GraphQL is much steeper, so I'm still a fan of good old REST!
Hashnode's API was my first contact with it too 😃 I must say I love it and it reminds me of working with DOM in the browser 😉
Nice! I actually got stuck with the new post creation, did you manage to get it to work?
I was working with their API the other way around - for fetching data. But for posting, I believe you have to make a mutation, as shown in this example to create a new story.
For further assistance, I would recommend their Discord server. Together we already found a bug in their API by discussing particular ways of retrieving data.
Thanks, sounds good! I will try it out! 🙌
I'm pretty skeptical of a large GraphQL API's performance over time, but have never worked with one. I'm starting a new job in December whose primary api is a flask based graphql one tho, so I'll find out soon!
I've read about some other devs being skeptical about using it on large projects, too 😉 Tho, it is a widely-used tool nowadays, and every situation you could possibly face should already be backed up by some workaround/best practice 😉
My use graphql in production. The ideas are good but think it not worth it. schema is nice, but I would love to build an app with
fastify+swaggeris a piwerful combination.Graphql does not deliver on its promise against overfetching. What I observe, is that frontend developer take the complete type definition and fetch everything in one go.
and it needs a huge shift in the mindset of developers. in rest and graphql alike, I observe that APIs get implemented specifically for separate pages.
Often I think graphql is more something for personalized data. With rest there are very good tools for caching like
varnishthat cache the hell out of your rest api apps. but not so much with graphql.Yeah I love GraphQL but I prefer REST. At first making a GraphQL API is in my opinion much more complicated than making a REST-API (in Java, Node, Python etc.). You can write a simple GET Request in 3 lines in Express (framework on Node.js).
I also think that GraphQL has not enough pro's over REST to replace it.
right now its only meant for JS or Js frameworks especially React.
However, from Using it in Laravel using the lighthouse-php for laravel works fine for me and I am exploring it more. Then only I can be assure that it is good to use GraphQl over REST.
I have experience with both GraphQL and REST, and while I appreciate both I do think the dynamic capabilities of GraphQL architecture makes it more flexible for complex data structures. It's harder to fit a complex data structure in REST in an efficient way and create a fast API in my experience. I do think GraphQL lends itself to programming efficiency because it can handle a lot in one query. But this is also coming from the API testing perspective, not a development perspective :)
GraphQL with gRPC is the best approach if you really want to escalate the application you build, there is no matter to discuss here. More performance (gRPC, as you don't need to parse JSONs and the weight is smaller), the ability to ask for some extra data from the front without the need to make changes to the API itself and so...
I call bias and shallow the arguments against REST and in favour of GraphQL.
There is no absolute best, each project presents its architectural challenges. these challenges are going to define the best tools for the project, not favouritism or personal preference.
REST API, bcoz what to do if data needs some processing!
Client directed security API (CAC or SmartCard driven).
I prefer REST since its easier to work with on small projects. If you have a really complex app with lots of fields on the models I can see it the appeal of graphql though.