My previous blog post was the proclamation of my admiration of AWS AppSync as a platform for GraphQL. In this post, I wish to proceed in my tango with the Amazon service that has given immense power to developers, especially those developing APIs. Hence, this is a demo post where I shall attempt to show the very basics of getting started with AppSync, and hopefully also provide some insight to those new with the technology. At the end of it, I hope to have some extremely basic examples through which you may be able to grasp the core understanding of AppSync and especially GraphQL. This is because, as mentioned in my previous blog, AWS AppSync and GraphQL, in general, are still novel technologies and have not yet been adopted to the same extent as current conventional data-driven application development methods.
In this demo, we shall first go over the basic structure of GraphQL and then implement the learned structures in the AWS AppSync Console. Considering the different ways that one can use AppSync, I shall also try to demonstrate some of these different methods while maintaining brevity. Amazon has never faltered in producing detailed documentation of their services, and this blog is not to be an alternative to them but rather a supplement that you can use to gain a solid insight before diving into AppSync with its myriads of capabilities.
As a developer, one of the most irritating things I face is that my attempts to implement good coding practices often renders my code broken and filled with bugs. It is quite the tragicomedy of code development, all in the effort to comply with the ecosystem of DevOps. The problem usually occurs when I try to configure tools I am not familiar with, only to result in my code base inevitably throwing errors or behaving unexpectedly. I thus end up barraging senior developers with Slack messages, and Google with endless searches in order to unravel the correct way of configuring these tools. Obviously if one follows the tooling docs to the letter, it should be simple, right? Wrong! More often than not, the documentation does not always address the specific use case you are trying to implement. Most typically, developers suffer through lots of easily-avoidable errors in the journey to become an expert on how to configure and implement that particular tool.
One example of a difficult tooling scenario is implementing a typical serverless monitoring tool. In order to collect even basic monitoring data, you often need to perform an excessive amount of in-code configuration. Usually, you are required to ‘wrap’ your code with the monitoring tool for monitoring to actually occur. Wrapping is the most popular way to integrate monitoring tools and collect basic data from your functions. However, this approach means you need to wrap numerous functions in order to successfully monitor an entire application.
Furthermore, in addition to the integration burden, configuring these tools can also prove tedious. It’s too complicated to expect, for example, a single simple-minded stooge like an unpaid intern, to wrap hundreds of functions and also expect him to do so successfully. No, there needs to be a more simple, less risky way of implementing monitoring for serverless applications.
Our team at Thundra realizes that this manual, labor-intensive approach simply isn’t efficient, and we’ve thus tried hard to design a monitoring tool which is easy and simple to use. Thundra offers its own serverless plug-in that allows automated wrapping to set up basic monitoring, along with automated instrumentation for more detailed monitoring. You don’t need to change your code base just to monitor your code. Finally, adding monitoring to your Lambda functions is actually easier than writing your Lambda functions. This is the way it should be!
Our previous blog showed you how our automated instrumentation (for detailed monitoring data) works, especially for Node.js. Now, let’s take a look at how automated wrapping is implemented. For now, we support automated wrapping for Node.js and Python functions.