Hi everyone, what is your preference on calling Ap...
# general
a
Hi everyone, what is your preference on calling AppSync API in a nextjs project? Apollo client or amplify? I am leaning toward amplify since it seems more organic with appsync but the hooks come with Apollo apis also look nice.
t
Urql
I think it's the best implemented GraphQL client, I have issues with Apollo and amplify
a
wow didn’t hear about it. does it work well with subscription too?
t
Yeah it does
But you need to do a little bit of extra work to connect both Apollo client or urql to subscriptions
I just gave up on AppSync ran into too many issues
a
sad to hear. what issues you run into?
m
Use appsync and don't have any issues, When using cognito for auth I usually go with amplify. I am using apollo in an app with custom auth and don't have any complaints. I've heard good things about urql but haven't used. As usual this stuff is usually just preference.
t
Need to consolidate all my thoughts around AppSync but I was really hoping it would work since it has an interesting automatic subscription implementation. Main issues were 1. Batch loading is limited to 5 concurrent - this is super limiting and would rather just implement dataloader myself 2. The dev workflow is kind of tiresome when editing your schema and you have to wait for changes 3. The tooling around it is decent, but Apollo's is obviously next level
a
thanks guys. will dive deeper in apollo and urql. the aws doc already gets me confused. they have amplify client as well as appsync sdk and appsync sdk with link to apollo v3 😂
m
@thdxr What is the use case for batch invoke? I've never had to use it to load nested resolver (resolver chains). While not huge I believe the concurrency level for appsync resolvers is 20. However I rarely use lambda for resolvers.
t
It's used to deal with n+1 situations. So if you fetch Posts and then want to fetch each author, you'd want to batch it. The limit of 5 is tough with that and there's a thread with two years of people complaining that hasn't gotten attention
The other thing is as much as VTL is very serverless and reduces your code, I particularly don't want to couple my api with my database
See the GQL thread recently in #random
a
It’s used to deal with n+1 situations. So if you fetch Posts and then want to fetch each author, you’d want to batch it. The limit of 5 is tough with that and there’s a thread with two years of people complaining that hasn’t gotten attention
I may misunderstand your problem. But can you use
PIPELINE
to hydrate the author field for each post? I don’t remember seeing concurrent limitation with this approach.
t
Pipelining solves a different set of issues, the need for batch invoke is detailed here: https://stackoverflow.com/questions/51788017/n1-queries-in-aws-appsync
AppSync isn't bad it works decently well for most things. Like most AWS things it's not best of breed but good enough. The only thing here is it's really easy to run up apollo with SST - maybe even easier than running up Appsync + Apollo serverside tooling is something I want to take advantage of
m
I see. n+1 is a graphql issue not just in appsync. I think we just subscribe to different mentalities. I tend to stick to service integrations as much as possible. I think it's the best way to operate in AWS. Running custom code in a lambda always gets a second look and is avoided. AppSync is it's own flavor and maybe a unique one! VTL is frustrating at first but it's really not that bad. AppSync is mostly meant to work with AWS in a service integrated way. Fighting that probably leads to more frustration. Not sure I follow this, "I particularly don't want to couple my api with my database". You simply permit appsync to communicate with a variety of data sources. They are not coupled. If you need to operate on the data returned that is what response templates are for. If you want manipulate request coming in that what request templates are for. If you need to talk to multiple data sources and manipulate data ala controller logic that's what pipelines are for.