To API Gateway or to not? about serverless HOT 10 CLOSED

We recently went through a similar thought process and settled on using API Gateway. The rationale was entirely for the sake of response caching. Even if a response is only cached for a few minutes, that has saved us many lambda invocations and database lookups, and made the application more responsive to the end-user.

This may not be true for all applications — but for ours, very rapid response times for small, seldom-changing data far outweighs the cons, not to mention to difference in provisioned throughput for DynamoDB and whatnot. I don't think the importance of cache can really be overstated for any application.

Aside from that, you can continue to use Cognito/IAM for a lot of authentication tasks even if using API Gateway. I know there are some limitations on how useful that is right now, but those issues are rapidly being addressed.

from serverless.

@hj1980 This is all interesting. Others have proposed similar architectures and they warrant serious consideration if they can save us developers from unnecessary complexity and give us our time back.

In general, I believe the REST API provides you with an extra layer, between the world and your Lambda functions (i.e., your code), that is useful for security and more. It's optimal for throttling/rate-limiting, load balancing, security (possibly), and it certainly makes it A LOT easier when you need to swap out infrastructure.

Is it necessary still? I don't know. API Gateway is brand new and it changes weekly. AWS changes weekly. Everything is evolving. We have to constantly test all options to find the best. For now, I'm inclined to invest in the API Gateway -> Lambda approach. I believe AWS knows what they are doing, they will keep making this flow better/easier, and REST APIs are a well understood standard. In the next day or two, JAWS will have more swagger/API Gateway functionality built, which will reduce a lot of API Gateway complexity for most.

However, if you go down your path and you find that it is ultimately supreme, please let me know. Perhaps it will win, perhaps it can complement a REST API approach, I don't know... But good luck, you have my attention :)

from serverless.

I think one place where using the the AWS SDK rather than REST to API Gateway would be uploading data to S3. Presumably the S3 upload logic in the SDK can be smarter about chunking up the upload, etc. It also is a more direct path to S3.

From the JS SDK docs:

Uploads an arbitrarily sized buffer, blob, or stream, using intelligent concurrent handling of parts if the payload is large enough.

from serverless.

The other concern with using API Gateway + Lambda + service rather than using the JS SDK to either directly call lambda or even directly calling the service is latency overhead. The API gateway adds latency as does the lambda function (even if it is hot).

from serverless.

Cheers guys for the feedback! I'm pretty interested to see how things pan out with our direct Lambda approach, and I'll be sure to let people know as it progresses. @ac360

I think that the whole REST API as a demarcation point is good, but if the goal is to have an end-to-end JS codebase then I think REST adds extra complexity on both sides. By controlling both the Server side JS and the Client side JS, there's an ability to change and use whatever transport + auth methods are required, the REST API is effectively invisible. Maybe I'm missing the point?

@kabaka The caching requirement made me think a bit, perhaps that could be included in the payload back from the Lambda functions as 'metadata' or similar. I know it's repeating the whole HTTP headers thing, but may still solve it.

@cancan101 Chunked uploads would definitely work if you can control the client JS. You could abstract the S3 upload process, using the same creds you get from Cognito - or alternatively if you could find a way to do it via multiple sequential Lambda function calls.. Interesting challenge!

Rate limiting is still an issue though for Lambda.... Any ideas?
Thanks again :)

from serverless.

Update 8/13/15:

We’re currently working on a document that outlines the specifications for JAWS v1.0.0.

A proposed resolution to this issue in particular is included in that document.

Today or tomorrow, we will share the document for everyone to comment on because your feedback is essential.

from serverless.

I've been wresting with this idea since the API gateway was announced. Very good points brought up here. Does it have to be a real choice? I think we can have both and do both well. Making API Gateway mandatory is not the way to go.

Direct DynamoDB Reads/Writes can be control with IAM and fine-grained access control.
I see the argument for caching, but you're also paying for the cache per hour and lambda calls when needed. Why not just increase the read throughput? Writes are never cached, so I see no upside there. Again though, you can have both. Perhaps you want to have a JavaScript SDK for your web app and provide a REST API with a Swagger file to use with other languages. It should be case-by-case, but the way to go is to provide standards for doing one or both.

You can also cache responses on the client-side with localStorage/sessionStorage/IndexedDB. I would like to have something like PouchDB that syncs with CouchDB, but instead for DynamoDB. This would be complicated to make initially, but I believe it could be done, probably in another project parallel to this one. Cognito Sync takes care of it, but only data for that user is accessible. Firebase has been gaining traction by handling this. I think it could be done better and cheaper with AWS, plus have all of the other awesome features AWS offers.

Don't use lambda functions to upload to S3. Use lambda functions to generate a presigned URL or token to let the client upload to S3 directly. You can control pretty much everything this way including file size--something that I wish IAM would implement for S3.

Rate limiting is definitely a problem with direct lambda invocations and direct database operations. Agreed that this would have to be (and should be) baked in by AWS. Perhaps it could be triggered by a CloudWatch alarm, DynamoDB Streams, or something similar. I would like it to be configurable in IAM.

from serverless.

@binoculars Great insights here.

For the record, JAWS will not make you choose one or the other. You can use both methods.

Instead, JAWS focuses on lambda optimization and deployment, as well as packaging your lambdas into modules for re-use and sharing so that others can easily install them.

from serverless.

We're taking the API gateway approach, REST has become a standardised approach, leads us open to future integrations (third party, public etc) if we need to go that route, not to mention the ease for our development team (everyone knows REST, right).

from serverless.

@ollierattue true, but AWS provides REST APIs already and SDKs for nearly every language. If you set your permissions in IAM, you can restrict things at very fine-grained levels. Why re-invent the wheel here if you don't have to? Also, there's no reason you can't do both.

from serverless.