Feature: GraphQL Server

[itsezc]

Is your feature request related to a problem?

Note this is a tracking issue for GraphQL implementation.

There is a huge disconnect between a Surreal backend and a client (whether a Web App or another form of client) in terms of DX, quite frankly this has always been the case over the decades with database interfacing. Since then, we've had ORMs developed - a noteable one that changed the scene was Prisma, while this was great it still meant extra work / abstractions are needed to really extract value from it, thereafter, we've come across Hasura and Supabase as data platforms, this is where we've bridged the gap. GraphQL Codegen tools are widely available noteably Apollo GraphQL Client, GQty for JS runtimes.

To reiterate here are the issues:

• No or manual typesafety while interfacing with Surreal via client libraries
• A language / runtime might or might not be supported via client libraries
• ORMs cannot expose / provide all the functionality provided by SurrealDB (as a web database)
• An "API" layer could be built on top of Surreal (like Hasura for Postgres) but this is third-party and introduces more complexity / friction for using Surreal

Describe the solution

With a GraphQL server built-in to Surreal, we're able to provide a type-safe way interface to query our data, across any language and runtime, where live queries are concerened one could use WebSockets or WebTransport (preferred) protocols.

The GraphQL resolver needs to be powerful enough to handle all the functionality Surreal offers, since Surreal tables can both be schemaful and schemaless, this plays a huge role in what the GraphQL schema would look like.

Some queries that maybe edge cases for the implementation are:

RELATE user:tobie->write->article:surreal
	SET time.written = time::now()
;

LET $from = (SELECT users FROM company:surrealdb);
LET $devs = (SELECT * FROM user WHERE tags CONTAINS 'developer');
RELATE $from->like->$devs UNIQUE
	SET time.connected = time::now()
;

SELECT * FROM person WHERE emails.*.value ?= /gmail.com$/;

// Expressions

-- Select a nested array, and filter based on an attribute
SELECT emails[WHERE active = true] FROM person;

-- Select all 1st, 2nd, and 3rd level people who this specific person record knows, or likes, as separate outputs
SELECT ->knows->(? AS f1)->knows->(? AS f2)->(knows, likes AS e3 WHERE influencer = true)->(? AS f3) FROM person:tobie;

-- Select all person records (and their recipients), who have sent more than 5 emails
SELECT *, ->sent->email->to->person FROM person WHERE count(->sent->email) > 5;

-- Select other products purchased by people who purchased this laptop
SELECT <-purchased<-person->purchased->product FROM product:laptop;

-- Select products purchased by people in the last 3 weeks who have purchased the same products that we purchased
SELECT ->purchased->product<-purchased<-person->(purchased WHERE created_at > time::now() - 3w)->product FROM person:tobie;

The end goal should be that Surreal acts as the source of truth for your data model.

Resources:

• https://github.com/graphql-rust/juniper
• https://github.com/async-graphql/async-graphql

Alternative methods

As GraphQL is already on the Surreal Roadmap, this issue is simply to bring attention, spark discussion and for tracking of the GraphQL implementation. Would prefer if the implementation is with async-graphql as it seems to be better maintained.

SurrealDB version

N/A

Contact Details

No response

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[XChikuX]

Maybe think of using existing graphql server implementations? Strawberry takes 'THE' best graphql approach I've known in the ecosystem.

They are planning to move most of the graphql server related code interface from python -> rust using FFI.

A similar RUST based backend would be one of Puff Rs.

[novoj]

In evitaDB we solve the same problem: https://evitadb.io/documentation/use/connectors/graphql

We maintain a strict typed schema that allows us to automatically generate a GraphQL schema with all necessary information (including documentation, optional/mandatory field settings, etc.) on demand based on the actual database schema. The generated schema tries to mimic the GraphQL that would be created by application developers - so it uses the business names of entities, fields and relations. Front-end developers (consumers of the GQL API) are very positive about it and understand the content well. Try it yourself and play with the auto-completion based on the GQL schema in the editor: https://demo.evitadb.io/lab?demoSnippetRequest=eyJicmFuY2giOiJkZXYiLCJwYXRoIjoiZG9jdW1lbnRhdGlvbi91c2VyL2VuL3F1ZXJ5L3JlcXVpcmVtZW50cy9leGFtcGxlcy9mZXRjaGluZy9yZWZlcmVuY2VDb250ZW50T3JkZXIuZ3JhcGhxbCJ9

We'd love to hear what you think and maybe even help inspire makers of SurrealDB too.

[lveillard]

Hello! We are building an open source ORM for typeDB (https://github.com/Blitzapps/blitz-orm) which is conceived to accept graphQL-like queries for multiple databases.

We would love to find somebody to help us building the adapter for surrealDB, that would enable using graphQL to communicate with surrealDB.

[noverby]

Hasura v3 has been reimplemented in Rust, and the new version provides an official API for data connectors: Hasura's Native Data Connectors.
That could also be an option for providing a GraphQL Server over SurrealDB.

[itsezc]

Hasura v3 has been reimplemented in Rust, and the new version provides an official API for data connectors: Hasura's Native Data Connectors. That could also be an option for providing a GraphQL Server over SurrealDB.

While this isn't a bad idea, it would have the down side of running yet another service on top of Surreal and the PR #3266 already has a working version of the GraphQL server, which is amazing to see thanks to @RaphaelDarley