Sudograph

Sudograph is a GraphQL database for the Internet Computer.

It greatly simplifies CRUD development by providing GraphQL queries and mutations derived directly from your GraphQL schema. All you have to do is define your schema using the GraphQL SDL.

For example, if you created the following schema:

```graphql

As an example, you might define the following types in a file called schema.graphql

type BlogPost { id: String! body: String! createdat: Date! live: Boolean! numwords: Int! publishedat: Date title: String! updatedat: Date! } ```

Then Sudograph would create the following queries and mutations for you:

```graphql type Query { readBlogPost(input: ReadBlogPostInput!): [BlogPost!]! }

type Mutation { createBlogPost(input: CreateBlogPostInput!): [BlogPost!]! updateBlogPost(input: UpdateBlogPostInput!): [BlogPost!]! deleteBlogPost(input: DeleteBlogPostInput!): [BlogPost!]! initBlogPost: Boolean! } ```

There's a lot more being generated for you to get the above to work, but you're seeing the most important parts (the queries and mutations themselves).

With the generated queries/mutations above, you could start writing code like this in any of your clients:

graphql query { readBlogPost(input: { live: { eq: true } }) { id body created_at live num_words published_at title updated_at } }

The query above will return all blog posts that are "live" (have been published).

Creating a blog post would look something like this:

graphql mutation { createBlogPost(input: { id: "0" body: "This is my blog post!" created_at: "2021-03-21T05:34:31.127Z" live: false num_words: 5 published_at: null title: "My Blog Post" updated_at: "2021-03-21T05:34:31.127Z" }) { id } }

Quick Start

Sudograph is a Rust crate, and thus (for now) you must create a Rust IC canister to use it. You should generally follow the official DFINITY guidance for the Rust CDK.

If you ever want to see a concrete example of how to implement Sudograph, simply take a look at the examples directory.

Let's imagine you've created a Rust canister called graphql in a directory called graphql. In the graphql directory you should have a Cargo.toml file. You'll need to add two dependencies to it (the need to directly include serde should be removed soon). For example:

```toml [package] name = "graphql" version = "0.0.0" authors = ["Jordan Last jordan.michael.last@gmail.com"] edition = "2018"

[lib] path = "src/graphql.rs" crate-type = ["cdylib"]

[dependencies] sudograph = "0.1.0" serde = "1.0.123" ```

Next let's define our schema. In the graphql/src directory, let's add a file called schema.graphql:

```graphql

graphql/src/schema.graphql

type BlogPost { id: String! body: String! createdat: Date! live: Boolean! numwords: Int! publishedat: Date title: String! updatedat: Date! } ```

Your canister should be implemented as a Rust library crate, in this case the source code for our canister is found in graphql/src/graphql.rs. You only need to add two lines of code to this file to bootstrap your GraphQL database:

```rust // graphql/src/graphql.rs use sudograph::graphql_database;

graphql_database!("canisters/graphql/src/schema.graphql"); ```

You will also need to add a Candid file to graphql/src. Let's call it graphql.did:

```

graphql/src/graphql.did

service : { "graphqlquery": (text) -> (text) query; "graphqlmutation": (text) -> (text); } ```

Sudograph will automatically create two methods on your canister, the first is called graphql_query, which is a query method (will return quickly). The second is called graphql_mutation, which is an update method (will return more slowly). You should send all queries to graphql_query and all mutations to graphql_mutation. If you want the highest security guarantees, you can send all queries to graphql_mutation, they will simply take a few seconds to return.

If you have setup your dfx.json correctly, then you should be able to deploy your Sudograph canister. Open up a terminal in the root directory of your IC project and start up an IC replica with dfx start. Open another terminal, and from the same directory run dfx deploy.

You should now have a GraphQL database running inside of your graphql canister.

Playground

It's simple to spin up a GraphQL playground in another canister...but this isn't documented yet. Check out the examples for more information.

Custom Queries and Mutations

More information to come...this is possible, just not documented yet. Actually, check out the intermediate example in the mean time.

Current Limitations

Possibly Outdated Information

Sudograph is a GraphQL generator for the Internet Computer. It is similar to projects like Prisma, Graphback, and Hasura, though it is designed to run on and thus inherit the capabilities of the Internet Computer.

Sudograph aims to greatly simplify the hardest part of GraphQL development, which is the actual implementation of the resolvers. From a types-only GraphQL schema written in the GraphQL SDL, Sudograph will generate a far more capable CRUD schema along with the implementation of its resolvers.

Basically, a GraphQL schema goes in and a generated CRUD backend comes out. This will create a highly declarative developer experience, and will free you as a developer to think more in terms of the shapes of the data of the systems you create, and to pass the implementation of the more capable schema and resolvers on to the generator.

As Sudograph will inherit the capabilities of the Internet Computer, its aim is to become the simplest, most flexible, secure, and scalable way to use GraphQL. It also aims to be the best way to build CRUD apps on the Internet Computer.

These are lofty goals, and there is a long road ahead.

Roadmap

This roadmap should give you an idea of what Sudograph is currently capable of, and where it is headed. Keep in mind that the roadmap is a rough sketch and subject to change.

Database

The Internet Computer does not have an efficient and scalable relational data store yet. A prerequisite to this project's success may be to create one of these data stores.

Query

Arbitrary-depth joins in selection sets, all basic relation types including one-to-one, one-to-many, many-to-one, and many-to-many.

Mutation

Single level of scalar inputs per entity and connecting or disconnecting relations by id only, arbitrary-depth joins in selection sets, same selection set capabilities as queries.

Selection Sets

Possible Future Capabilities