Are you considering GraphQL for your next projects than REST?

[Ben Hayat]

Hi Guys;

I’m going to ask two questions under this title;

Note: Most of us, including myself, might be more comfortable to use REST due to more tools out there and a lot more information, due to it’s age. So it’s easier to use something that you know more & better, but not necessarily the best choice. And that’s the reason for this post.

I recently worked on a project that I had to write both backend REST APIs and Front end. The backend was using old Store Procedures that was already in place and I could not change them. I ended up having lots of endpoints to cover many cases. On the frontend I had to make lots of round trips to get the final outcome. This made the frontend slow on the data fetching.

Because of that experience, I’m considering to use Vue+Apollo GraphQL for front end, and build my backend with .Net GraphQL to access PostgreSQL. This way, I can minimize the # of round trips and payload size.
It requires a lot more work building the GQL server than an REST server. Is it worth it???

Having said that,

1. For NEW project, do you guys consider using GraphQL over REST? If Yes or No, Why?

2. For those who are already using GraphQL, was it worth the extra work?

I thank you in advance for your wise and experienced comments!
…Ben

[s.molinari]

My 2 cents. You might think about just making the jump away from .NET as a backend, if you can. There is so much out there built around Node and GraphQL already, aka a good number of Frameworks and libraries, it might amaze you. The other awesome thing about using Node is avoiding the language paradigm switching. This adds to productivity (well, if switching is an issue for you. It was always for me with PHP).

As for using GraphQL, I’m a fan of it for a couple/ few years, but like a sideline cheerleader. I’m just now digging into coding with it TBH.

There are more advantages to GraphQL than just the way it caches and saves backend calls/ data over the line, especially with a SFC system like Vue has. To me, the ability to put the component data concerns straight into the components (or relatively close) and not at some intermediary level to then have to figure out how to best “spread the state out” is a huge win. It helps to make your app much easier to reason about. Apollo also offers client state management (albeit it is fairly generic), which means, (currently for me only in theory) you don’t need Vuex at all. I’ve heard though others have still opted for Vuex. Seems silly to me currently, but again, I’m just getting into the coding of it all.

Scott

[Ben Hayat]

@s-molinari
Thanks Scott; I will give deep thoughts to your points.
Especially that I can get away with Vuex

Thanks buddy!
I still need to figure out what Apollo+Quasar adds to Vue+Apollo. Any short answer?

[s.molinari]

There is no difference. QApollo just gives you the “Quasar way” of adding Apollo to Quasar (which is over the vue-apollo package). So, QApollo helps you with installing the basics needed to get a Quasar package running with Apollo as a GraphQL client.

Scott

[qyloxe]

@Ben-Hayat
hi, me again.

GQL is interesting indeed. As for now it helps in many aspects of stack, in the future it will help (probably) even more BUT with choosing a technology there are (at least) two simple rules, which you just can’t omit:

1. you can’t destroy complexity of the system - you can only shift it from one place to another. If you make it easier for data-savvy front-end developer, then you just made some kind of hell for back-end guy. If the back-end guy keeps all the cards, then front-end wizards just will not fly.

2. the structure of the system tends to mimic the structure of the organization. So if you have flat organization with good communication between backend-frontend you will not need a solution like GQL. If you have strict, hierarchical organization with “islands of power” then GQL will take some of “this power” from backend people to the frontend people. Of course in every scenario devops are in total hell.

IMHO this is not a technological decision. It is a business one. How much people you have, what is the scope of your project, how much time you have? With graphql the time estimation of future work is biased with much bigger error because you WILL encounter unexpected.
Personally I see a GQL, as it comes from Facebook as a sign, that frontend people didn’t had a good relations with backend because they invented something which gives them a full control of data shapes. I can say even more, they didn’t had even good relations with designers because they like to mix the code with HTML/presentation with their abomination of information architecture called JSX
In the essence - if your organization has similar dysfunctional way of working than maybe this will work. If you can find a business value in this - in the context of future changes, than this will (maybe) work, too. I am sure, that in some point, the GQL will have enough momentum, when many developers will come to the base architecture with their own experiences, that it will be quite OK. Maybe even Quasar will help with that in some way?

