Feature proposal: GraphQL API

[BboyStatix]

• Please tell us about yourself (include an email address):

  Naveed Elahi statix231@hotmail.com

Asalamualaikum, I was just wondering if a GraphQL API has been considered? I think it would benefit the Ummah greatly as developers will be able to ask for exactly the data they need, and that too in a declarative manner which makes the developer experience extremely intuitive.

There are two approaches to implementing this:

1. Create the GraphQL layer on top of the existing REST APIs. This way one simply writes the resolvers that call the endpoints to give the user the data that they need.
2. Create a GraphQL endpoint in the existing repository and create the schema and resolvers that would read from the database directly and give it to users.

I think option 2 would be pretty efficient as Hasura would convert the GraphQL requests into efficient SQL queries. As for option 1, a single GraphQL query could result in multiple REST API endpoints being called per query. Of course this is no different from client-side developers manually making calls to multiple endpoints to fetch the data they need and joining the information together. GraphQL simply abstracts this away from the client-side.

• edit: for version 2 it can be done without Hasura as well. We can literally copy and paste the database queries that we are using in the API endpoints to the GraphQL resolvers.

[BboyStatix]

I've created an implementation for version 1, feel free to take a look https://github.com/BboyStatix/GraphQL-API-Sunnah.com

[ahadith]

@hasankhan @Glaisher Please take a look. I think this is a valuable tool to provide. Do you think it's feasible to provide this out of a separate endpoint? In addition to our current /v1 endpoint i.e.

[hasankhan]

The reference implementation for 1) is in nodejs and as Naveed mentioned, it would result in multiple rest calls potentially. Developers can install their own proxy server if they see benefit in this.

We discussed graphql before @ahadith and our conclusion was that we want people to download the data in bulk instead of hitting our server for every user interaction. Given our API is free, it won't be feasible to scale it to the demands of all apps using the API interactively.

[BboyStatix]

@hasankhan Although it's true that it would potentially result in multiple REST calls, it wouldn't actually be all that different from clients constructing multiple REST API calls themselves.

It really depends on how the schema is designed. For example for a schema like this:

type Hadith {
  hadithNumber: String
}

type Book {
  bookNumber: String
}

type Query {
  getRandomBook: Book
  getRandomHadith: Hadith
}

Clients that want Book and Hadith when directly using the REST APIs would necessarily have to construct two REST API calls anyway. This would be no different for a GraphQL query that asks for both.

The problem of multiple calls usually only becomes an issue when one constructs types like so:

type Hadith {
  hadithNumber: String
  book: Book
}

Notice how book is not a String here, but is itself a type (which requires a REST API calls to retrieve). So any query for Hadith would result in a call to both the /hadiths endpoint as well as the /books endpoint.

The problem of nested resolvers + redundant api calls is what prompted Netflix to put a caching layer in between their GraphQL server and their REST APIs https://netflixtechblog.com/our-learnings-from-adopting-graphql-f099de39ae5f

But we don't have to worry about any of these since our schema design currently doesn't really face such a problem.

[ahadith]

Salaam alaikum

I know I don’t contribute much these days and May Allah accept from me what little I did before and forgive me for my lack of involvement.

However I did want to comment on this topic. As I stated in a meeting last year, it is important to keep things simple. Please don’t adopt graphql right now. Just make the api extremely easy to use. Regular REST is fine and the simpler the better.

I use graphql at work and I have worked with other proprietary graph decoration technologies before. I cannot emphasize enough that we should only resort to such things when we absolutely need to.

Just because we can use it and we know how to use it, does not mean we should use it. These things appear sexy but in reality there is no need and they slow down adoption rates, especially for external developers.

Netflix has a need to use graphql so that’s why they adopt it. There is a book/YouTube called “start with why”. If you can’t figure out with full conviction “why” you need a technology, then you don’t need it.

I remember one time Yahya Ibrahim said that wisdom is the ability to “make the right decision at the right time in the right place”.

Keep it simple and you will have less maintainance, less debugging and higher adoption rates. Your “why” will be met and the knowledge will spread InshAllah.

Hidayath please run such decisions past me in the future. JazakAllah khair.

Allah knows best.

Wsalaam

• Karim

On May 22, 2021, at 8:04 PM, Naveed Elahi @.***> wrote:

 @hasankhan Although it's true that it would potentially result in multiple REST calls, it wouldn't actually be all that different from clients constructing multiple REST API calls themselves.

It really depends on how the schema is designed. For example for a schema like this:

type Hadith { hadithNumber: String }

type Book { bookNumber: String }

type Query { getRandomBook: Book getRandomHadith: Hadith } Clients that want Book and Hadith when directly using the REST APIs would necessarily have to construct two REST API calls anyway. This would be no different for a GraphQL query that asks for both.

The problem of multiple calls usually only becomes an issue when one constructs types like so:

type Hadith { hadithNumber: String book: Book } Notice how book is not a String here, but is itself a type (which requires a REST API calls to retrieve). So any query for Hadith would result in a call to both the /hadiths endpoint as well as the /books endpoint.

The problem of nested resolvers is what prompted Netflix to put a caching layer in between their GraphQL server and their REST APIs https://netflixtechblog.com/our-learnings-from-adopting-graphql-f099de39ae5f

But we don't have to worry about any of these since our schema design currently doesn't really face such a problem.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.