I am looking for some general architectural guidance about designing good cloud apps, primarily using AWS. For the sake of argument, lets say it's a single page app, written in JS, hitting a couple of services like S3 and maybe some Lambda functions that read/write to a DynamoDB.

Option 1 - Make calls directly using AWS SDK So, this seems to be how the documentation is written. Your app would auth the user using Cognito, exchange for the tokens, then connect to the services directly.

Benefits here: Code is in the UI, so less moving parts. Cognito seems geared towards this type of dev...otherwise your server parts would have to cache the tokens or you'd somehow have to pass them around from the client. It also seems like less cost since you wouldn't be paying for an "intermediary" service to bounce calls off of.

Cons: Well, your code is all in the UI, making your UI bloated. It feels like too much business logic would be in the client, which feels wrong.

Option 2 - Intermediary services Basically you would write some service, be it a Lambda function or an EC2 microservice or the like, to "bounce" the calls off of.

Benefits here: Well, you would have some additional level of control. Also, these intermediaries could house most, if not all, of the business logic.

Cons: Well, the biggest one is cost as you would now have to host a bunch of extra "things" to service your calls. Also, for the most part, it would seem like most of your intermediary services would be pass-through, so where is the benefit?


I would say Option 2 is standard practice.

A direct client to database connection has always been considered bad practice, but usually this is in the context of standard privately hosted SQL databases.

To make a direct connection to a DB work your main problem is preventing the user accessing other peoples data, or changing their own data without following the business rules you have put in place.

To do this you really need row level security. This is available for DynamoDB, so it's in the realms of possibility, the question is whether the configuration is flexibly enough, or your DB simple enough that you can encode your business logic restrictions into the security permission config.

The main benefit of Option 2 is that you can put your business logic on computers that you own. This prevents any 'inventive' use of client credentials and allows you to:

  1. enforce complex rules: "no updates allowed on bank holidays!"
  2. Logging
  3. Audit trails
  4. access to third party APIs requiring secret keys

etc etc, regardless of the features of the underlying resource. Also it makes your client 'thin'. It just has to display the UI and call the API.

The right choice depends on your use case. If you want to share a photo with everyone in the world, sure, upload it to S3 directly. If your app is only deployed on company premises and the resources are firewalled, maybe direct a DB connection is fine.

Processing done on the client is processing you don't pay for, so it's always good as long as you can trust the client.

| improve this answer | |
  • I totally agree about the DB access. I guess my question was more geared to things like S3. As I am working towards playing in Cloud it seems like the old "write everything to a DB" was of development is becoming less appealing. And even if I where to use some sort of data store, it almost makes more sense to use something like AppSync and GraphQL, which has security built in, at least from what I can tell, through IAM roles and policies. – CodeChimp May 24 '19 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.