Why We're Excited About AWS AppSync - Think FaaS Podcast

Thu, 03 May 2018

Transcript

Hi, I’m Forrest Brazeal at Trek10, and this is ‘Think FaaS’, where we learn about the world of serverless computing in less time than it takes to run a Lambda function. So put five minutes on the clock - it’s time to ‘Think FaaS’.

AWS releases new services and features at a pretty bewildering rate, so don’t feel too bad if you missed the announcement a couple of weeks ago that AWS AppSync is now generally available. AppSync has been in preview since re:Invent in November, and despite the anonymous sounding name, it’s actually a pretty ambitious product. It essentially lets you set up a fully-managed backend as a service for a GraphQL API, along with real-time updates and offline synchronization for application clients. It’s also pretty cheap. We’ve been using AppSync on some serverless projects here at Trek10, and we’re getting more and more excited about it for a couple of reasons.

First, it makes real-time serverless apps a lot more feasible. Before AppSync, if you wanted to do real-time updates to a serverless app, your options were really limited, because a Lambda function can’t hold open a web socket. There was some crazy hacky stuff you could do with passing messages through AWS IoT, but AppSync finally brings this native ability to subscribe an app, get updates in real time, and synchronize offline data. You can think of it as a Firebase competitor, but using any database back end you want. Right now there are native integrations for DynamoDB and ElasticSearch, and you can plug in Lambda functions to bridge the gap to other things.

Second, it gets one step closer to “codeless” backend development. I recently used AppSync for a client project that needed a GraphQL API. To get a basic front-to-back query API working, I wrote a grand total of no code. I defined a GraphQL schema, I added a couple of VTL mapping templates to tell AppSync how to get my data in and out of DynamoDB, and I was done. I didn’t have to import any GraphQL libraries, I didn’t have to write code to query my database — AppSync took care of all that, while still giving me the flexibility to define behavior through config. The reduction in technical debt here is really exciting.

There’s also a bimodal trend in all of this, which folks like Joe Emison have been talking about for several years. We’re seeing data consolidate in the cloud, using scalable services like Aurora and DynamoDB. We’re seeing front-end applications being pushed to the edge and running directly on devices. But that middle layer — the app servers, the web servers, all the intermediate cruft you used to have to write in order to connect your users to their data — that is increasingly either disappearing or being abstracted into managed services like AppSync.

This is why we keep saying containers and container orchestration, all of which thrive in that middle tier, might be a distraction for a lot of folks. If you can deploy your app at the edge, and rely on a managed back end at scale, a lot of the reasons for rolling your own containers disappear. It also means that if you describe yourself as a “back end developer”, and you maintain CRUD APIs for a living, it might be time to level up your skills. Mapping data to API calls is just not that interesting of a problem anymore, and it’s only going to get more abstracted.

Getting back to AppSync, they added a couple of really key features in the GA release - CloudFormation support and CloudWatch logs, as well as some basic developer tooling, so I would say it is ready to use in your next project. But there are still a few big things we’d like to see.

Chained resolvers would be really nice. Right now, if you have an arbitrary number of traversals in your data, you’re probably stuck writing Lambda resolvers, and remember, we want to write less code, not more. An important thing to keep in mind is that GraphQL itself is a relatively new idea, and the general best practices for a GraphQL API are still evolving. So I actually have hopes that AppSync can help grow and mature that community as well. AWS has not had an amazing track record of contributions to outside open source projects, and this is a great time to change that.

I’d like to see AppSync adopt more features from API Gateway. I know, I know, API Gateway has its warts, but it also has this nice concept of usage plans, rate limiting on API calls, and tons of options around authorization. When you go straight to an AppSync endpoint, you lose a lot of that control. I’ve actually put API Gateway in front of AppSync and passed data through an HTTP proxy to get these features. That works okay, but obviously it would be ideal if AppSync had those controls natively.

A native RDS or general HTTP data integration would be awesome, hopefully with some kind of managed connection pooling so you don’t knock down the database. And of course, if and when AWS Neptune goes GA, we’d love to see an integration there as well. The point is, AppSync is exciting enough that you immediately start thinking of more things you’d like to do with it, and that’s a great problem to have.

With that, I’ve got to go write my very first AppSync CloudFormation template, so I’m signing off for today. If you’re looking for more serverless updates, you can stay up to date by following Trek10 on Twitter @Trek10Inc, I’m there as well @forrestbrazeal, and we’ll see you on the next episode of Think Faas.