Reconsider default GraphQL APIs?

[SachaG]

This is more of a long-term thing, but it might be worth reconsidering the signature of Vulcan's internal GraphQL APIs (i.e. list, single, total, new, edit, remove, and now upsert).

For example, is there some kind of "standard" GraphQL way to define these functions? Could we make them compatible with Graphcool or other GraphQL back-ends? How do other back-ends handle things like pagination and deleting fields?

One of Vulcan's strengths is that it's full-stack, meaning that we could change this transparently for the end users (just change the default resolvers and withList at the same time, for example). So I thought it was worth it opening up a discussion, even if we end up not changing anything.

[SachaG]

For example this is what Prisma's generated mutations schema looks like:

https://gist.github.com/gc-codesnippets/f302c104f2806f9e13f41d909e07d82d#file-prisma-graphql-L25-L28

[justinr1234]

https://www.graph.cool/docs/reference/graphql-api/mutation-api-ol0yuoz6go/

[SachaG]

One thing that's not super clear for me with their update mutation is how you delete fields. I borrowed the set/unset thing from Mongo for Vulcan because it makes it obvious which fields are being deleted vs being just set to empty values.

[justinr1234]

Likely just a wholesale replacement of document

[SachaG]

Prisma's generated schema: https://gist.github.com/gc-codesnippets/fed6ffe8c34a06b1682cc227dfcfd549

[sedubois]

I just heard about VulcanJS so apologies if this is a silly question, but is it possible to use Vulcan on top of one's own GraphQL API generated using Prisma? I would love to give it a try if that's possible.

[SachaG]

At this time not really*, but we're discussing how to make that possible.

• well technically you could, but you'd lose most of the advantages of using Vulcan in the first place.

[sedubois]

🙏😊 I think it would be a huge feature, would allow actually benefiting from GraphQL’s universal nature.

[sorenbs]

Would be super cool to use something like graphql-binding to blend in external GraphQL APIs into the Vulcan API.

At Prisma we are currently working with various database vendors to create official specifications for GraphQL API flavours for different kinds of databases including relational, document, search, k/v, and graph databases.

Prismas current API is the foundation for the specification for relational databases.

Example

The SDL schema:

type User {
  id: ID! @unique
  name: String!
}

type Movie {
  id: ID! @unique
  createdAt: DateTime!
  user: User
  userId: ID
  name: String
  year: String
  review: String
}

generates the following API:

• schema
• live endpoint

API Spec

The full schema spec is available at https://github.com/graphcool/prisma/issues/1340

One of the most powerful features in the relational spec is nested mutations. It is documented at https://github.com/graphcool/prisma/issues/1280

As Vulcan is based on Mongo, you should probably not adopt the current relational Prisma API Spec directly. We will start fledging out the mongo spec soon in https://github.com/graphcool/prisma/issues/1643. It would be great to collaborate on this!

Questions

Sascha asked how Prisma handles setting a field to null versus setting it to the empty value. At least that's how I interpreted the question :-D

We use the null value (introduced in October 2016) to mean set the value to null. As Vulcan is based on Mongo you actually have 3 different options:

1. set the field to the empty value (ie "" for a string)
2. set the field to null (ie null)
3. remove the field

I'm not entirely sure the distinction between 2 and 3 is important enough to justify a more complex API than just using the null value to mean one of the two.

[SachaG]

Yes I think we can decide that setting the field to null means removing it, it's a reasonable convention and wouldn't require a big change anyway.

I guess I just need to set aside half a day to make a proof-of-concept Vulcan+Prisma app now. Unless somebody else wants to work on this?

[sorenbs]

That's great!

I'll get the spec for Prismas MongoDB API going and ask around for anyone interested in contributing to Vulcan/Prisma integration.

@SachaG maybe you can give a few pointers to how someone would go about implementing that?

[SachaG]

Sure, out of the box Vulcan has a set of three default resolvers (single, list, total) and three default mutations (new, edit, remove) on the server; and five corresponding HoCs on the client.

So step 1 would be changing all these to work with the same API as Prisma.

Regarding the Mongo thing though, I think we want the GraphQL API to be database-agnostic, right? So the fact that Vulcan uses Mongo currently shouldn't really matter as far as this issue is concerned?

[SachaG]

Also is there a Graphcool project I could start playing with and entering data into? Or is there a way to open that endpoint in the Graphcool console somehow?