Prisma 1 Forum

Feedback: Framework Preview

I’m looking into the new CLI module system, specifically https://github.com/graphcool/modules/tree/master/authentication/email-password, and had a couple questions:

  1. should code in modules be modified by the end user?
  2. In the email-password module, an EmailUser type is created, I’m assuming this is in lieu of a User type? If so, what are the best practices for adding additional fields to that type (which of course relates to my first question)

The approach I’ve taken is to modify the email-password module to replace EmailUser with User, and moved the User type and associated permissions into the root types.graphql file. Not sure if that is the best way forward in terms of updating the email-password module in the future, but it sounds like there isn’t a connection after adding so figured that was a reasonable approach in terms of augmenting the base User type.

The primary purpose of modules right now is to structure a project in your file system.

That means, all types, permissions, functions and root tokens referenced in the graphcool.yml file of a module are conceptually appended to the base graphcool.yml file.

So having these base and module graphcool.yml files:

# in modules/myModule/types.graphql
type Item implements Node {
  id: ID! @isUnique
  name: String!
  parent: Parent @relation(name: "ItemOnParent")
}
# in ./types.graphql
type Parent implements Node {
  id: ID! @isUnique
  description: String!
  itmes: [Item!]! @relation(name: "ItemOnParent")
}

is conceptually the same as having this base graphcool.yml file:

# in ./types.graphql
type Item implements Node {
  id: ID! @isUnique
  name: String!
  parent: Parent @relation(name: "ItemOnParent")
}

type Parent implements Node {
  id: ID! @isUnique
  description: String!
  itmes: [Item!]! @relation(name: "ItemOnParent")
}

The same logic applies to functions, permissions and root tokens.

We will explore further purposes and mechanisms of modules in the future. For example, it could be possible to extend upon existing types in a module, or declare dependencies between different modules. All of that is not available right now. If you have other suggestions for modules, I’d love to hear about them!

2 Likes

Thanks. That helps.

In the reference email-password module. The following is defined in the .yml file:

permissions:
  - operation: EmailUser.create
  - operation: EmailUser.read

# Permanent Auth Token / Root Tokens
rootTokens: 
  - signup
  - authenticate

By my understanding, this configuration would:

  1. Give the functions defined in the files named ‘signup.js’ and ‘authenticate.js’ access to perform any operation on any node in my project.

  2. Make creating and reading the EmailUser node open to everyone.

Is this inference correct?

permissions:
- operation: "*"

The above config would make all operations on all nodes open to everyone. How do i specify the opposite i.e. no access to anyone on any node?

  1. Not directly, but the injected root tokens can be used as a header, and if you use the fromEvent helper of graphcool-lib then that’s what happens.
  2. That’s correct - these should probably be removed from the module, I’ll do that right away.

That’s correct. This mainly exists for an easier getting started experience and to reduce verbosity.

The Graphcool permission system follows a whitelist approach. This means that nothing is allowed by default, and every operation has to be allowed explicitely. So, the answer to your question is having this permission setup in graphcool.yml:

permissions: []

So when i configure a root token for filename , the generated token is added to the header of every api request I make with fromEvent? Can i access the token from within the function?

Modules added from the Graphcool module collection will need to be adjusted in most cases. However, you can create your own modules locally or remotely and deal with them in whichever fashion you want. I can see developer teams to build up their own module collection over time, using them as building blocks to use in different projects - but in the individual projects, modules will probably evolve separately.

Please also read my previous message about modules - having a package system with dependency resolving around Graphcool Modules would be a powerful concept.

That’s exactly the intended approach - please let me know how we can communicate that better :slight_smile: I chose the verbose names (EmailUser and FacebookUser, or SendgridEmail and MailgunEmail etc), because adding two modules with the type User, or even adding one module with the type User having a type User in the root project will currently result in an error - we definitely need a better approach here, and I think it will be something along the lines of “extending types”.

Awesome work! This new feature enable us to use git to manage the services, impressive!

