GraphQL has been around for quite a while now, and it has been a hot topic as a possible candidate for the next generation of data fetching.
I hav...
For further actions, you may consider blocking this person and/or reporting abuse
I made an hybrid API and used both REST and GraphQL at the same time. I make fetch queries and mutations through REST and then use only GraphQL Subscriptions from GraphQL. I could use pure WebSockets too, but I liked to make typeDefs and Apollo's client side libs were easy to use.
Interesting! How do you like it? Do you in hindsight wish you did anything different?
So far decisions I made feels quite good actually.
7 month later, has there been changes in this approach? Maybe you have some advice?
With AppSync serverless gql subscriptions are simple and seamless!
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 :)
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 :)
Hey, that is really cool! Thank you for sharing. If the need arises for subscriptions at scale I know where to look :).
Thanks for the post Peter, if you want, you can use (SOFA)[medium.com/the-guild/sofa-the-best...] in order to expose your graphql-backend as a REST API.
You can also checkout the newly release Apollo Federation for graphql Schema stitching!
Apollo Federation solves the gateway problem - apollographql.com/docs/apollo-serv...
Maybe! I like the approach a lot more than stitching for sure. I am a little afraid to try it though due to my history with stitching.
I don't think you should be. Federation is meant to replace it, as stiching has become deprecated now.
I will follow the discussion for sure, and see how people like it! Might just join in a little late on this one if it turns out to be great.
Good one. Been there 10 years ago, same architecture, different jargons: domain query language, stiched query,