Comment by dcposch | Hacker News Reader

Comment by dcposch | Hacker News Reader

Parent Full thread

The first post also misses something fundamental about modern software: servers programming is becoming more browser-like.

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit

And what makes V8 a "browser JS engine"? A focus on:

- rapid startup. Code starts running immediately, JITs quickly. The VM is designed for latency, not just for throughput.

- excellent sandboxing. The VM is designed to run untrusted code.

- no blocking code. Designed for callbacks and promises. No threading, no thread.sleep(), no mutex, etc. Makes is much easier for non-expert developers to write fast & reasonably correct code.

Now look at things like Cloudflare Edge workers, Lambda etc. Modern server environments share all of those same design goals.

Server-side JS/TS not only has the advantage of a single codebase. It also brings the design and engineering advantages of a browser VM to the server.

Your examples doesn’t really read as a prototypical server application.

Rapid startup: lambda is a tiny subset, and not really server application. A server app could take minutes and would still be okay, because they are designed to run for a long time. Even in case of scaling minutes are more than okay since deploying a new instance takes a similar amount of time.

excellent sandboxing: you usually only run your own code connected to db and other very privileged services. If there is a vulnerability it is a very big problem with or without sandbox

no blocking code: i’m not up to date, but node doesn’t have a strong parallelism story at all, compared to the JVM, Go, .NET

"A server app could take minutes and would still be okay, because they are designed to run for a long time."

Wby would you want to maintain a long-running server process if you don't have to? And, wny do you think you have to?

A typical most basic website, awaiting requests and serving static/dynamic content is not a short-living process, I don’t see what is controversial about that.

At the end of the day, most web servers are about serving requests. A short lived function model fits that more closely.

So you think starting up a whole process, establishing connections to a db and serving the request would have any sort of acceptable latency and/or throughput? At that point, you could write your server in bash as well.. also, I think it would be ridiculously expensive.

Lambda is great for seldom run functions, like running some analysis/conversion on user uploaded profile pictures or the like.

To answer your (intended-to-be-rhetorical) question: yes! NextJS webapps deployed to Vercel / AWS lambdas have excellent performance characteristics.

Lambda containers serve multiple requests. You just write the code as if you were handling a single request. And on the contrary, Lambda latency is worst when you have spiky traffic patterns (such as for a seldom run function). Of course, if you can tolerate the cold start latency overhead, Lambda is also a cost effective solution for those seldom run functions.

Also, specifically for Aurora, Lambda supports transparent connection pooling. It is just no longer a concern of your application code.

Disclaimer: I work on serverless services at AWS. I’m definitely biased :)

Thanks for the correction! My point was not at all to “bash” Lambdas, just to point out the (in my opinion) incorrectness of grand(grand?)parent’s comment.

Though I suppose Lambdas don’t use separate traditional OS processes to serve requests, do they?

"[A long-running, traditional server process] awaiting requests... is not a short-living process."

That's an irrelevant tautology; the question was why you believe a long-running traditional server process is necessary.

There's many reasons why you would want the server, and reasons why you may not want it. Data structures and algorithms that as you scale give you an edge in the specialized problem domain you are in is usually one that I've seen. How many services have I've seen deployed that scale the DB to many cores and CPU's just to avoid some startup time? This is a problem I sadly see in a lot of Node stacks, and its easy to look good when you write a simple component to replace all that complexity and costs decrease as a result.

Most of the "serverless" things delegate to a server in the end anyway - whether they be a database, a managed service, etc. Something has to stay alive, be a server and own the state after all - serverless doesn't make the problem go away just passes the buck. For run of the mill small scale websites or websites that fit a particular paradigm lambda works fine. But it doesn't suit all apps, and its hard to make all problems fit it currently. As businesses scale custom solutions can scale better.

Reply on news.ycombinator.com