Prisma1: Control all project settings with the graphcool.yml file

[marktani]

• permissions
• functions
• field and type descriptions
• ...

Consider what kind of versioning concept works best for this, as well.

[auser]

Oh man... I _so_ need this (thanks for opening it). I will switch from a custom GraphQL solution to graphql if I can control permissions in git.

[marktani]

Yea this will be awesome. Have you already tried out the Graphcool CLI? https://github.com/graphcool/graphcool-cli/ You can already manage your schema in Git 🙂

[auser]

I know... I have my schema in a graphcli text file, which is why I want to do the same thing with permissions.

I actually have my permissions in a similar library format called https://github.com/charlieschwabacher/gestalt

[stephenhandley]

I think this is really crucial for projects with multiple developers. The playground is great for figuring out queries etc. but I really appreciate having the schema in source control, and having the same for permissions and functions would make development easier.

@marktani any proposals on what this implementation would look like?
Firebase/GoogleCloudFunctions has a cool approach to how functions are exported:
https://firebase.google.com/docs/functions/http-events

Serverless uses a different approach with a yaml config file
https://serverless.com/framework/docs/providers/aws/guide/functions/

I prefer the js approach because I can envision multiple permissions (probably within a given model but potentially across models) using the same query and creating those vars would make things easier.

const isAuthor = `
  query ($input_postId: ID!, $user_id: ID!) {
    SomePostExists(
      filter: {
        id: $input_postId
        author: {
          id: $user_id
        }
      }
    )
  }
`;

module.exports = {
  Post: 
    schema: `
      type Post implements Node {
        createdAt: DateTime!
        author: Author! @relation(name: "PostAuthor")
        id: ID! @isUnique
        updatedAt: DateTime!
      }
    `,
    permissions: [
      {
        description: "Anyone can read", 
        operation: "Read",
        authenticated: false
      },
      {
        description: "Authenticated users can create", 
        operation: "Create",
        authenticated: true
      },
      {
        description: "Author can update", 
        operation: "Update",
        authenticated: true,
        query: isAuthor
      },
      {
        description: "Author can delete", 
        operation: "Delete",
        authenticated: true,
        query: isAuthor
      }
    ]
  },
  Author: {}
};

From a maintainability / self documentation perspective, it might be good to make the description required i.e.

Post: {
  permissions: {
    "Anyone can read": {
      operation: "Read",
      authenticated: false
    },
    "Authenticated users can create": {
      operation: "Create",
      authenticated: true
    },
    "Author can update": {
      operation: "Update",
      authenticated: true,
      query: isAuthor
    },
    "Author can delete": {
      operation: "Delete",
      authenticated: true,
      query: isAuthor
    }
  }
}

[cameronk]

@stephenhandley agreed on your point about the required description. If that's too restrictive, the server side could check if the permissions field was an array or object and adjust accordingly as well.

[kbrandwijk]

I don't think you should re-invent the wheel. Functions are essentialy webtasks. They are implemented under the hood using Auth0 Extend (the same platform as webtask.io) where every project gets it's own webtask container, and every function is a webtask. Auth0 Extend already offers Github integration for source control, and a cli for working with local source files. This functionality should be leveraged, and integrated into the cli, so the workflow is no different than any other project that uses Auth0 Extend / webtask.io webtasks.

All project settings can easily be exported using some form of JSON.

The schema is essentialy graphql, you can already init a project based on graphql, so no big changes there (other than adding new graphql to an existing project, instead of updating the existing schema and pushing, which would work a lot better from a composition point of view).

Queries are .graphql documents. They are with apollo-client, they are with graphql-tag, and (I think) they should be in this context. Whether or not you want to declare permissions as function or query is a different discussion, in the end it's just a query now against a different GraphQL endpoint for permissions.

Attaching a permission query to a Type is already and existing mutation on the system API endpoint, just like creating a RP hook, or a SSS is.

_Setting up a project, and sticking to the GraphQL paradigms, for me would be working with a schema that is under version control, a cli that accepts delta's to the schema, a collection of functions and queries and a setup script, which is basically a set of mutations against the system API to link everything together._

[kbrandwijk]

Also, see this article on code generation and tools support when having your schema and queries in a standard format: https://dev-blog.apollodata.com/5-benefits-of-static-graphql-queries-b7fa90b0b69a. Things like intellisense when writing queries in the editor, code generation based on the schema etc.

[kbrandwijk]

Then add webpack into the mix to 'compile' all the different query files, and configuration settings into something like a 'package' that you can import in the console, or use as input to graphcool init or graphcool push

[abefetterman]

Keeping permissions in sync is getting really hard--if we could expedite permissions specifically, even just to export, it would be a big relief.

[lastmjs]

I would like to explain my use-case: I want to be able to go from a development project, with schema, permissions, and migrations, and in a continuous deployment environment deploy that development project into my production project, all from the command line.

[marktani]

Thanks @lastmjs this is exactly what this feature request is about, or rather, will enable.

[marktani]

Because it's somewhat related and a question I often hear: there's a pending PR to the CLI about initial data import using eg a JSON file 🙂

[marktani]

This feature is now in an early stage closed beta. We're still looking for a few dedicated beta testers. Please reach out to me in a PM in our Forum if you're interested in early access.

[stephenhandley]

@marktani I'd love to check it out. just a heads up, I tried to log in to the forum and PM you but oauth didn't work for google or github. will try over slack

[marktani]

After multiple iterations in the last two weeks, we're ready to take in more beta testers. Please reach out to me in the forum if you'd like to test it out yourself 🙂

[FredyC]

@marktani Where exactly in the forum? Would love to test it out. Perhaps make topic similar to beta testing schema extensions functions?

[marktani]

This is now in open beta, please refer to the thread in the Forum for more information. 🎉

[timsuchanek]

This is now available in the framework preview. You can read more about it here