It sure looks like cool tech, but I don't really understand how you implement non-trivial resolvers by reading the docs 🤔. I'll have to play with it sometime!
Neat. Do you have experience with such use cases? Would love to read something more in-depth.
For example; on the top of my head when I'm looking at the lambda resolvers, I am thinking about the dataloader-situation. We make heavy use of dataloaders, which are placed in our graphql context. Those mutable objects can't really be transferred to a lambda function right? How would you go about solving that with AppSync? Would that be another layer of lambdas with batching logic, could something like that even work 😕?
All those things from medium article are true, but most of the limits are reasonable IMO :) I've never used dataloaders, but it's an interesting topic to investigate. Our team uses AppSync heavily, it's possible to create very non-trivial resolvers using VTL only, we are using it heavily with EalsticSearch and DynamoDB.
We are even using AppSync with Redshift (via Lambda), and there we use subscriptions to serve clients with long taking queries - this was the point of my comment, you surely CAN go 100% serverless with GQL subscription and Lambdas :)
Yeah there are definitely still limitations. Not sure how much it has evolved since the update on the article as we just got started with it couple of months ago. It has been so far sufficient for our needs, but yeah data loader sounds like a lot more trickier problem, I'v yet to try to solve that.
Of course, every serverless service has its limitations, but if used wisely it can cover most of modern apps scenarios IMO, and then if your case is complex and needs fine-tuning, then maybe serverless is not for you and you should use something else :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It sure looks like cool tech, but I don't really understand how you implement non-trivial resolvers by reading the docs 🤔. I'll have to play with it sometime!
You do it with Lambda function.
Neat. Do you have experience with such use cases? Would love to read something more in-depth.
For example; on the top of my head when I'm looking at the lambda resolvers, I am thinking about the dataloader-situation. We make heavy use of dataloaders, which are placed in our graphql context. Those mutable objects can't really be transferred to a lambda function right? How would you go about solving that with AppSync? Would that be another layer of lambdas with batching logic, could something like that even work 😕?
Edit: found medium.com/@dadc/aws-appsync-the-u... , good read! I wonder if any new updates has changed the scene...
All those things from medium article are true, but most of the limits are reasonable IMO :) I've never used dataloaders, but it's an interesting topic to investigate. Our team uses AppSync heavily, it's possible to create very non-trivial resolvers using VTL only, we are using it heavily with EalsticSearch and DynamoDB.
We are even using AppSync with Redshift (via Lambda), and there we use subscriptions to serve clients with long taking queries - this was the point of my comment, you surely CAN go 100% serverless with GQL subscription and Lambdas :)
Hey, that is really cool! Thank you for sharing. If the need arises for subscriptions at scale I know where to look :).
Yeah there are definitely still limitations. Not sure how much it has evolved since the update on the article as we just got started with it couple of months ago. It has been so far sufficient for our needs, but yeah data loader sounds like a lot more trickier problem, I'v yet to try to solve that.
Of course, every serverless service has its limitations, but if used wisely it can cover most of modern apps scenarios IMO, and then if your case is complex and needs fine-tuning, then maybe serverless is not for you and you should use something else :)