Anyone have pros/cons for using AppSync vs Apollo for a graphql API? I'm more familiar with Apollo but my main concern with using it right now is that all the examples i've seen involve creating one "fat" lambda for the entire API and perhaps this may not scale well in the long run as the API grows in size. This also seems like an anti pattern in the serverless world. Does using AppSync instead work as a solution to this? From past experience, the approach we took was to deploy several Apollo servers as microservices and combine them using schema stitching and eventually Apollo Federation into one large data graph that acted as an API gateway. This, to me, seems like it would be more conducive to serverless style development. Has anyone tried to implement a set up like this or is there a better approach? Thanks in advance for any help!

me frank and jay were just going back and forth on this an hour ago haha

hahah I guess I picked the right time to ask!

Apollo is definitely more mature and has some really nice bells and whistles. But for the basic stuff AppSync is there and is definitely "more serverless" - here are my issues with it: • Updating schema through cdk is very slow which is painful during development since you tweak schemas a lot • With apollo you likely are using dataloader to batch queries to address n+1 issue. AppSync also supports batching but it arbitrarily limits it to a batch-size of 5. This makes no sense to me and there is a long github issue of people complaining: https://github.com/aws/aws-appsync-community/issues/51#issuecomment-1000477825

I've been playing around with appsync and their VTL templates recently... really curious how far I can get on a clone of my works app with using 0 lambdas 😅 Havent used apollo or graphql much at all but appsync is really really cool from what I have used so far

@Garret Harp IMO the choice to use VTL was a bad one. not a fan at all. I just use multiple Lambda data sources, and use Lambda + Node.js to handle resolvers

just a sidenote on "fatness": You can always just deploy more than one apollo server.

@Sam Hulick what did you not like about it? It's interesting way to write for sure but I think it is pretty nice to have just a direct connection but havent played around much to understand why it might fully be annoying to work with

I also avoid VTL because I prefer keeping my API decoupled with the underlying database. I create domain layers that my APIs call into - this provides a refactor blast zone so that changes don't have to effect everything

@Garret Harp I just found the syntax to be clunky, and difficult to “debug” when issues arise

Ignore the ricardo guy responding to me lol, he works on AppSync and misunderstood my point and wrote paragraphs dismissing it

hmm I see. Yeah, I'm really weary of going with AppSync for the reasons you mentioned, @thdxr, although I do love the integration with SST! @Sam Hulick do you mean that you just use regular RESTful lambdas for different data sources and then have one lambda acting as a thin GraphQL layer to expose those data sources? @Derek Kershner When you say deploy more than one Apollo Server, does that mean having multiple endpoints for different parts of the data graph versus having a single endpoint to access the whole schema?

@Aman Saran correct, we just have different AppSync data sources which are hooked up to Lambda functions. Lambda gets the GraphQL request and is in charge of processing it and returning a result

@Aman Saran, correct, split on some kind of context seam that makes sense where you would never want subresolvers. You could also, in theory, stitch them back together with a federated apollo server as well, but that would definitely be missing a lot of the upsides being searched for.

Both are definitely interesting approaches. I think I may play around with AppSync and see how it is first and if I decide it's not a good fit, then I'll switch to Apollo. Also, thank you to everyone who replied to this thread with their thoughts and suggestions! This was super helpful!! 🙂

AppSync can get expensive in large scale too, with Apollo on Lambda it never gets as expensive,

Which is no problem if you're charging your customers appropriately

I feel like pricing is never really the main concern but rather DX which IMO appsync will 100% be better

yeah, agreed. I’ve never understood people’s concerns about price. just price your product correctly and it’s a non-issue

I’m using lots of lambda resolvers with appsync. It just sucks that there’s no local dev environment. Someone opened a PR to spin one up using apollo but the PR was closed 😩 I’m not using VTL at all

@Mischa Spiegelmock my local dev envionment, you mean something like Apollo’s playground?

I’ve never used apollo so I don’t know. It would be nice to test the graphQL API without having to deploy it

I think SST has you covered in either case @Mischa Spiegelmock.

i'm trying to migrate my app in stages to SST. it has a local graphql server?

We don't do much "locally" besides executing your functions. When they're tied to appsync you hit the real appsync URL but the resolvers are executed locally

oh neat. will be excited to try that when i'm able to use SST for bundling

but its "like" local development, which is I think what he is getting at.

cool

ask them about batching lol

@thdxr means to say "anything they improve will improve SST as well, most likely"

ok i'll ask lol

Limited resources as in her team is too busy?

@thdxr what's the batch limit exactly? she doesn't understand

It's this issue: https://github.com/aws/aws-appsync-community/issues/51 You can specify that a lambda resolver should be batch invoked - so if it needs to be called 5 times to resolve a query it's instead just called once with an array of the values so you can do an efficient read

ok

Thanks! How are you talking to her btw - I always find it impossible to get a hold of any aws team members

lol

@Aman Saran what did you end up doing? I am also struggling with this to decide how to go about the fat ambda issue, The approach in docs is also the "fat" lambda

They fixed the issue I linked in here. The reason we went with the fat lambda for our gql stack is that we were able to get a better day to day DX with a fat lambda

We went with the "fat lambda" approach. After speaking with former colleagues who work at a large multinational company, they told me they've been running the entire Apollo server in a one lambda with no issues

Thanks a lot, @Aman Saran, Really grateful for the help I have been reading so much on the internet but wasn't confident enough. So this is the example, right?