GraphQL for Apiv3

[agjohnson]

@humitos and I discussed APIv3 more this morning. He brought up GraphQL as an option for maintaining a flexible API client side. I don't have experience using GraphQL, but it could reduce the amount of code we're maintaining, or move the code to a more maintainable spot.

A few points worth considering:

• Path of least resistance is to continue with DRF
• I don't think there are any particular problems we have with DRF. We should weigh these, if any
• The biggest design flaw with our current API pattern is that our build system treats the objects returned from the API as Django model-like objects. I have wanted our build system to be directly API driven: instead of using methods on a client side, this should be data driven from the API return. Does GraphQL get us closer?
• GraphQL is an obvious win from the client side. Our APIv2 is mostly not helpful outside our build system
• Tangent idea: build is celery driven and drop the need for the API altogether there

Any other points?

[safwanrahman]

I am not comfortable to use GraphQL if its not highly necessary.
Using Rest API would be helpful as developers are comfortable with the design, as well as good development resource.
I dont know, if there are any auto API documentation is present for GraphQL, but for DRF, there are plenty auto doc generators.

[ericholscher]

I'm generally -0. Last time I talked w/ folks about it, it didn't seem like there was strong support for the server-side in Python, and it would be locking ourselves into a much smaller ecosystem. I think just building a proper REST API with REST Framework is going to be the best path forward for most of our users, and the simplest thing that we can do.

[humitos]

Maybe worth to mention that Gitlab is moving to GraphQL: https://docs.gitlab.com/ee/api/README.html#road-to-graphql

[agjohnson]

I still agree that DRF is least resistance, but GraphQL does solve our issues with schema design, and doesn't put additional burden on us to create a useable schema -- something we haven't been great at designing thus far.

With some testing, I'm not worried about the server side implementation. There is graphene_django, the server portion of the graphql implementation for django, it looks mature.

I'm the most hesitant about the client side though. I don't think it addresses some of our problems with API client use, and querying looks much less approachable than some of the ORM-y REST clients that we could use.

Next steps could be to do a POC, but I'm probably not sold on graphql solving what problems we do have. I'd say we'd be better off enumerating these issues and coming up with patterns that address them instead. The biggest pattern we need to remove is the builder-only modeling, I think we can get this to strictly client side REST if we make some privileged REST models that have a lot more fields in the response.

[agjohnson]

I'll say we can close this. I don't think we have enough support to consider graphql as an option here.