:eyes: Anyone using AppSync here? - Do you have 1 ...
# sst
f
👀 Anyone using AppSync here? • Do you have 1 Lambda per query? Or 1 Lambda handling a bunch of queries? • Are you using all Lambda resolvers, or a mix of DynamoDB/RDS and Lambda resolvers? Trying to create an
sst.AppSync
construct, and I’m curious if ppl have a lot of resolvers and if there’s an easier way to define them, ie. something like the Api routes make sense?
Copy code
resolvers: {
  'query listNotes' : 'src/listNotes.main',
  'query getNote'   : 'src/getNote.main',
  'mutation addNote': 'src/addNote.main',
}
p
we are using both patterns you described: • lambda per query • one lambda with a giant switch statement It basically depends on the use case, I like both patterns. Especially when having code or libraries that are reused, the “multi query handler” is quite useful. All resolvers are set up like this:
Copy code
baseDS.createResolver({
      typeName: 'Query',
      fieldName: 'account',
      requestMappingTemplate: appsync.MappingTemplate.lambdaRequest(),
      responseMappingTemplate: appsync.MappingTemplate.lambdaResult(),
    });
We had a bunch of VTL dynamodb resolvers, but we are migrating to RDS (postgres) and we are not using VTL with these anymore.
For the ultimate developer experience: we are using graphql codegen to generate typescript types from graphql.schema so the lambda handlers are fully typed with the arguments + response types for appsync. that only works without vtl of course, but it is AWESOME.
m
We are using the lambda resolver with switch statement method. Not using any VTL at the moment.
m
I would love a best practise guide about this
d
• 1 Lambda for a bunch of queries • Dynamo resolvers