And we have a feedback about the query files, the hash file name is not friendly in the text editor. Although we can change the filenames by our own, but we would like to have some name conventions.
https://files.slack.com/files-pri/T0MQBS8JG-F76MJSN2Z/image.png

2 Likes

You can actually name and organise your file as you want, You can edit your graphcool.yml with the path of your file so after that you can apply any conventions you want in your project and still have something really flexible.

Here is some of my permissions.

12 am

permissions:
# Contract
- operation: Contract.create
  authenticated: true
  query: permissions/types/Contract/create.graphql
- operation: Contract.read
  authenticated: true
  query: permissions/types/Contract/read.graphql
1 Like

Make sense, I will give a try.

And if I create a new permission from the console, it is hashed filename if pull it down. hmm… maybe I will try not to do that…

Please DO NOT change a project from both the CLI and the Console - you might run into inconsistencies along the way that are not resolvable.

That would be nice, but I suspect it’s not feasible. As a multi-tenant app, GraphCool has a ton of data isolation concerns, and I imagine that they deal with many of those concerns using additional Aurora instances and other costly, per environment hooks.

So I second the idea, but I doubt it’s feasible.

Are there any additional docs or tutorials beyond this thread describing the changes?

I just started on GraphCool and love the “old” GUI system. I understand the tension between simplicity and flexibility, but without more explanation, I feel like GraphCool took a serious step back on its core mission. If I wanted to create a GraphQL server, I’d fire up Elixir and Absinthe again and make one.

My frustration is likely from a lack of understanding, but I though I’d express that feedback. I know you can’t do everything at once. Beta testing and great docs are antithetical, but a better migration explanation would likely silence chicken littles like me. :slight_smile:

3 Likes

I updated the OP with the link to our upcoming docs: https://docs-next.graph.cool/reference/basics/cli-zboghez5go

We’re currently restructuring the design & content, would love your feedback @LawJolla and everyone else :slight_smile:

1 Like

We will announce more information about the concrete migration soon - but we actually received a lot of feedback that editing code in the browser (especially for permissions & functions) is tedious and error-prone. Furthermore, organising the code locally gives way for much better integration with other systems like git and CI tools. The Console will continue to exist, to get a look at your data, use the playground and get insights into analytics and things like deployment status.

The idea is that you can reach a much better development workflow in your favorite IDE than in the browser, and we’re working towards that goal :slightly_smiling_face:

5 Likes

You’re like an incredible mind reader, developer, teacher, wizard, and good guy wrapped into one! Exactly what I hoped for. I’m going to read it all and let you know any other questions, but after spending 10 minutes with it, I feel much better! Thank you.

Update: I get it and I love it! Thank you for the great docs!

2 Likes

Feedback so far:

Spent a some time trying to debug functions from auth modules before I realized that toString wasn’t called on errors so the logs only showed “{}”. Also invoking functions locally seems to be broken? I can call it with some json but there’s no output.
The navigation in console for functions/logs is bugged, often requiring a reload before I can open the logs again after a gc deploy.

The new docs look nice, but I’m not a fan of the nav menu that doesn’t group pages by subject, how am I supposed to know if the information I’m looking for is under concepts, guides or faq?

Function debugging is important though, I don’t see documentation for it.

Edit: Auth module email-password does returns “unexpected error” instead of “Email already in use”

Edit: Will graphcool support ES2017 for functions? (async/await)

1 Like

Hi @nilan, excited to try this out, but seemingly unable to PM you due to discourse new member restrictions. My account email is the same one used here. Thanks!

1 Like

I would love a way to do per-environment secrets, like api keys and whatnot.

2 Likes

there’s a relevant discussion about this here: https://github.com/graphcool/cli/issues/249

In the docs https://docs-next.graph.cool/reference/basics/cli-zboghez5go#graphcool-init it says that I can clone an existing project doing

graphcool init --copy myProject

however, the data is not copied. Is that expected?