Better handling of API-only vs DB-only vs both fields in schemas

In Vulcan, any field can be included in:

• the database
• the API
• both

But currently, that distinction is not very clear, and in fact it’s not even possible to declare a field to be made available through the API but not insertable in the database at all.

It’s all a bit messy, so here is a proposal for a better system.

1. We keep the existing schema object passed to createCollection for any field that should be included in the database. We keep the current canRead-based permission check to know whether those fields should also be made available through the API.
2. We support a new apiSchema object that contains fields that should only exist in the API, and not the database.

There are two advantages to this approach:

1. We are able to distinguish between the two kinds of fields.
2. We can simplify the syntax for API-only fields:

Before:

const schema = {
  pagePath: {
    type: String,
    optional: true,
    canRead: ["guests"],
    resolveAs: {
      typeName: "String",
      resolver: (post, args, context) => {
        return getPostPageLink(post, false);
      },
  }
}

After:

const apiSchema = {
  pagePath: {
    typeName: "String",
    resolver: () => {...},
  },
}

[SachaG]

This also means moving relation out of resolveAs, which probably makes sense anyway.

[SachaG]

Blog post WIP: https://medium.com/@sachagreif/vulcan-1-16-apischema-dbschema-7a85655dca26