Vercel/fun: ƒun – Local serverless function λ development runtime | Hacker News Reader

Vercel/fun: ƒun – Local serverless function λ development runtime

github.com

77 pointsOnavo25 comments

I've always hated calling these "lambdas" or even "serverless" as a whole. They are not pure and they absolutely run on servers.

Now, of course not all lambdas must be pure... but as a whole, for the entire concept to be called "lambdas" and have the entire link just be it runs a single function seems weak. Like what about the `main` function? It's just co-opting the term lambda to sell PaaS.

What they are is an attempt at making a more basic environment to program around. They are essentially operating systems, no?

Anyway, sorry for the early morning rant on this.

By definition anything that communicates with a db is not pure. So kinda useless term for endpoint handlers.

A function doesn't need to be impure to communicate with a db. It can describe the actions without executing them, returning the actions to let some other impure process execute the effects.

The function itself hardly communicates with the db then, does it? In your example it's the impure process that does all the actual communicating.

That's kinda my point.

https://sst.dev/docs/live lets you actually develop with lambda locally instead of resembling it

Serverless seems to me be just to be a more complicated way to do php shared hosting.

I personally went down the route of creating a mini wrapper around functionless/functions which allow me to run things locally via a server and then when it comes to deployment decide whether it should run via serverless or docker / on a vm via adaptors.

It doesn't allow you to simulate a lambda function directly, but makes the assumption (that held so far) that all the different API's and runtimes usually come down to the same core principles (HTTP / Websocket / timed jobs).

The core idea is exactly around testing which approach works best for lambdas / functionless.

https://vramework.dev/

Disclaimer: The core maintainer and I haven't yet published the serverless adaptors. Also need to update the landing page, as the serverless/server switch is only one of the core principles.

Honestly surprised more people aren’t talking about Cloudflare workers. They have an amazing local dev env with wrangler. Very cool architecture with JS-native RPCs, KV, durable objects, etc. I used lambda + dynamo for a while but found much more success with workers + supabase.

Is the Ruby runtime supported?

EDIT: No, https://github.com/vercel/fun?tab=readme-ov-file#runtimes

They still have anything besides nodejs on beta for ages, and although they build on top of AWS, only a subset of runtimes and deployment options are available.

What are some use cases for lambdas? I've not got around to doing anything with them yet and I wonder what they are mostly used for.

I've heard they are good for prototyping things where you need to change APIs and spin up new stuff easily. It might be better than using a service where you're basically required to have devops.

That said, you can also just spin up a VPS and use systemd to manage a service at small scale. There are also other PaaS solutions in addition to "serverless/lambda".

I've heard some horror stories about "lambda" pricing as well, so I'd make sure to read into that before becoming too dependent.

Do you think having a normalization layer between serverless and server-based approaches could actually help with the issue of becoming too dependent?

I find that the tight integration with providers like Azure, AWS, or CloudFront can make switching between them a very costly upfront decision.

Another disadvantage of serverless is that it’s quite challenging to produce an on-premises or enterprise-ready codebase if the need suddenly arises.

Being able to run things locally (like this post describes) is the only way anything should be accepted.

Or you can upload a cgi script to a web host like hetzner, then you have “serverless” too.

I think lambdas work really well for doing things as a reaction.

So for example, uploading an image to s3 could trigger a job, or having them run in parallel on a job queue since they theoretically scale way better then spinning up lots of 'job processors' to deal with influx.

One of the most fringe but interesting usecases I'm aware of is it being suggested as part of co2 (and cost) reduction. The main idea is that since lambdas only run the exact amount of time needed, we don't continue running/reserving costly machine time. This is still something where research is being done and does mostly pass the responsibility to the infrastructure / PaaS solution though

Here's a strong opinion semi-loosely held:

The fundamental difference between functions-as-a-service and just deploying to a damn server is that you get the ability to scale very quickly.

Our app has a feature which is very demanding but used infrequently. We can split the workload and spin up dozens of lambdas instantly to provide acceptable response times. Wouldn't want to have a server over-provisioned to handle that amount of scale at all times.

All the other purported benefits (e.g. you can plug Lambda into S3 events) are just ways to do vendor lockin to yourself. And the ops-less-ness is cool but also you could deploy to a container platform for that.

I could have done with this a while back. Seems much nicer than serverless framework.

I haven't developed in this space for a while so I'm just curious - which framework(s) are you referring to that this could have replaced?

Almost certainly this one https://www.serverless.com/

This doesn't really replace serverless framework though, only the serverless offline plugin (which is admittedly pretty dodgy).

Reply on news.ycombinator.com