Skip to content
This repository has been archived by the owner on Jun 7, 2024. It is now read-only.

Adding support for GraphQL #1270

Open
rcillo opened this issue Mar 21, 2021 · 4 comments
Open

Adding support for GraphQL #1270

rcillo opened this issue Mar 21, 2021 · 4 comments

Comments

@rcillo
Copy link
Contributor

rcillo commented Mar 21, 2021

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 =)

@adyach
Copy link
Member

adyach commented Mar 22, 2021

thank you for the suggestion Ricardo! the idea is around for a long time (you know that).

I am glad you finally settled down :)

@bocytko
Copy link
Member

bocytko commented Apr 8, 2021

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?

@adyach
Copy link
Member

adyach commented Apr 9, 2021

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.

@sriganth3
Copy link

@adyach, @bocytko, @rcillo, I would like to contribute!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants