Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Jeeze, there's a lot of comments in this thread written by people who have no clue how any of this works lol
    by nater5000
  • I strongly recommend never using functions as a service unless you genuinely have some client edge compute requirement that absolutely cannot be solved via some other means.

    Everything about running software is made more difficult this way. You might think it would make certain infrastructure aspects easier, but it just changes the semantics of the same problem. It's the same quantity of mess to clean up, but now it's in these really weird piles that are often much harder to access.

    > up to 128 concurrent requests per environment

    I am fairly confident I could support more capacity with a single t3a.nano instance.

    by bob1029
  • Something very similar to this was already possible via serverless-express for node:

    https://github.com/CodeGenieApp/serverless-express

    This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections.

    Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two.

    Similar libs exist for other runtimes as well.

    by torginus
  • I've built 2 applications using Lambdas as a backend and I love how simple and it is. It cost literally 0$ (the lambda part).

    The frontend is hosted on cloudfront, the backend is a lambda and you basically just pay for the database and certificate.

    I don't want to manage a server or even a docker image. I just want my code to exist there so I like the idea

    by remify
  • Rust + Axum has sort of supported this with a middleware (https://github.com/lazear/axum-aws-lambda). Essentially you write your API as normal, and then when you build for lambda you enable a feature that does the special handler for you.

    This + Function URL + Cloudfront, and you end up with an API entirely hosted in lambda. I have a backend that does is hosted like this that does pretty complex work (image/video uploads, image conversions, on top of the standard auth, database connections, etc). It even renders a frontend with HTMX/Alpine.

    Even with all the bot traffic I receive, at almost 15 million requests per month the cost is under $10/mo (median latency is roughly 90ms). Cold starts are a non-issue with the Rust runtime.

    by nemothekid
  • Looks pretty interesting. I presume the boom in cloudflare workers and other hosting platforms has been a forcing function to make running a web app more “normal” looking with their lambda offering.
    by tkcranny
  • Interestingly, Google Cloud recommends using Cloud Run (any container) instead of Cloud Functions (upload code). AWS can do that with Lambda too, I wonder why AWS decided to "move backwards" here, as I always found containers are easier and faster to work with?

    Both container-way and code-way have the same scalability (code-way is built into a container anyway, just on the cloud). Maybe AWS re-builds the container for security every day?

    The page has only a description, no comparisons. The best way to explain a technology is to compare it with something.

    by deepsun
  • I've written up how they work in practice: https://aws.amazon.com/blogs/compute/exploring-aws-lambda-we... We also have a selection of code samples to try it: https://serverlessland.com/patterns?services=lambda-web-func...
    by julianwood

Explore Birbla archives