jbailey2010
commented
6 years ago Hi,
As a quick-start, our goal was to provide a simple way to handle the use case that was easy to read/understand and that would work for most needs, though it might not work for all. The decision was partially due to the logical separation - SQL for one query/mutation lives inside the request mapping template for that query/mutation, rather than generating a SQL statement in the Lambda (which could get unwieldy in a large schema). It's totally fair to have to change how it goes about it to solve more complex problems.
With that being said, there's nothing stopping the SQL being executed from being fairly complex. You could combine multiple SQL statements and/or use where clauses to do a few cross-table operations at once. Specifically, it would be a totally viable alternative to have the query inside the type mapping template handle a join between the two tables, rather than having the resolver one of the type's fields.
Thanks, Jeff
Is this really the right way to store SQL queries in resolvers and then just invoke them against DB in a singular lambda?
When you have resolvers for a field within a type and you query for list of those types you will face 'N+1 queries' problem. I SQL in resolvers approach negates possibility to implement BatchInvoke resolvers which should provide concatenated fetching of data (solving N+1 queries issue) as each event in the batch will come as a separate query to lambda function.
Or is there some other way around this problem?