AppSync is my Object-Relational Mapper

Remember the Oscar Meyer Bologna tune? Sing along with me - -

My ORM has a first name

You spell it A-P-P

My ORM has a second name

And it’s S-Y-N-C

I love to call it every day

And if you ask me why I’ll saaay

Cause App-Sync has a way

Of making code feel light and gay

My apologies, I couldn’t resist. In part because I’ve had a love-hate relationship with Object Relational Mapping (ORM) tools over the years. I’ve known a few, some intimately. The affairs typically begin well. It’s all butterflies and unicorns at first, but it never lasts.

On one hand, ORM’s abstract the nastiness — from me and others — of whatever database I’m using. I love them for this. They make my code more readable, attractive and maintainable. They give me one spot to go fix — if there is a DB problem, or if I want to divorce my current DB for someone younger. As such, I consider them great dating material.

On the other hand, ORM’s are not very transparent, and like to do things themselves that they really should leave to me — like query optimization and schema generation. Many of them even provide “magic buttons” that will generate your DB schema and the required queries for you, thus allowing you to dig your own grave both deeper and faster.

Furthermore, many ORM’s like to cache the data they get from the DB. In general, this is a great thing; the DB queries to build your Objects are often complex, and why do that twice if you don’t have to? Very helpful. However, with the move to microservices and serverless computing, we’ve introduced extreme horizontal scaling into almost every modern architecture. Horizontal scaling doesn’t play well with in-memory caching, and results in a schizophrenic relationship. The resultant counseling required (aka - consulting) is expensive.

So, what’s a guy (or gal) to do? If only I could find an ORM that had all the good, with none of the post-honeymoon crazy. As a matter of fact, I have.

I’ve started dating AWS AppSync as my cloud-based, serverless ORM.

AppSync is serverless GraphQL. GraphQL is a RESTful and/or WebSockets API based upon a specification originally released into the wild by Facebook.

AppSync’s got curves in all the right places. From GraphQL it gets a clear schema, robust type definition, clear operations on those types, user-specified returns, and the ability to tell me when it’s changing things.

AppSync’s also fast, smart, listens well and is loyal.

GraphQL was originally designed to give objects to end-user web and mobile apps, so we know it’s fast.

·        AppSync adds the ability to talk to many different data sources, so it’s smart.

·        GraphQL only gives you the stuff you ask for, and nothing more, so it’s a good listener.

·        AppSync provides a fantastic set of authentication and authorization capabilities, at a fine-grain level if you wish, so it’s loyal and only talks about my stuff to people that I vet.

All of these excellent qualities mean that AppSync is not just a great match for managing persistent objects in a mobile/web application; it’s a fantastic match for managing those same objects in a serverless/microservices application! After all, aren’t serverless functions or microservices simply another form of app? It’s so good, I’ve even been using it for applications that are mostly back-end transaction processing.

I’ll end with a word of caution.

Just because you have a hammer, not everything is a nail. If I was building an application that was doing large, set-based manipulation and analysis of data, then AppSync/GraphQL (or any ORM) is not a good match. If I was streaming large objects in and out continuously, AppSync/GraphQL (or any ORM) is not a good match. You get the idea.

That said, the vast majority of the business application work that I do (and I suspect that you do) doesn’t fall into these data-intensive edge cases. Instead, it’s simply transaction processing and displaying information to users. And for that, I’ve found the best partner. At least for now.