I have a simple question: is there a way/program/method to create unit tests to test the API Url generated on AWS AppSync to verify the validity of created GraphQL schemas, queries, mutations, etc?
There is an open-source AppSync Serverless plugin which has offline emulator support. You may find it useful: https://github.com/sid88in/serverless-appsync-plugin#offline-support
Another good recommendation is to have two separate AppSync APIs. One API is hosting you production traffic. The other is to test changes before they go to production. This is significantly easier if you use Cloudformation (highly recommended) to manage your infrastructure.
If you want to validate your API is working periodically (every minute or so), you could create a canary like the following:
Create a Lambda function which runs on a schedule. This lambda function will make various GraphQL requests. It can emit success/failure metrics to CloudWatch.
Setup a CloudWatch alarm so you can be notified if your success/failure metric is out of the ordinary.
For the canary use-case see:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
https://docs.aws.amazon.com/lambda/latest/dg/with-scheduled-events.html
There is also amplify amplify-appsync-simulator package that is supposed to help with testing appsync, but there is no documentation on how you should use it. It is used by serverless-appsync-simulator Michael wrote and Amplify itself.
Related
I understand you can use the AWS API Gateway to allow developers to create applications that interact with AWS backend services (e.g. DynamoDB).
The basic flow is:
Create the resource (e.g. DynamoDB table)
Create a Lambda function
Create an HTTP API
Create Routes
Create an integration
Attach integration to routes
But what are the options for the API? What kind of operations can be done on DynamoDB (or whatever resource you’re working with)?
Usually when a REST API is available through a Gateway there is a set of endpoints, so the developers know what they can build with the API. Like Swagger Documentation.
It would be great to know all the things that can be done via API to DynamoDB, S3, Cloudwatch, etc. is there a master list somewhere?
Or is the idea that you can do anything inside the Lambda function that is supported by the aws-sdk?
In that case, is there a list of available options for the aws-sdk?
Am I thinking about this the right way?
Looking to create an Apollo Graphql microservice on AWS and am looking for the best way to build this on AWS, AWS do have their own Graphql as a service called Apsync but this seems like a blunt tool. Have found lots of suggestions to use Lambda but not much else. The Graphql layer will resolve data from several other AWS microservices.
Certainly don't use AppSync. We used it for a year, and found it's difficult to configure and does not perform well in many types of queries. We ended up using the Apollo Server on top of Lambda. As we use DynamoDb, we wrote our own resolvers (not much effort) as part of using the Apollo Server.
I've an api going thru Lambda (node.js) to Aws Neptune. X-ray shows the traces from api-gateway --> lambda and stops here. Has anyone enabled deeper tracing all the way into Neptune ?
Thanks !
you can use AWS X-Ray SDK for Node.js to instrument your lambda function so the calls to Neptune are traced: https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs-awssdkclients.html
Please let me know if you need further help.
As of now, the most you can do is to use XRay clients and explicitly trace [1] the requests that you make from your Lambda. Neptune's AWS SDK currently only tracks management API calls, and not queries to the database. So unlike the dynamo db example called out in XRay docs, you cannot get granular insights (eg: query that was executed, the latency breakdowns etc) via XRay from Neptune at the moment.
It does sound like a useful feature, so I would recommend making a feature request for the same, or build something custom for the client you are using. Just curious, what client are you using from within the lambda? (ie Gremlin GLV? Raw HTTP request? Jena? etc..) For example, if you're using Gremlin GLV, then maybe all you need is to build a custom netty handler that can do tracing on your behalf.
[1] https://docs.aws.amazon.com/xray/latest/devguide/xray-sdk-nodejs-httpclients.html
I'm using AppSync with Lambdas. To do so, I use the serverless framework.
I have few questions about the way you manage your serverless project with it's dev/test/prod versions.
I currently use the --stage option like sls deploy -s test to have multiple version. But if there is a problem after a deployment I can't rollback so I wonder if I should deploy with a new name all the time and remove the preview version later?
EDIT: I've found this that should do it for lambdas but will that work for AppSync?
How do you manage your dev/test/prod versions of AppSync and Lambdas?
Using API versions would be great except there are no cross-API subscriptions. Your mutations in one API won't trigger subscriptions in another. I'm hoping AppSync will come to support some sort of API versioning.
Not sure if serverless rollback works with AppSync, they probably should. However, it's just using serverless's S3 bucket cache, it's not a CloudFormation feature. Therefore, you could pretty much use version control to roll back changes and re-deploy just as well (your use case may vary).
We do have dev and test stages in one AWS account and prod in another AWS account. In test stage we can test that the API is working correctly before deploying it to production.
For our other deployments we also have beta stage before production but for AppSync this isn't possible because of the cross-API subscription issue. We can't have some data changing in production through beta API and not triggering a subscription in production API.
I am looking forward to work in a Amazon Lambda with Node.js
They call it server less, So is it a better way to host our code then traditional hosting servers ?
I am open for the suggestions, thanks in advance!!
It is called serverless as you dont manage and maintain the underlying server and the runtime.
Basically you write your code in one of the supported languages, say node.js, and then configure events that will trigger your code.
Example in case of AWS, the events can be a API GW call, a SQS message, a SNS notification etc.
So it can be better depending on what you are planning on doing.
Do note that there are certain limits that AWS imposes by default on accounts for AWS Lambda.
Also there can be slight startup penalty for a Lambda.
A plus point of Lambda vs Hosting your code in EC2 is that with Lambda you dont get charged if your code is not used/triggered.
However, do note that for functions that have heavy usage it might be better to
host your own EC2.
Most important a Lambda has to be stateless.
Considering all the above factors you can take a call on whether AWS Lambda and Serverless Architecture fits your needs.