https://serverless-stack.com/ logo
#help
Title
# help
a

Aman Saran

01/03/2022, 10:27 PM
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!
t

thdxr

01/03/2022, 10:27 PM
me frank and jay were just going back and forth on this an hour ago haha
a

Aman Saran

01/03/2022, 10:27 PM
hahah I guess I picked the right time to ask!
t

thdxr

01/03/2022, 10:29 PM
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
One other thing is subscription support working out of the box is cool, but triggering a serverside update is needlessly complicated
If you value the downsides of fat lambda + really want to be all in on a managed service it's maybe worth dealing with these issues. I'm pretty split personally
g

Garret Harp

01/03/2022, 10:33 PM
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
s

Sam Hulick

01/03/2022, 10:43 PM
@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
d

Derek Kershner

01/03/2022, 10:44 PM
just a sidenote on "fatness": You can always just deploy more than one apollo server.
one more difference to point out as well: AppSync is incredibly expensive compared to HTTP ApiGateway. (should your needs not include things that dont exist there)
g

Garret Harp

01/03/2022, 10:46 PM
@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
t

thdxr

01/03/2022, 10:47 PM
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
Also provides a central place to control the shape of my data
s

Sam Hulick

01/03/2022, 10:48 PM
@Garret Harp I just found the syntax to be clunky, and difficult to “debug” when issues arise
like, of all the languages out there, why did they choose VTL?
t

thdxr

01/03/2022, 10:50 PM
Ignore the ricardo guy responding to me lol, he works on AppSync and misunderstood my point and wrote paragraphs dismissing it
That said this is just an opinion - you can find VTL suits you rwell
a

Aman Saran

01/03/2022, 11:09 PM
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?
s

Sam Hulick

01/03/2022, 11:11 PM
@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
it’s been working great so far
no problems with AppSync. and subscriptions are super easy
d

Derek Kershner

01/03/2022, 11:13 PM
@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.
a

Aman Saran

01/03/2022, 11:24 PM
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!! 🙂
h

Hamed Mamdoohi

01/04/2022, 1:48 AM
AppSync can get expensive in large scale too, with Apollo on Lambda it never gets as expensive,
s

Sam Hulick

01/04/2022, 1:49 AM
Which is no problem if you're charging your customers appropriately
g

Garret Harp

01/04/2022, 2:04 AM
I feel like pricing is never really the main concern but rather DX which IMO appsync will 100% be better
and its only a $3 difference per million requests so its not even that big of a tradeoff
s

Sam Hulick

01/04/2022, 2:06 AM
yeah, agreed. I’ve never understood people’s concerns about price. just price your product correctly and it’s a non-issue
m

Mischa Spiegelmock

01/04/2022, 8:17 AM
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
f

Frank

01/04/2022, 8:39 AM
@Mischa Spiegelmock my local dev envionment, you mean something like Apollo’s playground?
m

Mischa Spiegelmock

01/04/2022, 8:58 AM
I’ve never used apollo so I don’t know. It would be nice to test the graphQL API without having to deploy it
d

Derek Kershner

01/04/2022, 3:43 PM
I think SST has you covered in either case @Mischa Spiegelmock.
m

Mischa Spiegelmock

01/04/2022, 3:44 PM
i'm trying to migrate my app in stages to SST. it has a local graphql server?
t

thdxr

01/04/2022, 3:45 PM
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
m

Mischa Spiegelmock

01/04/2022, 3:45 PM
oh neat. will be excited to try that when i'm able to use SST for bundling
d

Derek Kershner

01/04/2022, 3:45 PM
but its "like" local development, which is I think what he is getting at.
and local graphql server isnt quite right, but the whole API executes, and it can be GQL, REST, or anything else. You should be able to use Apollo or AppSync.
m

Mischa Spiegelmock

01/04/2022, 3:47 PM
cool
the AppSync PM is telling me right now they are working on fast lambda change deployments for appsync "With accelerate we aim for changes in your lambda functions to be deployed in less than ten seconds"
t

thdxr

01/04/2022, 4:00 PM
ask them about batching lol
I need an answer
Batching limit of 5 whyyy
d

Derek Kershner

01/04/2022, 4:01 PM
@thdxr means to say "anything they improve will improve SST as well, most likely"
m

Mischa Spiegelmock

01/04/2022, 4:01 PM
ok i'll ask lol
idk why she keeps saying she has very limited resources
t

thdxr

01/04/2022, 4:04 PM
Limited resources as in her team is too busy?
m

Mischa Spiegelmock

01/04/2022, 4:05 PM
@thdxr what's the batch limit exactly? she doesn't understand
t

thdxr

01/04/2022, 4:05 PM
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
It's arbitrarily limited to a batch size of 5 so if you're listing 100 articles and need to fetch the author for each of them, you'll invoke the function 25 times with 5 authors each instead of 1 time with 100 authors
m

Mischa Spiegelmock

01/04/2022, 4:06 PM
ok
forwarded it on
t

thdxr

01/04/2022, 4:07 PM
Thanks! How are you talking to her btw - I always find it impossible to get a hold of any aws team members
m

Mischa Spiegelmock

01/04/2022, 4:07 PM
lol
she said to DM her on twitter from a GH issue. https://twitter.com/praneetaprakash
s

Shadab

03/08/2022, 5:27 PM
@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
t

thdxr

03/08/2022, 5:30 PM
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 want to eventually get there with appsync as well but it's more involved
a

Aman Saran

03/08/2022, 5:31 PM
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
So I went with the same and so far, we've had no problems
s

Shadab

03/08/2022, 6:22 PM
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?
though I also explored the Apollo federation thing which you mentioned and it also seems a good solution if someone wants to deploy different apollo server for different resorces