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 =)
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-typesendpoint, 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
mutationsallowing for granular modification of specific fields without requiring users to callPUT /event-typeswith 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:
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 =)