3 ms·
The first post also misses something fundamental about modern software: servers programming is becoming more browser-like. > Node is not ECMAScript in a server
by dcposch 5y ago
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.
- kaba0 5y agoYour 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
- chrisweekly 5y ago"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?
- kaba0 5y agoA 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.
- catlifeonmars 5y agoAt the end of the day, most web servers are about serving requests. A short lived function model fits that more closely.
- kaba0 5y agoSo 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.
- chrisweekly 5y agoTo answer your (intended-to-be-rhetorical) question: yes! NextJS webapps deployed to Vercel / AWS lambdas have excellent performance characteristics.
- catlifeonmars 5y agoLambda 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 :)
- kaba0 5y ago
- akra 5y agoThere'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.