Adding support for GraphQL
rcillo opened this issue · comments
Nakadi API has an endpoint for listing event types https://nakadi.io/manual.html#/event-types_get which returns all the event types with all their fields in a single unpaginated list. This includes schema definitions and authorization fields which can be significant in size.
Some client might be interested in only a few fields, such as the name only, for example.
Instead of adding pagination to the existing GET /event-types endpoint, would the maintainers be interested in adding support for GraphQL to allow clients to request only the fields they need in a paginated endpoint? This could reduce latency and bandwidth utilization besides modernizing the API approach. I believe GraphQL has been successfully used at Zalando before.
Changing how data is stored in the database (single jsonb vs columns) could be discussed in a different ticket for further optimization.
GraphQL could also be later used for mutations allowing for granular modification of specific fields without requiring users to call PUT /event-types with the entire object, risking undesirable changes or having to extend the API with specific endpoints for changing each field of the event type.
A few downsides would include dealing with the obvious questions that would follow up and some other things, such as:
- please add support for reading events with GraphQL where I can specify the fields I need
- can I post events using GraphQL?
- are subscriptions also exposed via GraphQL?
- there a nasty bug in GraphQL that breaks everything
- this project has some history of using Netflix software that is just poorly written or abandoned (exhibitor and hystrix, for example)
This would also require a new documentation parallel to the Rest API which would slowly fade into obsolescence.
To be honest, I finished unpacking my things and wanted to reach out. Also, people really like GraphQL in some other companies.
Cheers =)
thank you for the suggestion Ricardo! the idea is around for a long time (you know that).
I am glad you finally settled down :)
Some client might be interested in only a few fields, such as the name only, for example.
Why introduce GraphQL when you can support partial responses for your REST API?
the idea is around for a long time
Is the concrete idea to add GraphQL APIs for the event type management part of Nakadi API?
Is the concrete idea to add GraphQL APIs for the event type management part of Nakadi API?
the idea is to add partial responses (GraphQL is one way to achieve it, but it looks indeed overwhelming in Nakadi project). the costumers retrieve megabytes of event types definitions when they need only a single json string field of specific event type.
