AWS: We're gonna make mobile apps great again with Lambda functions Amazon Web Services is rolling out new Mobile Hub features aimed at simplifying the development of secure mobile apps. The cloud giant says that its Cloud Logic feature will now let developers create Lambda functions specifically for mobile apps and integrate them with AWS's API Gateways. This, Amazon claims, should allow for …
Failing to see how lambda is being used to describe this. A function that creates another function can be written as 2 functions, without the need for lambda (regardless of convenience). So AWS users cannot currently use 2 functions instead of one? But, that seems to be a whole different matter considering how Amazon is describing the use of "Lambda" here. This doesn't seem to have anything at all to do with the actual coding practices, just a work around for their limited model/API or possibly a little more "freedom" from the Amazon collar servers or... a new API to increase client load.
Lambda in this sense is the AWS lambda service rather than the programming pattern of lambda functions. An AWS lambda service is a serverless piece of code written in Node.js or Python typically. It's entry point is exposed via API gateway as a restful end point that your mobile app consumes.
The big problem is that whilst API Gateway/lambda is a great protective wrapper round services with downloadable Android and Ios libraries for your API; the back end services that fulfil this API still have to be internet facing and cannot be inside a non-internet facing Virtual Private Cloud, which is pretty frustrating.
..but it's really handy nonetheless.
It's a shame they called them lambda functions, because that means something to me already, but in AWS parlance, a lambda 'function' is a zipped up set of code and binaries (if you want) constituting a microservice that executes in a docker container on AWS' managed lambda infrastructure. Paired with Gateway API it's great. The really nice thing is that your code is invoked by events (e.g. an API call or reading off a queue), and, depending on the frequency of those events, AWS will provision multiple instances of this environment to ensure your events are soaked up as quickly as they arrive. When the events stop, then the number of environments quickly scales to zero. You pay purely for memory and CPU usage.
The 'lambda function' is typically node.js but you can then invoke anything at all you've uploaded - e.g. a golang binary to do the work, but most of the time, your microservice is just going to call another API (such as a dynamoDB or S3 or another queue).
So there you go - free yourself from EC2 cluster management, nginx configuration, etc and still do scalable stuff which costs nothing when there are no events coming in but reacts within expected thresholds when an event does appear..
in my view, no-backend do work but only in greenfield. It's not that hard to build app to solve a problem people have even in an environment with many constraints like, AWS Lambda, Firebase or what used to be Parse.com (RIP).
But that is greenfield only. Try to integrate that with an existing technology stack if you have one and I'm sure you not gonna have a good time.
Only feasible way (does not break your mind or budget) Is to add rest end point to existing data sources and only integrate them at the view layer. Meaning just present the data in the UI like it was coming from one source while it actually is not.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
