Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] REST API output on Hasura v3 #10475

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

ecthiender
Copy link
Member

@ecthiender ecthiender commented Jul 24, 2024

Description

This is our new proposal of auto-generating REST API output in Hasura v3.

Rendered

@ecthiender ecthiender requested a review from a team as a code owner July 24, 2024 16:34
@ecthiender ecthiender added k/rfc RFC for a new feature / process auto-update-auto-merge labels Aug 29, 2024

Hasura will also generate an OpenAPI schema for complex filtering on nested types. As a result, any
auto-generated client would get full auto-complete and type-checking on any nested filtering
clauses. Check out <https://github.com/hasura/json-api-experiments> to see this in action.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must have missed that we're able to get this working in a well-typed fashion. Nice!


# OpenDD config

For the first iteration, to keep things simple, we are not introducing any OpenDD configuration. Any
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this because we're keeping scope slim, but I am concerned about breakages - ie, if by default we expose all models as a JSON:API endpoint, and then we later make each model opt-in, does that constitute a breaking change?

Do we solve this by only offering this feature on a strictly "this is experimental" basis?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. It will be a breaking change, and I guess we would have to incorporate this via Compatibility Date. But let me see if we can do anything better here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh of course. If we just say "everything before this date gets all models, everything after gets specific ones", we're fine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm thinking we can introduce a date after which it is still all models but user gets a warning. And after a second date, we switch to specific ones. Does this make sense?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sounds ideal!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes this works, thanks!

Co-authored-by: Daniel Harvey <danieljamesharvey@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants