Using alias on a request that uses forwardTo("db") returns incorrect data about prisma-binding HOT 13 CLOSED

No worries,

For people that have the same issue, I managed to work through it by using graph-QL requests to forward requests to Prisma. It allowed me to simplify the API exposed to the clients, at the cost of poorer performance, as you lose the ability to select fields on the Prisma requests.

It's definitely a workaround, but it works for my use-case. I just return all fields and let yoga filter out the ones I don't care about. When this bug is closed I should be able to just forward the requests.

resolver function

export const Query = {
    async postsByUser(parent, args, ctx: Context, info) {
        return getPostsByUser(args.userId, ctx)
    },
}
export async function getPostsByUser(userId: string, ctx: Context) : Promise<[FeedPost]> {
    const selection = fs.readFileSync('postsByUser.graphql', {encoding: "utf8"});

    const variables = {author: userId};

    let response = await ctx.graphQlClient.request(selection, variables);

    return response.user.posts.map((post: Post) => postToContent(post));
}

postsByUser.graphql

query postsByUser($author: ID!) {
    user(where: {id: $author}) {
        posts (orderBy: updatedAt_DESC) {
            id
            updatedAt
            content {
                id
                updatedAt
                reviews {
                    id
                    review
                    user {
                        id
                      ....
                    }
                    updatedAt
                }
                posts {
                    author {
                        id
                    ....
                    }
                    updatedAt
                }
                userPosts: posts(first: 1, where: {author: {id: $author}}) {
                    id
                }
                userSaves: saves(first: 1, where: {user: {id: $author}}) {
                    id
                }
                userReviews: reviews(first: 1, where: {user: {id: $author}}) {
                    id
                }
                video {
                    id
                   ....
                }
                book {
                    id
                   ....
                }
            }
        }
    }
}

(If anyone has good resources on the GraphQLResolveInfo object and how it can be used to map and select fields this would be useful)

from prisma-binding.

Thanks for sharing the workaround, @RoryKelly! 🙌 That's super helpful.

We recently published a blog post with more information on the info object! 🙂 This example also contains many different uses and patterns for resolvers: https://github.com/graphcool/graphql-server-example

from prisma-binding.

from prisma-binding.

I can confirm that this appears to be fixed for me. Also, @lueurxax's workaround is way better than mine. I didn't understand how custom type resolvers work. Thanks @marktani for the link really cleared up how to define an application schema in front of the one exposed by Prisma.

from prisma-binding.

Which one is the expected result?

from prisma-binding.

I edited my original post to try and provide some clarity. Let me know if I can provide any further information.

from prisma-binding.

Just some more information. If i bypass prisma-binding and use 'graphql-request' to forward requests to prisma, I get the same behaviour. This would suggest ( to me) the the problem is in graphql-yoga.

  async feedItems(parent, args, ctx: Context, info) {
        const userId = getUserId(ctx);
        let response = await ctx.graphQlClient.request(ctx.request.body.query, ctx.request.body.variables);
        return response.feedItems;
    },

from prisma-binding.

I'm sad, it's stopper for me

from prisma-binding.

@RoryKelly @lueurxax we'll be looking into this! Sorry about the inconvenience!

from prisma-binding.

No worries,

For people that have the same issue, I managed to work through it by using graph-QL requests to forward requests to Prisma. It allowed me to simplify the API exposed to the clients, at the cost of poorer performance, as you lose the ability to select fields on the Prisma requests.

It's definitely a workaround, but it works for my use-case. I just return all fields and let yoga filter out the ones I don't care about. When this bug is closed I should be able to just forward the requests.

This is a bad attempt, because Prisma has only ten threads...

 java.util.concurrent.RejectedExecutionException: Task slick.basic.BasicBackend$DatabaseDef$$anon$2@1171acb8 rejected from slick.util.AsyncExecutor$$anon$2$$anon$1@11e0b2dc[Running, pool size = 10, active threads = 10, queued tasks = 1000, completed tasks = 1916]

from prisma-binding.

I found the better way. For query

query feed($authorId: ID!) {
  posts {
    video {
      a: posts(where: {tag: { name: "fun" } })  {
        id
      }
      b: posts(where: {tag: { name: "politics" } }) {
        id
      }
    }
  }
}

in resolvers/index.js

module.exports = Object.assign({
  Query,
  Mutation,
  AuthPayload,
}, postsResolver);

post resolver

const postResolver = {
  Video: {
    posts: async (parent, args, ctx, info) => {
      if (args.where.tag.name === 'fun') return parent.a;
      else if (args.where.property.name === 'politics') return parent.b;
    },
  },
}

You can extend this example.

prisma-bidding: renaming -> you: reverse renaming -> graphql-yoga: renaming

from prisma-binding.

Thanks for reporting @RoryKelly & @lueurxax we did a recent fix that seems to have fixed it. It's available in [email protected]. Can you give it a try? Thanks!

from prisma-binding.

Awesome, glad that cleared things up :) Thanks for confirming, I'm closing this now.

from prisma-binding.