In this case I’d suggest using the concurrency feature of bluebird to limit the number of concurrent promises

Hmm...never used bluebird, do you have a resource on accomplishing this? I am still new to Promises

Sure, I’ve created an example for you: https://gist.github.com/schickling/7105a55cb5bcb9fd479d193d4d0ab605

Thanks! Much appreciated.

just curious

is the db for graph.cool mongo or postgres?

🙂

we use AWS Aurora as our db 🙂

using the simple api - is the current user id in the context somehow with a special keyword - or would i have to pass it in as a param?

I saw in the rules examples that you can just use a userId variable

can you do the same with a regular query?

Another question. Is there an example on how to set permission rules for a create operation? (like create an item if item.authorId == $userId, with item.author set as a relationship to user)

@francois I believe that is on the roadmap.

Yup @thisismissem. It is a beta feature. Not sure if #general is the right channel.

@schickling you know what would be cool? if your tutorials where set up as monorepos and you had a track showing how you did it! Well, that is why it would be cool for me. For you, it would be cool because you could remove friction for people learning (who we are assuming we would like to become customers). A new yarn install on every checkout totally does not leverage the fact that yarn is set up to speed up your subsequent installs. So you could do something like just do yarn add whatever additional files are necessary in the next section. I just waited for ten minutes on the 01 yarn install. Then i have to do it each time. I wonder how that would work? You could even have it set up for each track in case some idiot(like me) my consider going through each one...

@schickling now that i'm thinking about it, branches on a github repo would be one way to avoid yarn install everytime. Not a monorepo though...

Hello guys, i have a question related to error handling. In https://www.graph.cool/docs/reference/simple-api/errors you mention "path", i'm wondring why it's an Array instead of simple value.

{
  "data": {
    "updatePost": null
  },
  "errors": [
    {
      "locations": [
        {
          "line": 11,
          "column": 3
        }
      ],
      "path": [
        "updatePost"
      ],
      "code": <error-code>,
      "message": "'Post' has no item with id 'wrong-id'",
      "requestId": <request-id>
    }
  ]
}

@samz It is possible for an error to occur deep in a query, and then the entire path is returned as an array. For mutations it is obviously less useful, but even then the query for a mutation could return an error.

@monkeybonkey For regular queries you have to pass it in as a regular variable. The GraphQL spec requires that all variables be listed at the top and that all listed variables are used. We could introduce a special userId variable, but it would break existing tooling and not be spec compliant. We do this for query permissions as you are always writing the queries in the Console, and we are in charge of executing the query - not your application.

Hi @francois I’ll send you a direct message. It’s fine to ask beta related questions here. If it becomes too much we’ll create a separate channel

@thisismissem We are currently testing subscriptions and Query Permissions in beta. Let me know if you would be interested in testing this as well 🙂

@sorenbs maybe! At the moment I lack any real-world applications to use graph.cool with

Oh, that’s sad. We sometime speak with companies looking to hire a contractor to build stuff on Graphcool. Should we keep you in mind next time?

hey @sorenbs any examples of production apps I could check out that are built on graphcool?

Hey @nicoslepicos we are preparing a public list. In the meantime, anything in particular you are interested in, maybe I can hook you up with someone who can tell you about their experience. If you are more interested in technical implementation our console is open source and a pretty big project.

ah, awesome, ok I'll take a look at the console as a starting point - thanks @sorenbs

new permission system is ✨

been digging into the postgres permission system with postgrest.com, this seems to cover pretty much everything that the postgres permission system is capable of 🙂

Hey @Matt Mueller (Prisma Client PM)! Glad you like our new permission system! Please let me know if you have any pointers or feedback how to make it more powerful/easy.

Hey guys! How does your AWS Lambda workflow look like? Anybody using Apex?