AWS Lambda

If you're ONLY using Lambda I would recommend Claudia. It is a lot simpler of a framework and it is also pretty easy to configure and use without having to learn much. If you plan on using the wider AWS ecosystem I would recommend Serverless or SST.

Both Serverless and SST will give you more fine grained control over AWS resources and makes it easier to work with either through CloudFormation or CDK.

Hi Marc,

For the com part, depending of more details not provided, i'd use SSE, OR i'd run either Mosquitto or RabbitMQ running on Amazon EC2 instances and leverage MQTT or amqp 's subscribe/publish features with my users running mqtt or amqp clients (tcp or websockets) somehow. (publisher too.. you don't say how and who gets to update the document(s).

I find "a ton of end users", depending on how you define a ton (1k users ;) ?) and how frequent document updates are, that can mean a ton of ressources, can't cut it at some point, even using SSE

how many, how big, how persistant do the document(s) have to be ? Db-wise,can't say for lack of details and context, yeah could also be Redis, any RDBMS or nosql or even static json files stored on an Amazon S3 bucket .. anything really

Good luck!

I used to work in a Perl shop and must admit that the language is very simple for tasks like these, but as you mentioned it's not fast at execution time. I'm now a Go programmer professionally but I taught myself the language while in college purely out of interest and eventually found my way to the job, not the other way around. I've recently been learning a little rust because of how much that language comes up in conversations around Go. I find the concept of the borrow checker nice but I have to admit I feel lost like I am in most flavors of new fancy framework js. That's not to say Rust is really anything like js, but the learning appears the same to me as someone who's convinced they could learn just about any programming language if it was necessary (over time I've seen procedural, OOP, declarative and functional stuff but never programming logic outside of the prolog code I wrote in school).

Go isn't made for your specific task at hand but it's a very easy language to pick up and it has good directory traversal standard library code and good regex (even though with time perl's has been optimized to be faster and I think it's written in C++) but more than anything Go is "cloud native" programming in that an awful lot of new microservice tech stacks are centered around it, docker and kubernetes are written in it, and there's a thriving community whose focus is generally web-first and performance-oriented. This means for your use case there might already be a large cohort of gophers that have asked the stackoverflow questions for you

I personally would push you towards the NYT Profiler for Perl before I would towards Rest, but that's because I know you wouldn't waste any time being able to get to the task at hand and then make it go faster, and I expect all but a few rustaceans would be able to do so with the same speed.

Whatever you pick I wish you the very best of luck!

The main question here is your request rate. - If it's usually very high, then in most cases you shouldn't run into cold starts - and for the rare gaps, you can send a steady stream of "blank" requests that will keep the lambda's alive. - You can also consider pushing all your incoming requests to an SQS, and then triggering lambdas based on the sqs capacity - this way you'll be able to provide a constant level of service even with the cold starts

Have you used Provisioned Concurrency for your Lambdas? They can make a big difference, especially for Java.

I have never understood why using different vendors is such a big problem for many people. Each vendor is better than others for certain aspects, but no vendor is better than others for everything. At Kokoen, we usually host the applications we develop in AWS (EC2, RDS, S3), use Firebase (usually with OneSignal.com) for notifications, use Netlify for hosting certain SPAs, use Heroku to provide APIs directly from Git while we are still developing, MongoDB Cloud when we need NonSQL databases, etc..

I find Spring Boot is the most productive environment, and written properly, it is fast. However, speed is the least of your concerns. You should be considering support and maintenance, along with time to market. The best tool for the job is the one that you can support 5 years in to the future. It is the one that will return dollars from customers soonest. You can always scale up your AWS Lambda servers to get more power.

Hi Nikhil, I agree either Node.js or Java can be used to write the AWS lambda function. As you didn't say the type of task is going to be performed in AWS function. I would recommend Node.js if the task has to run asynchronous (i.e) Don't wait and simple continue with the next request.

Some difference between Node JS and Java

• Node JS is open source where as Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial, or production use without a commercial license, as Oracle announced.
• Node.JS uses asynchronous programming language, so its easier to write and executions is non blocking.

Hi, It's depend of which type of data and interaction with database requires, I vote for Cloud firestore as NoSQL Db to store large or complex data. RDS is good for relational data with simple queries. Based on your application functionality you choose the stack. Hope, it helps.

We have microservices in production with both technologies (hosting simple CRUDs, more complex async processes, GraphQL endpoints, etc). As a matter of preference, for greenfield projects, we tend to go full serverless (lambda, dynamo, aurora...), because is not only cheaper in general, but way easier to continuously integrate with bitbucket pipelines, github actions, etc. The drawback is still the cold starts, despite the last improvements in VPC cold starts; it's way less noticeable in non statically typed languages though (Node.js, Python...). You will have to keep the lambdas warmed with Cloudwatch events if you can't wait for a few seconds after the first invocation, or use the new feature Provisioned Concurrency (which we haven't), that kind of defeat the purpose of being serverless.

As to how to host different methods of an API in lambdas, there are different approaches: we have for example stacks of cloud formation where every lambda host unique functionalities (one for detecting faces in images, another for cropping, another for comparing, etc), and also other stacks where the entire GraphQL API is hosted with Fastify in just one lambda. It really depends on your use-case.

If you host your API in ECS with an ALB, you won't have cold starts, it will automatically handle blue/green deployments with no disruption in the service while you deploy, but your bill will increase, and the infrastructure will be more difficult to automate in something like a template.yaml.

Give it a try with aws sam (Serverless Application Model), with a few commands, you can have a sample API running in a couple of minutes.