61

When using AWS AppSync with lambda data sources you can encounter N+1 query problem.

Basically when you have individual field resolver on your type and your query returns an array of those types you field resolver lambda will be called N times.

AWS introduces BatchInvoking lambdas in resolvers to combat this problem. Here you can read more about the problem and their solution: https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-lambda-resolvers.html#advanced-use-case-batching

However, their solution is not working. BatchInvoking lambdas are limited to only 5 events (this is not stated in documentation). It is a slight improvement to the N+1 problem (it makes it N/5+1), but I think it is not enough as more complex queries tend to execute for a very long time and require more lambda invocations.

So my question is how do you deal with this problem? Is there any better solution to this?

Nmk
  • 1,281
  • 2
  • 14
  • 25
AlpacaGoesCrazy
  • 796
  • 8
  • 14
  • 10
    I work on AWS AppSync team. I will be happy to pass this on as a feature request to customize the batch size for batch invoke. – Karthik Aug 10 '18 at 17:10
  • This would be very helpful and will actually solve this problem in the best possible way, thank you! – AlpacaGoesCrazy Aug 13 '18 at 09:05
  • I hit the same problem. This is serious problem, because we have hundreds of resources with subresources, which are resolved in one betched call to external API (with current N/5 it would be ineffective to make such an amount of API calls). Too bad that it is NOT documented. – DavidC Aug 14 '18 at 15:36
  • 5
    Half a year passed and there's no workaround yet. @Karthik, is it in the roadmap? – Nikola Petkanski Mar 12 '19 at 16:29
  • Any updates on this topic? We're looking for a solid GraphQL solution which should serve as a facet for dozens of REST services. Currently, this limitation doesn't seem to be a blocker on the initial stages but we don't want to face it in the middle of the way. – Arthur Gurov Aug 01 '19 at 10:00
  • 3
    @ArthurGurov I think it is better to go with Apollo GraphQL for now, you can host apollo server on a conventional aws ec2 instance or even on aws lambda if you prefer – AlpacaGoesCrazy Aug 07 '19 at 13:46
  • 1
    Any update on this problem? It is a serious limitation – niqui May 05 '20 at 21:00
  • 2
    Just tested this again with a clean setup and this undocumented and unchangeable behaviour is still the case. You would expect AWS to at least document this behaviour after 3 years of not adding it, but no. – Bram Jun 23 '21 at 14:57
  • Have you tried adding PerResolver caching? https://docs.aws.amazon.com/appsync/latest/devguide/enabling-caching.html – RoboKozo Jul 07 '21 at 18:37
  • @RoboKozo For request to be cached for later use it should fire at least once successfully. However problem in question in my case caused my request to time out. – AlpacaGoesCrazy Jul 27 '21 at 12:38
  • That's interesting. I know they offer Full Request caching where what you describe would be my expectation. For Resolver based caching I would expect each individual resolver would be cached even if the overall response fails for some other reason. – RoboKozo Jul 27 '21 at 16:49
  • Is there perhaps a jira or other issue/case number so people can at least check the status of this at any time in the future? – Dennis Jaheruddin Aug 05 '21 at 21:34

3 Answers3

3

Until Appsync fixes their issues, we are using an Apollo server as a gateway in ECS to stitch the schemas made with Prisma and invokes lambdas directly where our logic is set.

For your request you can follow up on the feature request in their GitHub repo, which sadly does not have a lot of progress. https://github.com/aws/aws-appsync-community/issues/51

Lucasz
  • 1,150
  • 9
  • 19
3

AWS just made batching size for AWS AppSync Lambda resolvers configurable (official blog post).

Now developers can easily enable batching on their Direct Lambda resolvers, and configure the maximum batching size (up to 2000 instead of the previous fixed default of 5) for their resolver. The same functionality is available for AppSync pipeline functions that use a Lambda function data source.

The official documentation has been updated with:

You can enable batching for your Direct Lambda Resolver by configuring the maxBatchSize on your resolver. When maxBatchSize is set to a value greater than 0 for a Direct Lambda resolver, AWS AppSync sends requests in batches to your Lambda function in sizes up to maxBatchSize.

Setting maxBatchSize to 0 on a Direct Lambda resolver turns off batching.

Using the console

You can configure it via AWS console for each resolver:

AWS AppSync Lambda resolvers configurable batching size in console

Using CLI

Using --max-batch-size parameter in AWS CLI V2 or AWS CLI V1

aws appsync update-resolver \
  --api-id <value> \
  --type-name <value> \
  --field-name <value> \
  --max-batch-size <value>

Using CloudFormation

The property name is MaxBatchSize and it can be set on AWS::AppSync::Resolver and AWS::AppSync::FunctionConfiguration.

MyResolver:
  Type: AWS::AppSync::Resolver
  Properties:
    ApiId: MyApiId
    DataSourceName: MyDataSourceName
    TypeName: MyTypeName
    FieldName: MyFieldName
    MaxBatchSize: 100

The official CloudFormation doc update will be out this week

Yves M.
  • 29,855
  • 23
  • 108
  • 144
-1

AppSync released this enhancement today: https://aws.amazon.com/blogs/mobile/introducing-configurable-batching-size-for-aws-appsync-lambda-resolvers/

Nicholas DeJaco
  • 1
  • Please don't post links as they can be deleted, copy the information from the link as well and provide the part of the answer they are looking for – Derek Lawrence Jan 06 '22 at 23:04
  • 1
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jan 06 '22 at 23:04