Hello Gavin.
First of all, thanks for some nice work. Also interesting that you work for
hasura which is a very interesting tool in the postgres ecosystem.
I'm a bit assuming that the end goal is like hasura to avoid resolvers and
generate one big "sql" query for the whole graphql query. Some questions:How
are you planning on dealing with relationships? Like in hasura with
relationship metadata? Separate data model?How are you planning to handle
mutations? Classic resolvers? Calcite sql syntax is a bit more restricted than
postgres. No returning on insert, modifiable CTE, etc. So inserts from one big
json blob seems not to be feasible.
I've been tinkering with calcite for the same use case, however with sql as
transformed query output. For me, select queries work well to convert to
graphql json output but not inserts/updates because of the restrictions in
calcite sql syntax. Maybe the calcite query plan is more permissive. I have not
tried that.
/Martin
Le dimanche 2 janvier 2022, 19:04:54 UTC+1, Gavin Ray
<[email protected]> a écrit :
I wanted to officially share the project I've been putting all my spare time
into for a bit over a month. It's a tool to take Calcite data source
schemas, and
auto-generate a queryable GraphQL API from them.
- https://github.com/GavinRay97/GraphQLCalcite
(If you want to skip to "What does this do exactly?" illustrated visually,
jump
to the section: "Walkthrough of Current Progress")
For some brief background -- my dayjob is at an open-source tool that does
this
same thing (GraphQL API generation for data sources).
- https://github.com/hasura/graphql-engine
- https://hasura.io/
I'm very familiar with GraphQL, and Calcite seemed brilliant
and interesting, so I thought it could be a fun project to try to
re-write the core of Hasura's functionality with Calcite.
My hunch is that there's potentially a significant performance increase to
be
had by using Calcite for the query planning and optimization. Particularly
when
querying data from multiple data sources + joining across them is involved.
The "Roadmap" section lists a checklist of features currently implemented,
and
what's left to implement. I am not certain if all of it is possible. I am
not
certain Calcite will be faster (that would be a bummer).
Right now it only implements queries, but I want/need to implement Mutations
(insert/update/delete) and I have to figure out whether Calcite is capable
of
handling Subscriptions (live/streaming queries). I also have yet to figure
out
how to handle queries with JOIN's in them.
But so far, I've had a lot of fun learning and building this. If anyone is
interested in following along, I plan to build in public =) Also: Calcite
is a
large, complicated API. If anyone sees something stupid I'm doing, or has
advice, I would be grateful for it.
===================================================================
As a closing remark, I wanted to take a moment to thank some folks:
- Julian, for answering a bunch of dumb questions and the BOSS workshop
- Stamatis, for the Youtube videos he has on Calcite tutorials
- Vladimir Ozerov, for the QuerifyLabs blogposts about Calcite, and the
resources on Notion
- Gerard Nico, for https://datacadamia.com/db/calcite/getting_started and
https://github.com/gerardnico/calcite
- Jacques, for the conversation he had with me
