Is there any kind of downside to using react apollo to call queries/mutations, with aws appsync?
The Apollo client should work just fine with AppSync for queries/mutations.
One potential downside would be missing any future potential AppSync-specific optimizations or features that might be released the the AWS Mobile SDK team, as well as future ability to integrate subscriptions, which would require the AWS-built SDKs, or modifying the Apollo SDK, since the Apollo SDK would not work with AppSync subscriptions out-of-the-box.
Related
This is a question keeps confusing me. Although AppSync is marketed as for GraphQL while API Gateway is for REST. But API Gateway could also work with GraphQL via apollo server in lambda.
So what actually makes one a better option over the other?
It depends on how much control you want over your backend service execution, how much code you feel like writing, and then of course how much you want to pay.
With API Gateway and Lambda you are writing a handler function that executes a full graphql request against your resolver definitions that you write in whatever language your Lambda runtime is set to. You have to consider how much memory your application will need, and what kind of features you want to support. You will also need to do some legwork to get subscriptions working with websockets.
AWS AppSync is more of a managed service, where you register your GraphQL schema with AppSync and the service takes care of things like query validation, batching calls, and of course out-of-the-box subscriptions. In it you only need to define how you want to "map" the GraphQL request using VTL (Velocity Templating Language) to define calls to your downstream data sources ie. specifically DynamoDB, ElasicSearch, HTTP, Aurora Serverless RDS, or Lambda. Keep in mind, the Lambda functions you write for AppSync only have to handle a single resolver, whereas with Apollo Server you are writing all of the resolver logic in your code.
Ultimately whichever way you choose has its pros and cons. With Apollo Server on Lambda you get to control the full HTTP GraphQL request cycle at the expense of additional complexity to do so. With AppSync you have a more "managed" service where you only need to define the resolvers to talk to your data sources (and in many cases, these can be auto-generated for you using Amplify CLI) at the expense of having finer control over the whole GraphQL request.
I'm trying to integrate Cognito Authorizers into an existing application that is using API Gateway to authorize requests.
The documentation insists on using AWS Amplify to make these calls, but I'm not sure that this fits in well with the existing architecture since Amplify seems to have its own way of making API requests, and I'm worried that it would mandate having to change all of the existing API requests...
So my question is if there are more readily integratable solutions to this problem, or if my concerns are unfounded.
There are several SDK's that can be used with Cognito.
You can use the AWS js SDK to make low level API calls but you will lose the benefits that the Cognito Client Side SDKS provide like session management, caching of tokens and SRP calculations.
https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/CognitoIdentityServiceProvider.html
You can also use the Cognito Identity SDK which Amplify uses under the hood:
https://www.npmjs.com/package/amazon-cognito-identity-js
The Auth SDK if you are going to be integrating with the OAuth endpoints, which is now deprecated but can still be used or referenced, Amplify also uses or has similar functionality.
https://github.com/amazon-archives/amazon-cognito-auth-js
And then finally Amplify which is the go to, feature rich client side SDK which for the majority of usecases should be the SDK of choice in my opinion.
I have been thinking about building a backend with graphQL.
The aim is to make the life of the backend team easier and iterate quicker rather then have to build REST endpoints or wss actions for each dataset retreivale.
GraphQL seems to be one of solution. We are very familliar with the Lambda environement and therefore in our research we found AppSync. I looks like a perfect solution, however I have some concerened around being locked in AWS and by designing the whole architecture around AppSync.
The beauty of serverless is that with the Serverless Framework, we could redeploy all functions to another cloud provider (Azure Functions) or even dockerize the functions for a deployment onprem.
I am concerned that with AppSync there is really no alternative in either other cloud providers or to easly do this onprem. Does anybody have any experience with this? Would it be more worth it to do the work to deploy an appolo server in lambda and build the connectors/listeners to the data sources our selfs with something like this: https://github.com/michalkvasnicak/aws-lambda-graphql/tree/aws-lambda-graphql%400.13.0#design-michalkvasnicak ?
IMHO, it comes down to how exactly the client of the GraphQL endpoint will secure data. One strategy is to secure an app with Amazon identity services like IAM and Cognito. Amplify's strength is secure integration with IAM, Cognito, API Gateway, DynamoDB, S3, and AppSync. A secure GraphQL endpoint on AppSync, for example. The data hosted in each AWS cloud service can be secured with Amplify and there are many other strategies too.
The serverless framework is a break through for serverless developer operations. The framework is beautiful. I don't disagree with your concern that Amplify generated cloudformation is not portable. Cloudformation is different DevSecOps culture than the Serverless framework. Amplify's generated DevSecOps code simply lands in Cloudformation culture.
I'm awfully new to GraphQL on the cloud, FWIW. I don't have experience with Apollo on Lambda. I cried, it looked difficult to automate the security though a seasoned pro may know. I certainly hope you get to a point where you never have to throw a single line of code away. I'm not even close, yet.
An easy entry point to the AWS eco system is to use AWS Amplify.
It has documentation guidance on security, GraphQL API, etc.
When using AWS AppSync as a backend GraphQL server, what are the advantages of using AppSync client on top of vue-apollo client? Can I just use vue-apollo to interact with my GraphQl server without using AppSync client?
Can you please share the specific use-cases or features looking for?
AppSync provides lot of the other features like real-time subscriptions, offline access, caching and enterprise security and fine-grained access control.
Does Amplify support the Offline capabilities outlined here:
https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app-react.html#offline-settings
Should I set it up like this?
https://aws.github.io/aws-amplify/media/api_guide#configuration-for-graphql-server
Or for offline capabilities, do I have to use something like Apollo?
There is a difference between AWS Amplify and AWS App Sync.
AWS Amplify is a library for web and mobile developement in JavaScript providing better access to AWS services like Auth, Analytics, Storage, APIs, Caching.
AWS AppSync is a combination of service that works as a GraphQL server and SDK (for web, iOS and Android). This SDK extends Apollo Client to provide capabilities like Offline and Realtime synchronization out of the box.
So, to answer your question: AWS AppSync does provide offline via its SDK out of the box and you shouldn’t need to do anything specifically to set up that.