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.
It has been 2 weeks after Re:Invent. Last week, as I recovered from the Las Vegas-to-Turkey trip jet lag, I took some time to evaluate what we learned from the event, made some adjustments to the Thundra roadmap, and got back into the daily work routine. Now, I finally have some time to share my thoughts from the event with this recap blog.
First, the AWS team does a great job putting on the conference. Previously, I followed Re:Invent via live streams but this was my first in Vegas and I really admired the quality of work by the team to manage, educate, and entertain tens of thousands of attendees.
I was often on duty at our Thundra booth, giving demos to visitors curious about AWS Lambda, Thundra, or simply just curious. Traffic was non-stop, giving me the opportunity to validate assumptions and clarify some open questions I had gathered before coming to Re:Invent. I want to thank the +1300 visitors who stopped by our booth and shared their experiences and needs regarding serverless, monitoring or both.
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.