Towards Schemas end to end (without Effect)
Towards Schemas end to end (without Effect)
The dashboard knows the query type, but the output of a query is 'any'. Imagine that we document what is the type of output. The UI dev will be happier. And make it discoverable based on runs. Like how schema is generated now the from existing data in the db.
It would feel good to have some benefits of graphql (a contract between backend and front-end).
Frontend devs love to consume Graphql because the schema of the data is very clear.
So I am thinking two about two concepts:
- A. schemas for functions output (with errors and lifecycle status as data) like in go/elixir
- B. resolvers: for query implementation, so that we can say, it's more technical, it's using Promises, and it's ok to be more difficult.
A. is for product design days and UI
B. is for backend engineering days.
That's the DX i am thinking I would like to see.
4 Replies
The return type of your query functions should not be "any," do you have a code sample @Chakib Ouhajjou?
Are you looking for runtime enforcement and a centralized set of types to define it? I think we're on the same page (some of these features are coming soon) but I'm not sure I understand what you're asking for vs how Convex works today.
Sorry for the confusion, I am mostly wrong.
You are correct the return values have types. I guess I am looking to 'enforce' the schema from my frontend effort. Having a contract Backend/FrontEnd contract with types/schemas is I guess what I need to build frontend first, and use data mocks.
I guess it's Schema first vs Code first is what they call this - I am trying to do Schema first.
We're adding return value validators soon (see the open source repo or the last alpha release for a preview!) for runtime enforcement, which will make it possible to generate client bindings in the future; especially useful for languages other than TypeScript like Python or Rust.
This "API schema" is still defined in the functions though, this won't require writing an API in one file and implementing it in another — but that's absolutely an approach that can be supported. But most users have asked for this alongside implementations so far. If it can be avoided most devs don't want to go back to header files 😉
Very cool ! 👍