In this article, I'm going to contextualize some history of AWS' mobile products, and explain when and why you should (or should not) use them.
Early Development of Android support at AWS
This year, the AWS SDK for Android turned 10 🥳. The Android SDK originated as a fork of the original Java SDK.
To frame the discussion, let's recall what AWS looked like in 2010. S3 and EC2 were among our only offerings. Each was still in its infancy of public availability.
2010 was the start of the "Web 2.0" revolution, wherein it was no longer enough for a company to be "online." In the Web 2.0 world, you needed to have an API, too.
In response to the dramatic uptick in demand for APIs, REST began to overtake SOAP as the dominant architectural pattern for client-server exchange on the public Internet. Then-recently created OAuth emerged as the dominant standard for authenticating service requests.
A key point here is that the Android SDK was envisioned before these practices had emerged, not in response to them.
Overview of AWS SDKs
Shifting gears for a moment, let's talk about the AWS SDKs in general. AWS offers SDKs for JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++. I'm aware of active projects to support at least three more popular modern languages.
We also provide platform-focused SDKs, like the SDKs for Android, iOS, and front-end JavaScript.
One immediate question you might have as a front-end dev is:
Why wouldn't you just use the Java SDK for Android, and the JavaScript SDK for the web? And the (er) ... what about iOS?
Why You should use our Mobile SDKs
There are a number of reasons why you might want to use one of our mobile SDKs (as opposed to a traditional SDK.)
First off, if you're an iOS developer, you don't really have an option right now. The iOS SDK is currently the only SDK that supports Objective C or Swift.
But even on Android, the V2 Java SDK uses some advanced language features, that are not supported on Android. For backend developers, it makes sense to take full advantage of modern JVM features in a modern Java SDK. Unfortunately, the tradeoff is that the Java SDK isn't compatible with Android's runtime, "ART."
Another reason to prefer the mobile SDKs is that they tend to be vastly stripped down in comparison to the traditional SDKs. For reference, the Android SDK has tens of modules, many of which are focused on data-plane operations. The V2 Java SDK has hundreds of fully-featured modules, useful in managing server infrastructure. It would be wasteful to include all of that extra bloat on a resource constrained device.
Lastly, AWS Amplify also provides some high-level client libraries which are specifically tailored to use cases commonly encountered on the front-end. For example, most apps need to handle user authentication, save data to the cloud, and record some usage metrics.
The high-level Amplify libraries are plug-and-play for developers without a lot of experience fiddling with the AWS backend. If you're just starting out with an idea, and want to build it out quick: use Amplify. You'll be able to think about the problem in an idiomatic way, using workflows familiar in your front-end development environment.
Why you should not use the Mobile SDKs
"Great!" you say. So why wouldn't I use the mobile SDKs?
The answer to this draws back to my opening point about AWS' history. The SDKs were designed at a time when it was still future-looking to simply communicate with a remote endpoint over REST. That ship has sailed. That's how 95% of new APIs work, now.
Let's distinguish between two types of client-server interactions. There is a "north-south" interaction, where a public client talks to your service over the Internet, and there is an "east-west" interaction, where your services talk to each other behind a gateway.
I posit that the AWS SDKs are primarily used for server-to-server communications, to toggle control/admin plane functionalities. In its infancy, AWS prescribed no mechanisms for the data plane. That was left to whatever application you installed in EC2.
Why does it matter? Mobile devices are always a "north-south" interaction. Once you release your application to the App or Play Store, you lose control over them.
In a perfect world, we could just implement business logic, and make it available for use over the public Internet. But, we don't live in a perfect world, alas. APIs that serve the public Internet need to be conscious of DDoS attacks, they need to bill/meter resource consumption, throttle over-zealous actors, authenticate and authorize requests from different parties. The list of additional functionalities starts to go on and on.
In fact, there are so many additional features needed, even before we reach your business logic, that it really makes sense to put all of this stuff in its own "front-end service." At Amazon, we have only a handful of services that implement this full range of "front-end" functionalities. I'll call these "mobile-blessed services." The leader of the pack is Amazon API Gateway.
How You Really Ought to Use SDKs with AWS
Your mobile applications should interact with your business logic through a RESTful endpoint managed by Amazon API Gateway. You should prefer not to make direct calls to most Amazon services directly from a mobile device.
This mantra has some big implications for the utility of the mobile SDKs. As one arbitrary example, let's consider a use case where we want to call Amazon Translate, to translate some text. Instead of using the Amazon Translate support in the iOS or Android SDKs, I'm suggesting that you should pick any supported language, and implement those Translate service calls behind the API Gateway. Render an API response that contains only the bits you need on the mobile device.
By the time you've implemented this solution, you don't need much on the client. You need a tool to auth users, and a way to sign requests to Amazon API Gateway. Retrofit and Volley are de facto standard REST client libraries.
Now, there are a lot of different things you can put behind Amazon API Gateway. But for most small-to-medium sized applications, where you don't want to futz about with EC2 instances or containers, you should probably start with an AWS Lambda.
Exceptions to the Rule & Special Snowflakes
AWS has a few other mobile-oriented services and/or services with a rich set of "front-end" features: Cognito, S3, CloudFront, AppSync. Similarly, any discussion of various AWS services would be replete without guidance around EC2 and DynamoDB.
Cognito is almost a prerequisite to any serious AWS mobile integration. It provides mechanisms to hook into Google, Apple, and Facebook accounts. You can assign rules around which users get to access what AWS resources. There is a lot of client side logic needed to implement a secure session with Cognito. I recommend using our high-level Amplify Auth for this.
S3 is actually Amazon's oldest service. It hooks into CloudFront. It has been designed explicitly to serve low-latency content over the public internet. S3, combined with a CDN of some kind, is absolutely a "front-end" service.
AppSync is a newer offering, providing a serverless, managed GraphQL endpoint. My team is actively investing a huge amount of energy into the product space. Overall, this is still emerging technology at Amazon. AppSync lacks some basic P0 front-end functionalities like throttling.
EC2 is one of our most popular services. However, there are limited use cases to provision servers directly from a mobile handset over the public Internet. This a prime example of something you should not be doing with the AWS Mobile SDKs.
Dynamo is in a similar boat. It's a well-known bad practice to call a database directly from an application. However, Dynamo is arguably one of the most useful services AWS provides. We've built an entire front-end product based on transacting data models into and out of Dynamo. Please checkout the Amplify DataStore!
Wrapping Up
Above, I've tried to provide a bit of context on why we have the products we do, and how you might like to use them. I've laid out some strong opinions. But, as with all solutions in Engineering, you need to look at your use case, and weigh the tradeoffs. I hope this article has moved you closer to a good solution in your unique situation. Happy hacking!
Top comments (0)