You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 7, 2024. It is now read-only.
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 =)
The text was updated successfully, but these errors were encountered:
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.
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 callPUT /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:
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 =)
The text was updated successfully, but these errors were encountered: