Prospects of using graphql over REST in badgeyay

[djmgit]

As discussed in the hangouts call on 30th April'18, we need to consider the prospects of using GraphQl over normal REST. Now the things we need to consider our what are the pros and cons of using graphql in badgeyay over REST. Do we actually require GraphQl at all keeping in mind the functionalities that badgeyay offers or will offer. Can graphql improve badgeyay or will it be an overkill for the system?

[djmgit]

@gabru-md @vaibhavsingh97 @yashLadha @ParthS007 Please share your views, lets have an open discussion on this.
@SaptakS it would be really helpful for us if we can get your inputs on this :)

[yashLadha]

According to the research which i have done till now, Graphql is basically a query language that provides an addon layer to efficient API. Like suppose structure for a particular request is too big them we have to either do multiple rounds of querying or create specific endpoints for the task. But by specifying the params needed to be fetched from the request eases the problem of multiple rounds of query and creation of specific end point. I think if the structure of the API becomes too much nested and deep them we should move to Graphql. Also it is going to provide subscription them we can also use it to have like socket or websocket communication. If we are thinking of the bigger picture and going to scale it in future then probably, Graphql will hugely benefit the system. Also i don't think it will be an overkill as we are going to expand the features.

[djmgit]

@yashLadha the question here is will badgeyay ever require such complex db query or will it ever require to have such complicated relationships between models?

[yashLadha]

May be in later future when we do user management and dashboard preparation or admin panel, then probably we can have flexible querying with Graphql. Like showing results according to some specific roles. Also why not to use both as pointed in this article. for eventbrite API. Also the queries become much simpler and better understanding while modification. Link

[ParthS007]

I would like to mention some points in reference to need of Badgeyay.

1. Architecture

• REST is an architectural concept for network-based software, has no official set of tools, has no specification, and is designed to decouple an API from the client.
  while
  GraphQL is a query language, specification, and collection of tools, designed to operate over a single endpoint via HTTP, optimizing for performance and flexibility.
  So
  When utilizing HTTP, REST can leverage HTTP content-types, caching, status codes, etc., whereas GraphQL invents its own conventions.

2. Data Transfer

• REST APIs provide is CRUD via JSON, but it can do plenty more than that, such as file uploads.REST API support application/JSON requests on the same endpoint to handle the upload slightly differently, and offer URL-based uploads too.
  while
  If we were talking about uploading files, we will have to switch to another approach and have a dedicated service which handles the upload, leaving the main API to only accept metadata; title, description, tags, etc. This is the approach we are forced to take with GraphQL because we can only speak to GraphQL in terms of fields.
  So
  Being forced to create another service is overkill for smaller images and we have to depend on other a server and various clients can even support it. This is one area where REST holds strong.

3. Caching

• In an endpoint-based API i.e REST, clients can use HTTP caching to easily avoid refetching resources, and for identifying when two resources are the same. The URL in these APIs is a globally unique identifier that the client can leverage to build a cache.
  while
  In GraphQL, though, there's no URL-like primitive that provides this globally unique identifier for a given object.
  so
  It's hence a best practice for the API to expose such an identifier for clients to use. REST over HTTP uses a whole pile of HTTP conventions that make existing HTTP clients, HTTP cache proxies, etc., all work easily to benefit both API clients and API servers, but with GraphQL… tough. Reorganize your data stores, use a bunch of Redis as said by @yashLadha in yesterday meeting, and hope clients are caching too.

PS : I have read some articles and blogs to write this. My words seem to match them but I have concluded according to needs of Badgeyay and others may have different views & I am open to it. I have no problem in following these two approaches but we should follow that is best suitable for badgeyay.
Please correct me if I am wrong Somewhere. 😃

[ParthS007]

Main Point is DATA TRANSFER which is main need of Badgeyay.

[yashLadha]

But the need for ease of query will be greatly resolved with the help of graphql and also gives the better understanding of the structure. We can have both the things to work.

…

On Tue 1 May, 2018, 8:19 PM Parth Shandilya, ***@***.***> wrote: Main Point is DATA TRANSFER which is main need of Badgeyay. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#674 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ARMqT18hvNRl-lHmBys8llprKNLVva-Rks5tuHYWgaJpZM4Tt7PS> .

[gabru-md]

Since Badgeyay is going to be a self centric application, that means that the only agent that will ever need to access Badgeyay's API will be its frontend and no one else.
I have seen GraphQL being used at places where the sole purpose of the product is to provide an Open API to audience. For example : Github API. There are many people using the same API for several different purposes so they require GraphQL but here at Badgeyay the only user shall be the frontend and we can easily manage that using RESTful APIs built in Python.

And kudos to @ParthS007 for pointing out so many different points between the usage of both. :) 👍

[gabru-md]

This is a really valid point @ParthS007
and since our API needs to deliver endpoints for file uploads as well I agree with your point here

If we were talking about uploading files, we will have to switch to another approach and have a dedicated service which handles the upload, leaving the main API to only accept metadata; title, description, tags, etc. This is the approach we are forced to take with GraphQL because we can only speak to GraphQL in terms of fields.
So
Being forced to create another service is overkill for smaller images and we have to depend on other a server and various clients can even support it. This is one area where REST holds strong.

[yashLadha]

It is also used in enterprise systems and as facebook has opensourced it, it is also being used in their codebase. I have seen talks given by developers of shopping portals about how they have used it for sending data to frontend according to needs.

[yashLadha]

For file uploads visit this thread https://stackoverflow.com/questions/46333870/upload-files-using-flask-and-graphene?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

[gabru-md]

This is written in the article you linked to, @yashLadha :

REST over HTTP uses a whole pile of HTTP conventions that make existing HTTP clients, HTTP cache proxies, etc., all work easily to benefit both API clients and API servers, but with GraphQL… tough. Reorganize your data stores, use a bunch of Redis, and hope clients are caching too.

[ParthS007]

@yashLadha Please visit the source of the link and I am posting the comment of the contributor who's code is used as a answer in the above question.

[yashLadha]

Here is the issue link to the repo graphql-python/graphene-django#101