[Ben Hayat]

@qyloxe said in Are you considering GraphQL for your next projects than REST?:

So if you have flat organization with good communication between backend-frontend you will not need a solution like GQL.

Well my friend, all your points are well taken, but after many years of jumping into hot tech with both feet and burning them, I’ve become more cautious now. I try to evaluate and find a balance of need.
What you said above has been my exact conclusion. In my case, I have FULL control over both ends. If frontend needs a fancy JSON payload that may stretch over several tables on the backend, I can have a REST endpoint that creates a special model, fetches the data via ORM, fills the model and sends it back to frontend. So in this case, the REST API basically provides what the front end needs, and that’s because I/we have control over both ends. And I had come to the same conclusion as you had said. GQL is great when these two ends are two different nations who need a proxy to talk to each other.
Thank you my friend

[s.molinari]

I can’t disagree with you about the complexity. In fact, many a dev have asked a lot of questions to extending the GraphQL spec to include specialties, which are business logic requirements. One coming to mind is authorization. Who can see what is coming out of your server? It almost makes perfect sense to have that logic in a GraphQL gateway and there have been many, many calls to put that logic in the GraphQL DSL, possibly as a directive, and thankfully, it has never been accepted. Authorization belongs in the busines logic.

One thing I will say is, I am certain GraphQL can actually simplify both the back-end and frontend dev efforts, because the things needed to design the API are based more in the business logic and needs and less on any certain architectural paradigms like REST. GraphQL is a clear standard and because it is a standard, nobody is wasting too much breath about what the “right way” is all about. It’s more about “how can I model my business best?”. Since that is the core discussion, the solutions end up better for the business in general, because there is no loss in technical debt in “getting it right”. This is another advantage not often talked about, when it comes to GraphQL.

I feel, to get GraphQL best, what it can do and how, everyone needs to learn the paradigm change GraphQL brings with it. It did not come about at Facebook because of any problems between front and backend dev communication. That is just nonsensical conjecture and incorrect (@qyloxe ). It came about, due to the effort required to maintain Facebooks REST API and versioning for all the sprouting needs they had like rebuilding their “native” iOS and Android apps and getting their “news feed” to mobile. Btw, that is another big advantage of GraphQL. A versioning system, like is needed with any decent REST API, isn’t an issue or rather, isn’t even needed.

My eyes were opened watching this video and I was sold from there on out (I can’t believe it’s 5 years ago. OMG!).
https://www.youtube.com/watch?v=9sc8Pyc51uU

This second video is only a nice one to watch too to get a feel for the “why did GraphQL come about”.
https://www.youtube.com/watch?v=783ccP__No8

Edit: In the last video, listen to what Sascha Solomon says about Twitter’s dev experience for the backend. I think that is hugely key to GraphQL’s adding to simplicity in the API. The schema is written by machines, not humans. Humans should only need to concentrate on the business logic. The schema is generated automatically from that. Awesome!

Enjoy!

Scott

[jraez]

Just a quick answer.

No. I use Python/Django/Django Rest Framework and it’s quick fast to develop REST API. It’s my very personal opinion but I think GraphQL is more suitable (in terms of overhead) if you use NoSQL datastores (elastic search, mongo, etc.). If you use anything SQL based, somehow you’ll have to translate your GraphQL to SQL which adds unnecessary complexity.

[dobbel]

I am using Meteor.js + Mongodb that (mainly) uses a sub/pub system ( realtime db out of the box) instead of rest and graphql ( you can but I don’t) . There’s nothing faster in terms of backend development for medium to small apps. And meteor integrates great with quasar/vue’s reactivity to build real time app’s out of the box.