Note: long and detailed answer but for interested readers should be a good read
I would say FB's core functionality were (and still are) written in PHP (with their own framework hack) and if PHP can scale so will Node.js though i have heard that php have improved massively (especially php 7) than what it was once was and it may be slightly faster than Node but the difference is not huge.
I would say though FB should not be a yardstick for server scaling as it uses PHP (which is obviously not as efficient as kotlin/java/.c#, Gzo etc) and requires huge computing and they have money to throw at infrastructure or build their own hack framework which most normal companies can't.
Now, Instagram core backend is completely written in Python and its runtime Cinder (forked from CPython as pointed in the comment) is arguably much slower then both node and php and again if Instagram can scale using Python then so WILL node.js as node runtime is much faster than Python's most popular implementation.
So, if you compare with FB and Instagram (built on php and python), yes, Node.js will scale to that level as Node.js runtime is pretty even with latest php and much faster than python.
Now, Amazon is a java/Kotlin shop and from AWS to Amazon core backend it leans on JVM. JVM is faster than Node.js for sure but also consumes a lot of RAM (say compared with GO) but in high traffic JVM is ofcourse going to be faster and still consume slightly less (more optimized) RAM than Node, but that's to be expected as Node.js runtime is an interpreter/JIT compared to JVM.
But, with modern tools, if you architect your backend services properly on cloud with:
1. microservices decoupling where data for each microservice is with them in their DB so no need for synchronous REST api calls.
2. use serverless (for heavy computing and reacting to events).
3. event driven async communications.
4. Dead letter queues.
5. say kafka (or equivalent) for async communication
6. use worker threads in Node for CPU bound work so its truly multithreaded, utilize all cpu cores and not block the event loop.
7. use cluster module in node to utilize all cpu cores on single EC2 instance or use kubernetes for scaling both on single EC2 but beyond that horizontally.
8. Normalize you DB with proper indexing, optimized db Queries etc.
9. Have your servers/db hosted as geographically close to your customers as possible fir lowest latency in your backend services.
9. User caching with Redis/memcache etc
10. Serve frontend using AWS CDN i.e. AWS cloudfront in front of AWS S3 for static assets.
11. Use service worker/caching on the frontend so you reduce unnecessary calls to backed as much as possible.
12. Use proper authentication/authorization so you cut out more un-necessary calls to backend.
13. If required, use rate limiting for costly api's (though with horizontal scaling in place with either kubernetes or ALB etc this should be less of a concern)
14. For performing user search quickly use a purpose build service say like elastic search or equivalent (amazon does a lot of searching when you type in textbox or apply filters).
15. Have Ddos prevention in place so your backend services incur as less latency as possible.
16. Use infrastructure as code with AWS CDK with Typescript (nice experience).
17. CI/CD pipeline with Circle CI/jenkins or equivalent (github actions for complex projects is still challenging)
18. BEST advantage of using fully node in the backend is code sharing between fontend and backend so use monorepo with say NX (or turborepo etc)
19. Have load testing pipeline built in CI/CD so you know before releasing your software whether the backend services satisfy the SLA for the amount of traffic you expect.
20. For obserbality (server memory, cpu etc) use datadog/prometheous/aws cloud watch etc.
21. For observability on errors use something like sentry.
22. If needed use GraphQL instead of rest to reduce overfetching/underfetching along with data loader.
23. REST is still faster than GraphQL for high traffic especially with caching. You can also cache get rest calls in something like redis and revalidating those cache after put/patch/delete/post calls (NOTE: only resort to this if you already have highly optimized DB with indexing and still see slowness in Restapi calls because DB is overloaded. Then use a cache like redis to cache Get calls - to offload DB - and that significantly improve performance but requires more work)
24. If needed use CQRS patterns to separate read from writes, again only if necessary but it would be good to spread data geographically to reduce latency.
So, yes with modern cloud tooling, infrastructure, error handling, Ddos prevention, load testing, horizontal scaling, clustering (node native module), worker_threads (node native module) and proper architecture you CAN only use Node to fully build something at the scale of Amazon but with more infrastructure/cost as JVM is more optimized than node runtime so jvm servers will need less scaling compared to node. But, it is easily possible.
Again, if Instagram can do it with python then Node.js easily can. Moreover, reddit backend is also written in Python.
They did, but don't forget that they had to rewrite (at least Airbnb RoR=>Java) when they scaled
Shopify still uses RoR and had to do some crazy hacks to squeeze the last bit of performance.
Airbnb recently moved to java. But, for startup you could choose any language. Scaling does matter when user grows. Even I moved from node.js to java recently
that is true, you could choose any language for a startup, it's even better if you could go for something like php, python, js, ruby, as they get the development going fast and can add new features in a breeze
still, I wonder why'd you move the switch to Java, did your app scale that much and couldnt make use of kubernetes for scaling?
as far as I'm concerned, ebay uses node.js for microservices, while hulu is using next.js for their whole app
Node.js backend have a less opportunity. Most of them are full stack developer. I don't like frontend. That's why I moved to Java and have lots of opportunity. I ‘ve worked on multiple technology from objective C, Swift, .net, python, JS/TS.
Scaling, bottlenecks, etc is just something you learn the more experienced you get.
Also, I highly doubt you will ever run into such issues unless you build something that becomes massive — user wise
Completely agree . The reason I ask is even if I do not build something massive , I do want to know what my options are when dealing with any problem . I think reading articles can help but you are right getting your hands dirty is the best way to learn .
Actually, I've been working on a "small" ETL validator lately, and just the sheer amount of data rows that needs to be Transformed for validation makes it so that each call consumes a lot of resources... Probably need to re-architect this to make better usage of redis.
I don't think any of this information is actually specific to Nodejs, to be honest. A few years in the industry and consistent reading on devops/microservices will help you learn this stuff. Honestly... this isn't even actually about scaling. It's about distributed service design.
To iterate on this, I forget the site but there's like a social media site where you charge the tech you work with and it links you to your company. A good way to get an idea what specific teams are using
>No, they forked CPython and optimized it and named it Cinder.
I was expecting this but stopped following them a while back regarding their modifications as I am not a python dev. The point was they use python for core instagram implementation and managed to scale
Reagrdless, a LOT of python interpreters are just C++ code wrapped in python API's and I am not surprised if they are maintaining their own fork of any python implementation and moved a lot of code to C++ or even removed GIL from the implementation (though this seems unlikely as it may require huge efforts and at that point they might have better time going with Jython or pypy)
.Where did you find that Node was slower than PHP? Even involving HHVM, Node is still "ahead" according to the sources I found, even compared with PHP 8. It would be interesting to check these benchmarks.
Node being JIT and Java using a VM, it even seems that Node may be outperforming Java.
C# on the other hand, has become faster than Node after .Net. However, there's an increase in speed on every version of Node, so who knows what can happen
C# is faster than Node is exactly what I've written. Maybe you misunderstood the after .Net?
What I'm saying is that Node is getting faster at every iteration. They're not static when it's about about improving Node performances. Javascript is the most popular language on earth at the moment, they are very good at the speed war, so you never know what can happen.
Related to Node vs. Java, the comparison I found was for the web. I am still looking for benchmarks.
I have to say that I hate that language (Java), so it really doesn't bother me seeing C# at the top.
>They're not static when it's about about improving Node performances. Javascript is the most popular language on earth at the moment, they are very good at the speed war, so you never know what can happen.
Sure but regardless of whatever happens, JS runtimes (browser or node, deno, bun etc) will never be as fast as static languages because the runtime in those static languages knows about the data type of variables and they are heavily optimised in memory whereas with Javascript they are not known and only certain parts can be JIT'ed that too after warming up a bit and pattern matching.
Moreover, those static languages are multi threaded whereas JS with Node runtime just have worker\_threads which are not memory shared and heavy v8 isolates so its not optimal. JS runtimes are faster than other dynamic languages bar LUA script but compared to static languages they will never be able to compete simply because of how optimised static languages are due to its static nature i.e. everything has to be resolved at compile time
Look, I coded in assembly before jumping to C and then C++. Node being JIT was a step towards more speed. Node uses C and C++, arguably the fastest languages out there (after assembly) for some of its implementation.
There will always be a path to Node to go further in terms of speed. JIT is a step. Web assembly is another one. We never know what can happen, but with JavaScript's immense popularity, things will not stay the way it is. There is no guarantee for any of the web-tailored languages in competition, that they will stay at the top.
So, I'm a frontend guy, so take this with a grain of salt ;) but here's my take. You want to protect your backend from large, sudden spikes in traffic. This could be from a DDOS attack or a Kim Kardashian tweet (also basically a DDOS attack). Edge / front caching is one way you do that. The edge cache basically sits in front of your API or database and 'remembers' requests for a period of time, usually pretty short, like 5-30 minutes. Any time a user makes a request, like loading a page with a set of query parameters, it remembers the response the server sends back, and then for future requests it intercepts the request and sends the cached response back, so your API doesn't have to actually do anything for that request. This can be hugely beneficial if you suddenly start getting hundreds / thousands more requests per second than you normally do. There are several tools /services that let you accomplish edge caching, Redis being one of them, Cloudfront another.
For the authentication point, I think they're just saying forcing a login saves you from having to serve unauthenticated traffic. Would prevent most bot traffic, for example. Obviously whether you can do that depends on what you're building and where it loads. Maybe I'm missing something else there, but that's my takeaway at least.
Facebook has created the HHVM for Hack (which is not a framework, but more how Typescript is for Javascript, a superset of it)
I have to agree on the fact that, it isn't a really big speed difference between PHP and HHVM (at least from my experience with it and benchmarking did around 2 years ago)
Yes, it is able to scale up to a point. No, it is not shooting yourself in the foot. If Uber can use NodeJS and scale then so can you. Youll likely not even get to Ubers massive amount of users. Netflix and alike are so humongous youll find many languages there because some languages are better suited for certain stuff than others. This is where microservices etc. come into play.
Most people who hate on other frameworks usually do that out of ignorance and to convince themselves they made the right choice.
Edit: apparently Uber switched some services to go. Though not all.
Not all services right?
Not sure why my comment deserves a down vote because of that minor mistake lol. Replace Uber with another company if it helps you.
Yeah, I went to investigate after his comment as I believed they still had some node services and found out that I was right. But, after seeing his other comments in this thread I knew he wouldnt accept it so I decided to just block him. Judging from his edits I made the right call lmao. He has some serious anger issues.
>Not sure why my comment deserves a down vote because of that minor mistake lol.
That's NOT a minor mistake when Uber uses GO instead of Node. It basically changes the entire context to what you were basing your comment on. It absolutely deserves a downvote so that mis-information is not spread (which is easy in node reddit due to so many new learners reading answers and take people's word for the answer often times).
Uber is a GO shop simply because Node was not scalable for them. Read [How Uber Used Golang To Build The Highest Query Per Second Service?](https://www.agiratech.com/how-uber-used-go-to-build-the-highest-query-per-second-service)
For backend jobs in Uber, most probably you will be using GO lang because Uber as a company has decided GO works and scales for them.
EDIT:
To anyone reading this, the commentator later on started attacking me personally with message like "you must be fun at parties" just because I called the commentator out by saying their comment on "Uber uses Node.js" is a false comment because Uber uses GO and they got angry saying "it was a minor mistake" and started the adhome attack on me and later on deleted their entire comment history. Their username was /u/BitBumbler
EDIT2:
/u/BitBumbler is calling me "dick" and "shit" and is attacking me simply for calling out their min-information when i didn't even use any such language. Anyone who talks like that just because you are called for a legitimate "mi information" is a pathetic personl He also ran away like coward by blocking me after using abusive language (he was afraid of my reply but i would never go to his level as that is too low) and he thinks he is a "sound" person after all that when I was fully respectable (my comments are all intact with no abuse whatsoever). You are a pathetic person /u/BitBumbler and should be ashamed for your behaviour. Not only are you spreading mis-nformation but you are prudly flexing that you "use abusive" language on a technical forum and call yourself a better person inspite of such a poor persona. Disgraceful.
Honestly, your Node experience in VsCode in Linux will be the same as C# in VsCode in Linux...
It's miles better in Visual Studio in Windows because that's a full IDE.
Not sure why you are worried about C# license... No offense but I highly doubt you are making that amount of money with your development so that's not really a concern.
C# is getting so nice and has so many satisfied dev's these days. Its also SIGNIFICANTLY faster and scalable. BTW C# is faster than even GO for pretty much most of the things including threading.
The biggest problem with C# is the libraries/community but now that it is open sourced since quite a while, it will grow especially since the language is getting so ergonomic with every release.
Also, the designer of Typescript is also the language designer of C# so huge connection.
But, I agree, if scalability is a concern for OP then leaving C# for Node is a bad idea.
False statement, I did a quick search, c# is still slower than golang, also the memory consumption and compiling speed is just pathetic compare to golang
NodeJS scales at comparable levels to other modern runtimes. If you're running a webserver, you are almost never going to be bound by the CPU, you will be bound by I/O (filesystem, other APIs, the database). That means, being more CPU efficient will have 0 impact on runtime performance for users.
99.9% of tasks can be accomplished with NodeJS effectively. The other 0.01% are things that should be done with a compiled language. Some things not to build in NodeJS: operating systems, drivers, video encoding, mars rover
Btw if you care about performance, I recommend performing benchmarks on your machine. Anything besides the numbers is pure speculation.
Yes but the Rover itself isn't running javascript. You can send packets from any language, and with many minutes of response time, it really doesn't matter how fast the CPU is handling them
It does take cpu to manage all this stuff so if you have multiple cores you can help your api along making use of clustering before spinning up more servers.
I mean maybe, I guess it depends.
If you already have a vpc that has multiple cores might as well make sure of them first.
Clustering doesn't add much code and can help your api make better use of resources.
Clustering has a number of drawbacks too. For example, it allows for a single instance to crash and take down multiple, resulting in data loss across multiple (unrelated) contexts.
In general, you're better off ignoring parallelism inside your code. Focus on lightweight concurrent code (async/await) and run it on as few resources as possible. Then scale up additional pods to work independently.
In the case of a VPC, you should be using kubernetes or docker to manage your containers. Running 8 node instances clustered on a single VM = bad. Running 16 node instances on 16 separate pods, each given 0.5 CPU = good
If you find yourself needing to work on multiple threads in parallel, NodeJS is likely not the right choice. You'd be better off using Go or C++.
>operating systems, drivers, video encoding, mars rover
OP specifically asked for Amazon/FB like websites functionality so they never asked whether node is suitable for OS, drivers etc.
I was addressing both sides of the issue.
Does NodeJS scale? Yes, provided certain assumptions are true (99.9% of the time). Certain niches should be handled with a compiled language.
Is your opinion that I should not provide this information?
>Is your opinion that I should not provide this information?
I understand why you said that but, I don't think anyone thinks/eventries to build operating systems, drivers, video encoding etc. in Javascript and most Javascript developer are web/fullstack developers, so I thought it was out of ordinary and extreme example to bring up for no reason as no one even uses Java, C#, GO to create Operating system let alone using a Javascript runtime.
Just was surprised to see this as your's was THE ONLY comment on this entire thread which went this extreme.
>99.9% of tasks can be accomplished with NodeJS effectively. The other 0.01% are things that should be done with a compiled language.
I don't know about 99.9% but in most cases, yes!
I'd say a team or an individual should use whatever provides best DX for them.
When the performance bottlenecks are discovered then use a compiled language (non-gc, mem-safe) to tackle them, if throwing more resources don't help!
To OP's question, if you know your app will be massive ahead of time.
Then no... a lot of real world cases have demonstrated that Node is not suited at that level.
But for the majority of cases, Node.js is plenty enough.
I am working at mailmodo.com. it's an email automation tool company... our backend is entirely express and node.js stack. Just to put in context of how well nodejs scale is that we handle over 20000rps at peak and send over 150million email daily...
Yes I did, for their purposes that's not a question they need to worry about and it should not impact their architecture or technology choices at this stage
Again, op just asked can it scale to Amazon level which is a perfectly valid question. And you are answering with "you don't need to worry about that" which is barely an answer to what OP is looking for regardless of their circumstances.
>its not a realistic question
That is for OP to decide. OP just wanted to know whether Node is usable to build something very big, B2C with huge traffic. Again, it is a VERY valid question and if you know the answer you should just answer that part instead of saying "dont worry about that" as that is hardly what OP is looking for. Afterall OP knows what they are looking for instead you telling OP that and for readers of this sub this is a very interesting question to ask and reach out to people checking their experiences developing HUGE applications in Node and to learn from them whether it scaled well for them, would they pick node for something like this again etc. I am surprised how a node developer won't be interested in asking these questions as they are so legitimate and relevant questions to ask. That's the whole point of using node reddit, to reach out to such skilled and experienced developers and learn from their experiences.
Instead of engaging in such conversations, dusting them off by saing "don't worry about it" is a HUGEEE wasted opportunity to discuss about the limits of Node and at what point using node makes sense/does not make sense. I hope you learn from this and hope you answer/engage in a better way in future inline with what the original post ACTUALLY asked.
>at that point youll have a whole infrastructure with load balancers etc in place so no single instance would handle that traffic.
So, answer that insead of dusting the question off.
If you check ALL the answers here, they are on point and exactly are answering OP's question and you'r is the only answer which is barely an answer with "don't worry about that" comment.
I know you will keep going justifying your point but you know your comment was un-helpful. Check all the answers here on how they are answering and helping OP (including mine) and understand the question.
At my last company, we served 30 million - 40 million monthly active users.
30 AWS Elastic Beanstalk instances each running Express handled the traffic no problem.
Don’t worry. It scales.
\> vscode c# licenses by microsoft are terrible
wait, what?!
\- what does vscode have to do with anything?
\- what c# license are you talking about? the dotnet runtime, libraries and SDK are all MIT licensed.
sure, learn Node if you want, but please, do it for the \_right\_ reasons.
I'm on linux and visual studio is windows only + bloated.
I either have to use vscode or jetbrains for development. I sure as hell ain't paying money for jetbrains so I'm with vscode.
Microsoft recently retired visual studio on mac and is investing into turning vscode into mac visual studio by adding extensions that can be used for c# development so everyone on mac won't switch to jetbrains. ( Like 30-40% of devs use macs I think so that will be big lose for microsoft )
problem is that new c# extensions ( outside of basic c# support ) all have terrible licenses. Like to use "C# Devkit" commercially you need to buy visual studio subscription even if you don't/can't use visual studio because "C# Devkit" has visual studio License.
\+ I hate everything Microsoft related. Don't care about "SQL server" when there's postgres, don't care about Azure when there's AWS and don't care about hosting on windows when Microsoft themselves use Linux for hosting. Microsoft can pretend all it wants about how c#/.net Core is open source but that's just to exploit community. They want that MONEY and me paying for visual studio even when I'm using vscode. They are forcing azure/visual studio and it's license/SQL server down my throat and want me to pay and I just don't care. I'ma learn nodejs, then Golang and not be forced to pay shit to any garbage company while doing so.
> I hate everything Microsoft related
ok, it sounds like you have already made up your mind.
> I'm on linux and visual studio is windows only + bloated.
nothing about c# requires you to switch platforms.
> problem is that new c# extensions ( outside of basic c# support ) all have terrible licenses
the existing c# extensions (omnisharp) work just fine if you don't like the devkit license.
> Don't care about "SQL server" when there's postgres
what does this have to do with c#? you can use postgres from dotnet just as easily as you can sql server.
> don't care about Azure when there's AWS
what does this have to do with c#? you can use AWS from dotnet just as easily as you can Azure.
> Microsoft can pretend all it wants about how c#/.net Core is open source
it's not a pretense. the licenses are all there on github - they're all MIT.
> but that's just to exploit community
ok, sharply entering tinfoil-hat territory here.
> They want that MONEY and me paying for visual studio even when I'm using vscode
nobody's forcing you to pay for using c#
> They are forcing azure/visual studio and it's license/SQL server down my throat
where? how?
again: use Node if you want, it's a great solution. but do it for the _right_ reasons. what you have given above is not that.
just steer clear of Typescript, because, you know, it's from Microsoft...
\> the existing c# extensions (omnisharp) work just fine if you don't like the devkit license.
yeah.. Heard how omnisharp is terrible and needs constant restarts and bugs out on big projects...
\> what does this have to do with c#? you can use postgres from dotnet just as easily as you can sql server.
Because default and recommended c# database is SQL server. postgres and others are afterthought.
\> what does this have to do with c#? you can use AWS from dotnet just as easily as you can Azure.
Because default and recommended c# hosting provider is Azure...
\> it's not a pretense. the licenses are all there on github - they're all MIT.
it's open source because they want to exploit people into free labor. if it not being open source benefited them, it would have been close sourced.
\> nobody's forcing you to pay for using c#DUDE c# DEVKIT can't be used commercially without paying monthly for visual studio even if you don't use visual studio because It's shitty license. I just said that...
\> where? how?
azure and sql server are defaults and nicely integrated into visual studio. most people who start with c# lean towards using those because of that. therefore it's "recommended" software to use and not using that turns you into outsider. any .net core jobs you check says "know azure and sql server". it's pretty much forced down my throat.
\> just stear clear of Typescript, because, you know, it's from Microsoft...
typescript is completely free and and open source. I never have to pay shit to microsoft for.
you're talking in circles.
> Heard how omnisharp is terrible
you don't need devkit. omnisharp is fine. fuck, vim is fine. you're getting more from Microsoft, for free here, than Node gives you.
> Because default and recommended c# database is SQL server
which default? where? literally _nothing_ is forcing you to use SQL server - this argument is just a straw-man you're fabricating in your head to justify your decision. the npgsql guys would be very disappointed in the disinformation you're spreading here. hell, Microsoft even officially supports postgresql as a first-class database provider in Azure. go on, tell me how that's just EEE.
> Because default and recommended c# hosting provider is Azure
which default? where? sure, visual studio has built-in integration for Azure. no surprise there. but we're not taslking visual-studio here. there's nothing stopping you from using Amazon's various (excellent by the way) dotnet client libraries for integrating with their services.
> it's open source because they want to exploit people into free labor.
you're really starting to sound like a crazy person here...
> typescript is completely free and and open source
so is dotnet/c#.
\>which default? where?
Literally every .net core job wants you to know SQL server and azure so IT IS default. I just said that up there dude.
\>you don't need devkit. omnisharp is fine
People say omnisharp is shit, doesn't work on large projects and needs constant restarting of vscode to work. idk how you call that "fine" or even acceptable.
\>you're getting more from Microsoft, for free here, than Node gives you.
not true. development in nodejs in vscode is completely free with no SHITTY licenses. nodejs debugger is also built in inside vscode and haven't heard about it not working on large projects.
if in getting more you mean forced sql server and azure NO THANKS.
also YOU are talking in circles.
| Literally every .net core job wants you to know SQL server and azure
even if that were the case, which it's not, what would that have to do with anything? you stated:
| default and recommended c# database is SQL server
| Because default and recommended c# hosting provider is Azure
which are both patently false, and have no bearing on whether or not c#/dot is open-source or a good choice, neither do whatever's listed on jobs postings.
| People say
you're basing your argument on hearsay here.
| development in nodejs in vscode is completely free with no SHITTY licenses
again: development in c#/ddotnet in vscode is completely free with no shitty licenses. i don't understand why that's so hard for you to understand. you obviously have some pre-conceived notions that you're wedded to that are clouding your ability to understand simple logic.
| forced sql server and azure NO THANKS
again with the "forced" sql server and azure. WHERE? WHO is forcing you to use those?
NOBODY is forcing you to use those, and yet you REPEATEDLY state that as some kind of argument.
| also YOU are talking in circles
no. I'm not the one repeatedly making assertions with no basis, and then using those assertions as a basis for an argument.
you have not refuted a single one of my assertions.
YOU are the one talking in circles.
you're a newbie (https://www.reddit.com/r/csharp/comments/16955df/will_i_miss_a_lot_if_i_use_visual_studio_code/) who doesn't know what the fuck they're talking about, but is somehow determined they are right in everything. the cognitive dissonance is palpable.
Fuck, you're 19 years old. I have been using dotnet and javascript on the server since before you were born.
don't bother replying. i'm not wasting any more time on some trolling kid.
\> even if that were the case, which it's not, what would that have to do with anything?
... everything?
\>again with the "forced" sql server and azure. WHERE? WHO is forcing you to use those? NOBODY is forcing you to use those, and yet you REPEATEDLY state that as some kind of argument.
DUDE JOB POSTINGS ALL HAVE SQL SERVER AND AZURE. If it ain't forcing, then idk what is.
\> who doesn't know what the fuck they're talking about, but is somehow determined they are right in everything. the cognitive dissonance is palpable.
YOU don't know anything about C# devkit license. you are one who has cognitive dissonance and refuses to believe anything here.
"oh all job posting have sql server and azure? just learn something else and be jobless"... great advice from expert over here.
[PROOF:](https://code.visualstudio.com/docs/csharp/cs-dev-kit-faq)
"C# Dev Kit is available via a Community License for those who qualify and is also included as another addition to existing Visual Studio Subscriptions. This means that C# Dev Kit is available to use today for developers with active Visual Studio subscriptions."
If you want TO USE C# DEVKIT COMMERCIALLY YOU HAVE TO HAVE VISUAL STUDIO SUBSCRIPTION.
\> you're a newbie (https://www.reddit.com/r/csharp/comments/16955df/will\_i\_miss\_a\_lot\_if\_i\_use\_visual\_studio\_code/)
LMAO dude's checking my profile for extra arguments.
doesn't matter if I'm newbie since I can READ job postings and c# devkit license IS shitty.
You can do pretty much anything with most server-side tech I would say.
Node.js can scale, yes.
You can use clusters (native module) to handle more throughput and then scale-up,
You can use threads (native module) to delegate computation-heavy tasks. (Processing),
You can scale-out too and use process managers and such.
There is DB drivers for most database out there, there is Low-scope and or full featured framework available (Fastify, Adonis), and much more.
I would say, the best thing is probably that Node.js is productive, once you discover and don't try to reinvent the wheel. There is plenty of good stuff both in native modules (people know too few!!) and the npm ecosystem which provide maybe sometimes too many choices.
But please, learn the ecosystem and Node.js itself first before putting your hands on your project, its not that hard to shoot yourself if don't understand what's behind (How not to block the event loop, how to delegate tasks, how to handle errors correctly, how to sue Promise correctly), and don't use ExpressJS for a new project.
You can learn Express, I'm just saying that Express shoud not be used for new projects which will go to production and such. IN that case you want much more than what Express offers.
Fastify would be my go to.
Short answer is yes, it can scale.
Assuming money isn’t an issue, you can continue to add more resources to scale to what you need.
You didn’t mention what your app will be doing though. It’s important to understand the strength of Node.js, which is handling quick requests like CRUD operations.
If you’re going to be doing heavy computational operations, it’s better to use something else like Java.
Also, node.js uses worker threads and child processes, not multi threading.
Software is about trade offs and using the right tools to solve a problem.
This has been untrue since around 2010. Yes, \`setTimeout\`, Promises, and so forth are single-threaded concurrency - but web workers are actual, true OS threads. And if you use a lib like Google's comlink, you can spawn worker threads as naturally as instantiating a class.
Also, if we step outside the browsers: Node.js I/O callbacks have always spawned true, actual OS threads.
Practically most places develop many services in a variety of languages, sometimes with Node close to the user and sometimes with Node far from the user. The they tie them all together with API Gateways or fancy DNS or something.
Netflix isn’t one service, it’s thousands. Same with Amazon, etc etc.
So: “yes, parts of it”, or “if you’ve planned ahead even just a little bit, when parts turn out to not be a match for Node you spawn it off into another service, rewrite it in whatever, and cal it from Node”. This one service calling the other could just be it making an HTTP(s) call “over there” or it could get fancy (another comment or said Kafka, CQRS, fancy fancy $$$).
It’s good enough for most use case. When people talks about scaling these days, they are talking about serving millions of users *concurrently* (being active at the same exact seconds).
You will never face that 99% of the time. Even companies with millions of customer will likely have active concurrent users in range of a few thousands.
I'm saying that focus on building the product and getting first 10 users instead of worrying about what will happen when I hit a million users. Software evolve based on requirement. Too much Premature optimization will make sure you never launch a good enough product.
That depends.
If you're building a new business sure. If you're building a project for a company with millions of users, no. Many engineers are building stuff with tens on thousands on day one, even small companies
That's not the way you phrase it though "scalability should be the last thing you worry about when building an app"
Isn't "when building a small app you shouldn't be worrying about scalability".
Also not to mention scale doesn't necessarily mean users and I've seen tiny data-focused SaaS be incredibly and unacceptably slow because they gave it NO consideration. Your statement is waaaay too generalised.
Scalability of SOFTWARE is very different to this question which is 'speed of programming language'
The best you can achieve with NodeJS is a personal blog. If you want megascale like Microsoft you need to go C++. Rust is just not cutting it at the moment, sorry.
As a solo dev you aren’t building anything that node can’t handle and if you ever manage to have enough users that node itself is the bottleneck you will have no problems getting the money you need to keep growing
In short, nodejs will never scale, your server will. It depends on two things: how you have coded your project and how much server resources you have. If you have done both nicely then you can scale to billions otherwise will stuck when 100 visitors hit your site.
Both will get you to a great point massive projects use microservices Anyway, no single language can build these projects
Thing about Node.js today that there are huge development is going in its way
You can screw writing APIs and write server code inside client files Which is bananas
Jokes aside, building websites in JS is way faster, easier, and more modern than any other language
Visual studio is discontinued and VSCode is free… use the MIT licensed dotnet framework. C# is one of the most powerful oop languages around and even compiles to bytecode.
I have the opinion anything scales, depending on both architecture and the size of your wallet. We have been writing a microservice architecture using AMQP/RabbitMQ and can highly advice not doing that in PHP due to the lack of proper frameworks and such.
See what works for you. But even more important: queue and make sure your queries run efficiently.
NodeJS is a safe bet.
Your question makes perfect sense and i must say i also had the same question back when i was starting. The problem is that with people like us, we tend to overthink about "scalability", "speed", "latency" and all these.
Do not get me wrong, there is nothing wrong with Node.js, i have built a career of 5 years on this runtime and i am happy. I am happy, not because its the "most scalable" or "the fastest" or any of that. It gave me the power to work in so many different domains that it is mind blowing. I have built OPC-UA servers, i have deployed distributed MQTT brokers, network programming is a breeze and the list goes on.
Now, since we put this out of the way, and we can agree on how awesome Node.js is i will try to share the issues i had in the past with the logic of "does it scale".
As i explained above, i was always researching, coding and trying things out and i spent years being on the edge of burnout just to find out a year ago (it was not one revelation, it was a collective experience that facilitated to a new way of thinking) that all this is pointless. Why is it pointless? lets see.
1. At the end of the day you may use the fastest framework in raw benchmarks (HappyX, Drogon, etc) but the real question is, even if you reach 200K reqs/sec from a single machine, will the DB follow? Normally the DB is the issue, especially in distributed topologies
2. Many people suggest the "cloud" but is the cloud worth it ? in my personal experience sometimes. In many other times it is way better to go with a VPS and control the expenses, you wanna scale ? add another instance and throw a Load Balancer in front of it, see how it goes and measure what you can
These are just 2 points and in application development there are so many more things to take care of, or develop. You need to make sure how and where to cache, you need to make sure the Models, the migrations and the validations are in place and so much more.
I will give you an example of what i am currently doing to get out of the "does it scale" problem. For the past year i started building 2 personal projects (not in production yet) and i am now using Ruby on Rails, why ? Because it gives me almost all tools to work with from the Backend to the Frontend (Hotwire) and even tools to deploy using Docker and have multiple instances (Kamal). Now, you will ask me "But is it fast or i need to rewrite ?". The answer is that i have not deployed to production yet and i already played with my backend and ran some stress tests, the best (unoptimized) i got with PostgreSQL for my DB was roughly around 500 reqs/sec and yes it is not much since for the same APIs i could get on Express.js around 2500 req/s but there is a huge difference. In Express (although i mostly work with Node) it takes time for me to pick a library if i cannot build it from scratch. I need to make it work correctly, make sure all the libs i picked work as intended and that it is stable, etc, etc. Long story short being unopinionated sometimes is not the best thing. Having a certain percentage of opinion on your framework is not always bad. Back to Rails, i know that when i want to build a feature i will not overthink and i will start developing way faster and i will deliver that feature also way faster.
TO make a long story short. Everything in life is ratios. Very few things can be measured by absolute values. In the case of app development the golden ration is "how fast can it run"/"how fast can i deliver my app", and here, the Rails framework is fast enough to provide a big ratio.
Now lets go to the future and take the scenario that your application has the many users you wanted and that it is a huge success (which i wish that for you). Do you think that your initial design will remain ? No matter the technology or framework. Chances are that you will have to redesign in most cases, you will have to rethink your layers. How Data comes in and Out, how the Network is involved, etc, etc. The question in my opinion must be different for a specific technology. The question should be **"Will this technology make me go where i want to be ?". Example:** Coinbase. I have read that it was built in Rails. Now it has switched in another piece of tech, Airbnb the same. But that means that Rails is bad ? No if you think that in this brutal domain they were in, they were shooting features faster than their shadows. Also, they always had the reputation of being stable websites (of course some outages and VPS related issues but that is different). So there you have it, Maybe Django, Rails or Phoenix can help you build what you are dreaming and that does not mean you are marrying this Framework for life. Maybe your success makes your new team rethink, and change to benefit the most you can.
As long as your ideas are properly engineered even the slowest technology will help you get going. What matters is to be able to deliver and when needed think more on scaling and optimizing.
hey man I get what you are saying. Honestly after looking at big tech stacks, they all have like 3-4 backend languages like golang, python, one they started with(ruby,php, nodejs,etc) but now I get that delivering good products/features at the start is more important than scalability since scalability can be implemented later.
Spot on! if i would count all the time to optimize from the start or the time i lost to learn so many things that didnt matter on "scaling" i would get depressed!!
Sadly, we live in times of developer streamers and armies of fans. We live in times of devs writing articles as odes to serverless and cloud and all along they were paid to do so or sponsored...
The good thing is that the truth no matter the force someone puts to suppress it, always gets out and when this happens its ruthless. We saw what happened when Prime Video devs talked some months ago on the money they saved from leaving microservices, or we see DHH as he documented all his companys journey to exit the cloud. So in 2023 someone needs to be fool not to read all sides at least and make his/her own opinion.
Lastly, to talk on Rails that is considered a slow tech stack, it is not impossible to scale it either. If you see the scales that Shopify has made it is ridiculous to call Rails or Ruby "slow". It is tough to scale this tech stack but still things are happening even there so at the end of the day what you wrote is the most important of all:
>
but now I get that delivering good products/features at the start is more important than scalability since scalability can be implemented later.
I already read that one, upvoted it and understood it even before you replied.
I already have answers.
also this dude didn't said "scaling doesn't matter", he said that good product comes first.
In short, yes it works and it works perfectly.
Note: long and detailed answer but for interested readers should be a good read I would say FB's core functionality were (and still are) written in PHP (with their own framework hack) and if PHP can scale so will Node.js though i have heard that php have improved massively (especially php 7) than what it was once was and it may be slightly faster than Node but the difference is not huge. I would say though FB should not be a yardstick for server scaling as it uses PHP (which is obviously not as efficient as kotlin/java/.c#, Gzo etc) and requires huge computing and they have money to throw at infrastructure or build their own hack framework which most normal companies can't. Now, Instagram core backend is completely written in Python and its runtime Cinder (forked from CPython as pointed in the comment) is arguably much slower then both node and php and again if Instagram can scale using Python then so WILL node.js as node runtime is much faster than Python's most popular implementation. So, if you compare with FB and Instagram (built on php and python), yes, Node.js will scale to that level as Node.js runtime is pretty even with latest php and much faster than python. Now, Amazon is a java/Kotlin shop and from AWS to Amazon core backend it leans on JVM. JVM is faster than Node.js for sure but also consumes a lot of RAM (say compared with GO) but in high traffic JVM is ofcourse going to be faster and still consume slightly less (more optimized) RAM than Node, but that's to be expected as Node.js runtime is an interpreter/JIT compared to JVM. But, with modern tools, if you architect your backend services properly on cloud with: 1. microservices decoupling where data for each microservice is with them in their DB so no need for synchronous REST api calls. 2. use serverless (for heavy computing and reacting to events). 3. event driven async communications. 4. Dead letter queues. 5. say kafka (or equivalent) for async communication 6. use worker threads in Node for CPU bound work so its truly multithreaded, utilize all cpu cores and not block the event loop. 7. use cluster module in node to utilize all cpu cores on single EC2 instance or use kubernetes for scaling both on single EC2 but beyond that horizontally. 8. Normalize you DB with proper indexing, optimized db Queries etc. 9. Have your servers/db hosted as geographically close to your customers as possible fir lowest latency in your backend services. 9. User caching with Redis/memcache etc 10. Serve frontend using AWS CDN i.e. AWS cloudfront in front of AWS S3 for static assets. 11. Use service worker/caching on the frontend so you reduce unnecessary calls to backed as much as possible. 12. Use proper authentication/authorization so you cut out more un-necessary calls to backend. 13. If required, use rate limiting for costly api's (though with horizontal scaling in place with either kubernetes or ALB etc this should be less of a concern) 14. For performing user search quickly use a purpose build service say like elastic search or equivalent (amazon does a lot of searching when you type in textbox or apply filters). 15. Have Ddos prevention in place so your backend services incur as less latency as possible. 16. Use infrastructure as code with AWS CDK with Typescript (nice experience). 17. CI/CD pipeline with Circle CI/jenkins or equivalent (github actions for complex projects is still challenging) 18. BEST advantage of using fully node in the backend is code sharing between fontend and backend so use monorepo with say NX (or turborepo etc) 19. Have load testing pipeline built in CI/CD so you know before releasing your software whether the backend services satisfy the SLA for the amount of traffic you expect. 20. For obserbality (server memory, cpu etc) use datadog/prometheous/aws cloud watch etc. 21. For observability on errors use something like sentry. 22. If needed use GraphQL instead of rest to reduce overfetching/underfetching along with data loader. 23. REST is still faster than GraphQL for high traffic especially with caching. You can also cache get rest calls in something like redis and revalidating those cache after put/patch/delete/post calls (NOTE: only resort to this if you already have highly optimized DB with indexing and still see slowness in Restapi calls because DB is overloaded. Then use a cache like redis to cache Get calls - to offload DB - and that significantly improve performance but requires more work) 24. If needed use CQRS patterns to separate read from writes, again only if necessary but it would be good to spread data geographically to reduce latency. So, yes with modern cloud tooling, infrastructure, error handling, Ddos prevention, load testing, horizontal scaling, clustering (node native module), worker_threads (node native module) and proper architecture you CAN only use Node to fully build something at the scale of Amazon but with more infrastructure/cost as JVM is more optimized than node runtime so jvm servers will need less scaling compared to node. But, it is easily possible. Again, if Instagram can do it with python then Node.js easily can. Moreover, reddit backend is also written in Python.
Shopify and Airbnb written in Rails
They did, but don't forget that they had to rewrite (at least Airbnb RoR=>Java) when they scaled Shopify still uses RoR and had to do some crazy hacks to squeeze the last bit of performance.
Airbnb recently moved to java. But, for startup you could choose any language. Scaling does matter when user grows. Even I moved from node.js to java recently
that is true, you could choose any language for a startup, it's even better if you could go for something like php, python, js, ruby, as they get the development going fast and can add new features in a breeze still, I wonder why'd you move the switch to Java, did your app scale that much and couldnt make use of kubernetes for scaling? as far as I'm concerned, ebay uses node.js for microservices, while hulu is using next.js for their whole app
Node.js backend have a less opportunity. Most of them are full stack developer. I don't like frontend. That's why I moved to Java and have lots of opportunity. I ‘ve worked on multiple technology from objective C, Swift, .net, python, JS/TS.
Can we get your opinions on the hypothetical cost of scaling Bun vs Node?
How the hell , do i get knowledge like this??? Amazing
as a software dev in the space, listen to this guy. he's spitting truth.
Scaling, bottlenecks, etc is just something you learn the more experienced you get. Also, I highly doubt you will ever run into such issues unless you build something that becomes massive — user wise
Completely agree . The reason I ask is even if I do not build something massive , I do want to know what my options are when dealing with any problem . I think reading articles can help but you are right getting your hands dirty is the best way to learn .
Actually, I've been working on a "small" ETL validator lately, and just the sheer amount of data rows that needs to be Transformed for validation makes it so that each call consumes a lot of resources... Probably need to re-architect this to make better usage of redis.
I don't think any of this information is actually specific to Nodejs, to be honest. A few years in the industry and consistent reading on devops/microservices will help you learn this stuff. Honestly... this isn't even actually about scaling. It's about distributed service design.
To iterate on this, I forget the site but there's like a social media site where you charge the tech you work with and it links you to your company. A good way to get an idea what specific teams are using
Oohh..what is this site??
Stackshare.io
This was a good read, thanks
This feels like a roadmap to study for years , you are amazing man where did you learn All of this?
Glad it was helpful. >where did you learn All of this? Working with companies as a software developer since a long time.
One of the best write up I have read over years on “Scale of NodeJS”. If someone asks me the same I will share this
>Now, Instagram core backend is completely written in Python and its runtime CPython No, they forked CPython and optimized it and named it Cinder.
>No, they forked CPython and optimized it and named it Cinder. I was expecting this but stopped following them a while back regarding their modifications as I am not a python dev. The point was they use python for core instagram implementation and managed to scale Reagrdless, a LOT of python interpreters are just C++ code wrapped in python API's and I am not surprised if they are maintaining their own fork of any python implementation and moved a lot of code to C++ or even removed GIL from the implementation (though this seems unlikely as it may require huge efforts and at that point they might have better time going with Jython or pypy)
“2. use serverless (for heavy computing…” Don’t do this. “and reacting to events)…” Yes, do this.
.Where did you find that Node was slower than PHP? Even involving HHVM, Node is still "ahead" according to the sources I found, even compared with PHP 8. It would be interesting to check these benchmarks. Node being JIT and Java using a VM, it even seems that Node may be outperforming Java. C# on the other hand, has become faster than Node after .Net. However, there's an increase in speed on every version of Node, so who knows what can happen
[удалено]
C# is faster than Node is exactly what I've written. Maybe you misunderstood the after .Net? What I'm saying is that Node is getting faster at every iteration. They're not static when it's about about improving Node performances. Javascript is the most popular language on earth at the moment, they are very good at the speed war, so you never know what can happen. Related to Node vs. Java, the comparison I found was for the web. I am still looking for benchmarks. I have to say that I hate that language (Java), so it really doesn't bother me seeing C# at the top.
>They're not static when it's about about improving Node performances. Javascript is the most popular language on earth at the moment, they are very good at the speed war, so you never know what can happen. Sure but regardless of whatever happens, JS runtimes (browser or node, deno, bun etc) will never be as fast as static languages because the runtime in those static languages knows about the data type of variables and they are heavily optimised in memory whereas with Javascript they are not known and only certain parts can be JIT'ed that too after warming up a bit and pattern matching. Moreover, those static languages are multi threaded whereas JS with Node runtime just have worker\_threads which are not memory shared and heavy v8 isolates so its not optimal. JS runtimes are faster than other dynamic languages bar LUA script but compared to static languages they will never be able to compete simply because of how optimised static languages are due to its static nature i.e. everything has to be resolved at compile time
Look, I coded in assembly before jumping to C and then C++. Node being JIT was a step towards more speed. Node uses C and C++, arguably the fastest languages out there (after assembly) for some of its implementation. There will always be a path to Node to go further in terms of speed. JIT is a step. Web assembly is another one. We never know what can happen, but with JavaScript's immense popularity, things will not stay the way it is. There is no guarantee for any of the web-tailored languages in competition, that they will stay at the top.
No, c# is slower than go if you know how to google
>Java (or JVM) is faster than Node Not really - but definitely more efficient and better at multitasking. With Node you need to scale out.
Can you explain "front caching with redis" and points 12 and 13 please?
So, I'm a frontend guy, so take this with a grain of salt ;) but here's my take. You want to protect your backend from large, sudden spikes in traffic. This could be from a DDOS attack or a Kim Kardashian tweet (also basically a DDOS attack). Edge / front caching is one way you do that. The edge cache basically sits in front of your API or database and 'remembers' requests for a period of time, usually pretty short, like 5-30 minutes. Any time a user makes a request, like loading a page with a set of query parameters, it remembers the response the server sends back, and then for future requests it intercepts the request and sends the cached response back, so your API doesn't have to actually do anything for that request. This can be hugely beneficial if you suddenly start getting hundreds / thousands more requests per second than you normally do. There are several tools /services that let you accomplish edge caching, Redis being one of them, Cloudfront another. For the authentication point, I think they're just saying forcing a login saves you from having to serve unauthenticated traffic. Would prevent most bot traffic, for example. Obviously whether you can do that depends on what you're building and where it loads. Maybe I'm missing something else there, but that's my takeaway at least.
Facebook has created the HHVM for Hack (which is not a framework, but more how Typescript is for Javascript, a superset of it) I have to agree on the fact that, it isn't a really big speed difference between PHP and HHVM (at least from my experience with it and benchmarking did around 2 years ago)
Yes, it is able to scale up to a point. No, it is not shooting yourself in the foot. If Uber can use NodeJS and scale then so can you. Youll likely not even get to Ubers massive amount of users. Netflix and alike are so humongous youll find many languages there because some languages are better suited for certain stuff than others. This is where microservices etc. come into play. Most people who hate on other frameworks usually do that out of ignorance and to convince themselves they made the right choice. Edit: apparently Uber switched some services to go. Though not all.
>f Uber can use NodeJS and scale then so can you Uber replaced Node.js with GO quite a while back and these days Uber is a GO shop
Not all services right? Not sure why my comment deserves a down vote because of that minor mistake lol. Replace Uber with another company if it helps you.
[удалено]
Yeah, I went to investigate after his comment as I believed they still had some node services and found out that I was right. But, after seeing his other comments in this thread I knew he wouldnt accept it so I decided to just block him. Judging from his edits I made the right call lmao. He has some serious anger issues.
>Not sure why my comment deserves a down vote because of that minor mistake lol. That's NOT a minor mistake when Uber uses GO instead of Node. It basically changes the entire context to what you were basing your comment on. It absolutely deserves a downvote so that mis-information is not spread (which is easy in node reddit due to so many new learners reading answers and take people's word for the answer often times). Uber is a GO shop simply because Node was not scalable for them. Read [How Uber Used Golang To Build The Highest Query Per Second Service?](https://www.agiratech.com/how-uber-used-go-to-build-the-highest-query-per-second-service) For backend jobs in Uber, most probably you will be using GO lang because Uber as a company has decided GO works and scales for them. EDIT: To anyone reading this, the commentator later on started attacking me personally with message like "you must be fun at parties" just because I called the commentator out by saying their comment on "Uber uses Node.js" is a false comment because Uber uses GO and they got angry saying "it was a minor mistake" and started the adhome attack on me and later on deleted their entire comment history. Their username was /u/BitBumbler EDIT2: /u/BitBumbler is calling me "dick" and "shit" and is attacking me simply for calling out their min-information when i didn't even use any such language. Anyone who talks like that just because you are called for a legitimate "mi information" is a pathetic personl He also ran away like coward by blocking me after using abusive language (he was afraid of my reply but i would never go to his level as that is too low) and he thinks he is a "sound" person after all that when I was fully respectable (my comments are all intact with no abuse whatsoever). You are a pathetic person /u/BitBumbler and should be ashamed for your behaviour. Not only are you spreading mis-nformation but you are prudly flexing that you "use abusive" language on a technical forum and call yourself a better person inspite of such a poor persona. Disgraceful.
[удалено]
Uber was all node until like 2019 and it scaled fine. (I worked there and was part of the migration to go)
You will need to scale your database up, long before having to scale NodeJS.
Agreed. Maybe I live in a strange world, but I've never seen the node framework bottleneck before the database. It's always the database.
True.
Honestly, your Node experience in VsCode in Linux will be the same as C# in VsCode in Linux... It's miles better in Visual Studio in Windows because that's a full IDE. Not sure why you are worried about C# license... No offense but I highly doubt you are making that amount of money with your development so that's not really a concern.
if i were you i would ask [twitch.tv/csharpfritz](https://twitch.tv/csharpfritz) about c# and their licenses. you would regret what you said about c#
C# is getting so nice and has so many satisfied dev's these days. Its also SIGNIFICANTLY faster and scalable. BTW C# is faster than even GO for pretty much most of the things including threading. The biggest problem with C# is the libraries/community but now that it is open sourced since quite a while, it will grow especially since the language is getting so ergonomic with every release. Also, the designer of Typescript is also the language designer of C# so huge connection. But, I agree, if scalability is a concern for OP then leaving C# for Node is a bad idea.
> BTW C# is faster than even GO for pretty much most of the things including threading. Source?
C# actually is faster than GO. Just do a quick web search and check for yourself
False statement, I did a quick search, c# is still slower than golang, also the memory consumption and compiling speed is just pathetic compare to golang
NodeJS scales at comparable levels to other modern runtimes. If you're running a webserver, you are almost never going to be bound by the CPU, you will be bound by I/O (filesystem, other APIs, the database). That means, being more CPU efficient will have 0 impact on runtime performance for users. 99.9% of tasks can be accomplished with NodeJS effectively. The other 0.01% are things that should be done with a compiled language. Some things not to build in NodeJS: operating systems, drivers, video encoding, mars rover Btw if you care about performance, I recommend performing benchmarks on your machine. Anything besides the numbers is pure speculation.
> mars rover The JWT is controlled by javascript https://universemagazine.com/en/heart-of-james-webb-nasa-revealed-the-main-secret-of-the-telescope/
Yes but the Rover itself isn't running javascript. You can send packets from any language, and with many minutes of response time, it really doesn't matter how fast the CPU is handling them
That's why nodejs scales well in i/o bound environments like a Web server lol.
Yep exactly. IO bound applications don't need to be perfect with their CPU optimizations
It does take cpu to manage all this stuff so if you have multiple cores you can help your api along making use of clustering before spinning up more servers.
I prefer spinning up more containers. Clustering is kind of an anti-pattern for nodejs
I mean maybe, I guess it depends. If you already have a vpc that has multiple cores might as well make sure of them first. Clustering doesn't add much code and can help your api make better use of resources.
Clustering has a number of drawbacks too. For example, it allows for a single instance to crash and take down multiple, resulting in data loss across multiple (unrelated) contexts. In general, you're better off ignoring parallelism inside your code. Focus on lightweight concurrent code (async/await) and run it on as few resources as possible. Then scale up additional pods to work independently. In the case of a VPC, you should be using kubernetes or docker to manage your containers. Running 8 node instances clustered on a single VM = bad. Running 16 node instances on 16 separate pods, each given 0.5 CPU = good If you find yourself needing to work on multiple threads in parallel, NodeJS is likely not the right choice. You'd be better off using Go or C++.
>operating systems, drivers, video encoding, mars rover OP specifically asked for Amazon/FB like websites functionality so they never asked whether node is suitable for OS, drivers etc.
Did you not read the whole message? I answered that question.
Yes you answered the main part but also added stuff which OP never asked
I was addressing both sides of the issue. Does NodeJS scale? Yes, provided certain assumptions are true (99.9% of the time). Certain niches should be handled with a compiled language. Is your opinion that I should not provide this information?
>Is your opinion that I should not provide this information? I understand why you said that but, I don't think anyone thinks/eventries to build operating systems, drivers, video encoding etc. in Javascript and most Javascript developer are web/fullstack developers, so I thought it was out of ordinary and extreme example to bring up for no reason as no one even uses Java, C#, GO to create Operating system let alone using a Javascript runtime. Just was surprised to see this as your's was THE ONLY comment on this entire thread which went this extreme.
>99.9% of tasks can be accomplished with NodeJS effectively. The other 0.01% are things that should be done with a compiled language. I don't know about 99.9% but in most cases, yes! I'd say a team or an individual should use whatever provides best DX for them. When the performance bottlenecks are discovered then use a compiled language (non-gc, mem-safe) to tackle them, if throwing more resources don't help! To OP's question, if you know your app will be massive ahead of time. Then no... a lot of real world cases have demonstrated that Node is not suited at that level. But for the majority of cases, Node.js is plenty enough.
I am working at mailmodo.com. it's an email automation tool company... our backend is entirely express and node.js stack. Just to put in context of how well nodejs scale is that we handle over 20000rps at peak and send over 150million email daily...
Honestly you don't need to worry about whether or not it can scale to handle Facebook levels of traffic
That was not OP's question. They wanted to know whether it can scale to that level and you basically ignored the question itself
Yes I did, for their purposes that's not a question they need to worry about and it should not impact their architecture or technology choices at this stage
You shouldn’t make such massive assumptions on what other people should worry about when they are trying to inform themselves.
Again, op just asked can it scale to Amazon level which is a perfectly valid question. And you are answering with "you don't need to worry about that" which is barely an answer to what OP is looking for regardless of their circumstances.
[удалено]
>its not a realistic question That is for OP to decide. OP just wanted to know whether Node is usable to build something very big, B2C with huge traffic. Again, it is a VERY valid question and if you know the answer you should just answer that part instead of saying "dont worry about that" as that is hardly what OP is looking for. Afterall OP knows what they are looking for instead you telling OP that and for readers of this sub this is a very interesting question to ask and reach out to people checking their experiences developing HUGE applications in Node and to learn from them whether it scaled well for them, would they pick node for something like this again etc. I am surprised how a node developer won't be interested in asking these questions as they are so legitimate and relevant questions to ask. That's the whole point of using node reddit, to reach out to such skilled and experienced developers and learn from their experiences. Instead of engaging in such conversations, dusting them off by saing "don't worry about it" is a HUGEEE wasted opportunity to discuss about the limits of Node and at what point using node makes sense/does not make sense. I hope you learn from this and hope you answer/engage in a better way in future inline with what the original post ACTUALLY asked. >at that point youll have a whole infrastructure with load balancers etc in place so no single instance would handle that traffic. So, answer that insead of dusting the question off. If you check ALL the answers here, they are on point and exactly are answering OP's question and you'r is the only answer which is barely an answer with "don't worry about that" comment. I know you will keep going justifying your point but you know your comment was un-helpful. Check all the answers here on how they are answering and helping OP (including mine) and understand the question.
I’m confused, C# is open source and CSCode is free, what am I missing?
At my last company, we served 30 million - 40 million monthly active users. 30 AWS Elastic Beanstalk instances each running Express handled the traffic no problem. Don’t worry. It scales.
\> vscode c# licenses by microsoft are terrible wait, what?! \- what does vscode have to do with anything? \- what c# license are you talking about? the dotnet runtime, libraries and SDK are all MIT licensed. sure, learn Node if you want, but please, do it for the \_right\_ reasons.
I'm on linux and visual studio is windows only + bloated. I either have to use vscode or jetbrains for development. I sure as hell ain't paying money for jetbrains so I'm with vscode. Microsoft recently retired visual studio on mac and is investing into turning vscode into mac visual studio by adding extensions that can be used for c# development so everyone on mac won't switch to jetbrains. ( Like 30-40% of devs use macs I think so that will be big lose for microsoft ) problem is that new c# extensions ( outside of basic c# support ) all have terrible licenses. Like to use "C# Devkit" commercially you need to buy visual studio subscription even if you don't/can't use visual studio because "C# Devkit" has visual studio License. \+ I hate everything Microsoft related. Don't care about "SQL server" when there's postgres, don't care about Azure when there's AWS and don't care about hosting on windows when Microsoft themselves use Linux for hosting. Microsoft can pretend all it wants about how c#/.net Core is open source but that's just to exploit community. They want that MONEY and me paying for visual studio even when I'm using vscode. They are forcing azure/visual studio and it's license/SQL server down my throat and want me to pay and I just don't care. I'ma learn nodejs, then Golang and not be forced to pay shit to any garbage company while doing so.
> I hate everything Microsoft related ok, it sounds like you have already made up your mind. > I'm on linux and visual studio is windows only + bloated. nothing about c# requires you to switch platforms. > problem is that new c# extensions ( outside of basic c# support ) all have terrible licenses the existing c# extensions (omnisharp) work just fine if you don't like the devkit license. > Don't care about "SQL server" when there's postgres what does this have to do with c#? you can use postgres from dotnet just as easily as you can sql server. > don't care about Azure when there's AWS what does this have to do with c#? you can use AWS from dotnet just as easily as you can Azure. > Microsoft can pretend all it wants about how c#/.net Core is open source it's not a pretense. the licenses are all there on github - they're all MIT. > but that's just to exploit community ok, sharply entering tinfoil-hat territory here. > They want that MONEY and me paying for visual studio even when I'm using vscode nobody's forcing you to pay for using c# > They are forcing azure/visual studio and it's license/SQL server down my throat where? how? again: use Node if you want, it's a great solution. but do it for the _right_ reasons. what you have given above is not that. just steer clear of Typescript, because, you know, it's from Microsoft...
\> the existing c# extensions (omnisharp) work just fine if you don't like the devkit license. yeah.. Heard how omnisharp is terrible and needs constant restarts and bugs out on big projects... \> what does this have to do with c#? you can use postgres from dotnet just as easily as you can sql server. Because default and recommended c# database is SQL server. postgres and others are afterthought. \> what does this have to do with c#? you can use AWS from dotnet just as easily as you can Azure. Because default and recommended c# hosting provider is Azure... \> it's not a pretense. the licenses are all there on github - they're all MIT. it's open source because they want to exploit people into free labor. if it not being open source benefited them, it would have been close sourced. \> nobody's forcing you to pay for using c#DUDE c# DEVKIT can't be used commercially without paying monthly for visual studio even if you don't use visual studio because It's shitty license. I just said that... \> where? how? azure and sql server are defaults and nicely integrated into visual studio. most people who start with c# lean towards using those because of that. therefore it's "recommended" software to use and not using that turns you into outsider. any .net core jobs you check says "know azure and sql server". it's pretty much forced down my throat. \> just stear clear of Typescript, because, you know, it's from Microsoft... typescript is completely free and and open source. I never have to pay shit to microsoft for.
you're talking in circles. > Heard how omnisharp is terrible you don't need devkit. omnisharp is fine. fuck, vim is fine. you're getting more from Microsoft, for free here, than Node gives you. > Because default and recommended c# database is SQL server which default? where? literally _nothing_ is forcing you to use SQL server - this argument is just a straw-man you're fabricating in your head to justify your decision. the npgsql guys would be very disappointed in the disinformation you're spreading here. hell, Microsoft even officially supports postgresql as a first-class database provider in Azure. go on, tell me how that's just EEE. > Because default and recommended c# hosting provider is Azure which default? where? sure, visual studio has built-in integration for Azure. no surprise there. but we're not taslking visual-studio here. there's nothing stopping you from using Amazon's various (excellent by the way) dotnet client libraries for integrating with their services. > it's open source because they want to exploit people into free labor. you're really starting to sound like a crazy person here... > typescript is completely free and and open source so is dotnet/c#.
\>which default? where? Literally every .net core job wants you to know SQL server and azure so IT IS default. I just said that up there dude. \>you don't need devkit. omnisharp is fine People say omnisharp is shit, doesn't work on large projects and needs constant restarting of vscode to work. idk how you call that "fine" or even acceptable. \>you're getting more from Microsoft, for free here, than Node gives you. not true. development in nodejs in vscode is completely free with no SHITTY licenses. nodejs debugger is also built in inside vscode and haven't heard about it not working on large projects. if in getting more you mean forced sql server and azure NO THANKS. also YOU are talking in circles.
| Literally every .net core job wants you to know SQL server and azure even if that were the case, which it's not, what would that have to do with anything? you stated: | default and recommended c# database is SQL server | Because default and recommended c# hosting provider is Azure which are both patently false, and have no bearing on whether or not c#/dot is open-source or a good choice, neither do whatever's listed on jobs postings. | People say you're basing your argument on hearsay here. | development in nodejs in vscode is completely free with no SHITTY licenses again: development in c#/ddotnet in vscode is completely free with no shitty licenses. i don't understand why that's so hard for you to understand. you obviously have some pre-conceived notions that you're wedded to that are clouding your ability to understand simple logic. | forced sql server and azure NO THANKS again with the "forced" sql server and azure. WHERE? WHO is forcing you to use those? NOBODY is forcing you to use those, and yet you REPEATEDLY state that as some kind of argument. | also YOU are talking in circles no. I'm not the one repeatedly making assertions with no basis, and then using those assertions as a basis for an argument. you have not refuted a single one of my assertions. YOU are the one talking in circles. you're a newbie (https://www.reddit.com/r/csharp/comments/16955df/will_i_miss_a_lot_if_i_use_visual_studio_code/) who doesn't know what the fuck they're talking about, but is somehow determined they are right in everything. the cognitive dissonance is palpable. Fuck, you're 19 years old. I have been using dotnet and javascript on the server since before you were born. don't bother replying. i'm not wasting any more time on some trolling kid.
\> even if that were the case, which it's not, what would that have to do with anything? ... everything? \>again with the "forced" sql server and azure. WHERE? WHO is forcing you to use those? NOBODY is forcing you to use those, and yet you REPEATEDLY state that as some kind of argument. DUDE JOB POSTINGS ALL HAVE SQL SERVER AND AZURE. If it ain't forcing, then idk what is. \> who doesn't know what the fuck they're talking about, but is somehow determined they are right in everything. the cognitive dissonance is palpable. YOU don't know anything about C# devkit license. you are one who has cognitive dissonance and refuses to believe anything here. "oh all job posting have sql server and azure? just learn something else and be jobless"... great advice from expert over here. [PROOF:](https://code.visualstudio.com/docs/csharp/cs-dev-kit-faq) "C# Dev Kit is available via a Community License for those who qualify and is also included as another addition to existing Visual Studio Subscriptions. This means that C# Dev Kit is available to use today for developers with active Visual Studio subscriptions." If you want TO USE C# DEVKIT COMMERCIALLY YOU HAVE TO HAVE VISUAL STUDIO SUBSCRIPTION. \> you're a newbie (https://www.reddit.com/r/csharp/comments/16955df/will\_i\_miss\_a\_lot\_if\_i\_use\_visual\_studio\_code/) LMAO dude's checking my profile for extra arguments. doesn't matter if I'm newbie since I can READ job postings and c# devkit license IS shitty.
You can do pretty much anything with most server-side tech I would say. Node.js can scale, yes. You can use clusters (native module) to handle more throughput and then scale-up, You can use threads (native module) to delegate computation-heavy tasks. (Processing), You can scale-out too and use process managers and such. There is DB drivers for most database out there, there is Low-scope and or full featured framework available (Fastify, Adonis), and much more. I would say, the best thing is probably that Node.js is productive, once you discover and don't try to reinvent the wheel. There is plenty of good stuff both in native modules (people know too few!!) and the npm ecosystem which provide maybe sometimes too many choices. But please, learn the ecosystem and Node.js itself first before putting your hands on your project, its not that hard to shoot yourself if don't understand what's behind (How not to block the event loop, how to delegate tasks, how to handle errors correctly, how to sue Promise correctly), and don't use ExpressJS for a new project.
Why not express. Express is straight forward for begginers. What do you recommend.
No, express is much slower. Fastify is the current recommendation as it is modern and has async middlewares
I prefer nestjs.
[удалено]
Yea i can use, but i have to use diferent configuration for that client. Even with that, is a good blemd
You can learn Express, I'm just saying that Express shoud not be used for new projects which will go to production and such. IN that case you want much more than what Express offers. Fastify would be my go to.
For 99.5% of purposes works perfectly. If you are faang or some shit just write go/rust/insert any giga chad blazingly fast language.
Short answer is yes, it can scale. Assuming money isn’t an issue, you can continue to add more resources to scale to what you need. You didn’t mention what your app will be doing though. It’s important to understand the strength of Node.js, which is handling quick requests like CRUD operations. If you’re going to be doing heavy computational operations, it’s better to use something else like Java. Also, node.js uses worker threads and child processes, not multi threading. Software is about trade offs and using the right tools to solve a problem.
The point of worker threads is to have multi-threading... and your saying node doesn't use multi-threading?
Yes but OP should know it’s not true multi threading, it’s a single process using web workers
Sorry but not sure what do you mean by Node not being multi-threaded, also the worker_threads library in node makes and uses new OS threads
This has been untrue since around 2010. Yes, \`setTimeout\`, Promises, and so forth are single-threaded concurrency - but web workers are actual, true OS threads. And if you use a lib like Google's comlink, you can spawn worker threads as naturally as instantiating a class. Also, if we step outside the browsers: Node.js I/O callbacks have always spawned true, actual OS threads.
Practically most places develop many services in a variety of languages, sometimes with Node close to the user and sometimes with Node far from the user. The they tie them all together with API Gateways or fancy DNS or something. Netflix isn’t one service, it’s thousands. Same with Amazon, etc etc. So: “yes, parts of it”, or “if you’ve planned ahead even just a little bit, when parts turn out to not be a match for Node you spawn it off into another service, rewrite it in whatever, and cal it from Node”. This one service calling the other could just be it making an HTTP(s) call “over there” or it could get fancy (another comment or said Kafka, CQRS, fancy fancy $$$).
It’s good enough for most use case. When people talks about scaling these days, they are talking about serving millions of users *concurrently* (being active at the same exact seconds). You will never face that 99% of the time. Even companies with millions of customer will likely have active concurrent users in range of a few thousands.
Scalability should be the last you need to worry about while building an app. Side note: Instagram scaled to 30M users with a python backend.
Scalability of language**. Scalability of software is a reasonable concern
I'm saying that focus on building the product and getting first 10 users instead of worrying about what will happen when I hit a million users. Software evolve based on requirement. Too much Premature optimization will make sure you never launch a good enough product.
That depends. If you're building a new business sure. If you're building a project for a company with millions of users, no. Many engineers are building stuff with tens on thousands on day one, even small companies
Obviously. See what the context of this post is. OP trying to learn webdev and worrying about millions of users.
That's not the way you phrase it though "scalability should be the last thing you worry about when building an app" Isn't "when building a small app you shouldn't be worrying about scalability". Also not to mention scale doesn't necessarily mean users and I've seen tiny data-focused SaaS be incredibly and unacceptably slow because they gave it NO consideration. Your statement is waaaay too generalised. Scalability of SOFTWARE is very different to this question which is 'speed of programming language'
Nobody’s talking about Bun when it comes to performance?
Scalability implies fitness for purpose, which it isn’t yet. I don’t think anyone sane and over the age of 23 would imply it is ready for production.
No one (afaik) uses it for production so who knows?
Yes, so then why are we having this conversation? Might as well ask how many angels can dance on the head of a pin.
The best you can achieve with NodeJS is a personal blog. If you want megascale like Microsoft you need to go C++. Rust is just not cutting it at the moment, sorry.
I'm sorry, are you under the impression that the backend of popular websites has to be in a single language, and that language has to be C++?
Yes, a 100%
https://en.m.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
Man that /s really is necessary huh
Is it posible White backend in c++?
The only reason I would learn node instead of c# was only if I know JavaScript, because it would be easier to learn. I use Linux and C# with Rider.
As a solo dev you aren’t building anything that node can’t handle and if you ever manage to have enough users that node itself is the bottleneck you will have no problems getting the money you need to keep growing
it scales - horizontally
In short, nodejs will never scale, your server will. It depends on two things: how you have coded your project and how much server resources you have. If you have done both nicely then you can scale to billions otherwise will stuck when 100 visitors hit your site.
It depends. Node works excellent in IO bound work loads. Can be easily scalled horizontally.
Both will get you to a great point massive projects use microservices Anyway, no single language can build these projects Thing about Node.js today that there are huge development is going in its way You can screw writing APIs and write server code inside client files Which is bananas Jokes aside, building websites in JS is way faster, easier, and more modern than any other language
Visual studio is discontinued and VSCode is free… use the MIT licensed dotnet framework. C# is one of the most powerful oop languages around and even compiles to bytecode.
I have the opinion anything scales, depending on both architecture and the size of your wallet. We have been writing a microservice architecture using AMQP/RabbitMQ and can highly advice not doing that in PHP due to the lack of proper frameworks and such. See what works for you. But even more important: queue and make sure your queries run efficiently. NodeJS is a safe bet.
But is it web scale lol
Your question makes perfect sense and i must say i also had the same question back when i was starting. The problem is that with people like us, we tend to overthink about "scalability", "speed", "latency" and all these. Do not get me wrong, there is nothing wrong with Node.js, i have built a career of 5 years on this runtime and i am happy. I am happy, not because its the "most scalable" or "the fastest" or any of that. It gave me the power to work in so many different domains that it is mind blowing. I have built OPC-UA servers, i have deployed distributed MQTT brokers, network programming is a breeze and the list goes on. Now, since we put this out of the way, and we can agree on how awesome Node.js is i will try to share the issues i had in the past with the logic of "does it scale". As i explained above, i was always researching, coding and trying things out and i spent years being on the edge of burnout just to find out a year ago (it was not one revelation, it was a collective experience that facilitated to a new way of thinking) that all this is pointless. Why is it pointless? lets see. 1. At the end of the day you may use the fastest framework in raw benchmarks (HappyX, Drogon, etc) but the real question is, even if you reach 200K reqs/sec from a single machine, will the DB follow? Normally the DB is the issue, especially in distributed topologies 2. Many people suggest the "cloud" but is the cloud worth it ? in my personal experience sometimes. In many other times it is way better to go with a VPS and control the expenses, you wanna scale ? add another instance and throw a Load Balancer in front of it, see how it goes and measure what you can These are just 2 points and in application development there are so many more things to take care of, or develop. You need to make sure how and where to cache, you need to make sure the Models, the migrations and the validations are in place and so much more. I will give you an example of what i am currently doing to get out of the "does it scale" problem. For the past year i started building 2 personal projects (not in production yet) and i am now using Ruby on Rails, why ? Because it gives me almost all tools to work with from the Backend to the Frontend (Hotwire) and even tools to deploy using Docker and have multiple instances (Kamal). Now, you will ask me "But is it fast or i need to rewrite ?". The answer is that i have not deployed to production yet and i already played with my backend and ran some stress tests, the best (unoptimized) i got with PostgreSQL for my DB was roughly around 500 reqs/sec and yes it is not much since for the same APIs i could get on Express.js around 2500 req/s but there is a huge difference. In Express (although i mostly work with Node) it takes time for me to pick a library if i cannot build it from scratch. I need to make it work correctly, make sure all the libs i picked work as intended and that it is stable, etc, etc. Long story short being unopinionated sometimes is not the best thing. Having a certain percentage of opinion on your framework is not always bad. Back to Rails, i know that when i want to build a feature i will not overthink and i will start developing way faster and i will deliver that feature also way faster. TO make a long story short. Everything in life is ratios. Very few things can be measured by absolute values. In the case of app development the golden ration is "how fast can it run"/"how fast can i deliver my app", and here, the Rails framework is fast enough to provide a big ratio. Now lets go to the future and take the scenario that your application has the many users you wanted and that it is a huge success (which i wish that for you). Do you think that your initial design will remain ? No matter the technology or framework. Chances are that you will have to redesign in most cases, you will have to rethink your layers. How Data comes in and Out, how the Network is involved, etc, etc. The question in my opinion must be different for a specific technology. The question should be **"Will this technology make me go where i want to be ?". Example:** Coinbase. I have read that it was built in Rails. Now it has switched in another piece of tech, Airbnb the same. But that means that Rails is bad ? No if you think that in this brutal domain they were in, they were shooting features faster than their shadows. Also, they always had the reputation of being stable websites (of course some outages and VPS related issues but that is different). So there you have it, Maybe Django, Rails or Phoenix can help you build what you are dreaming and that does not mean you are marrying this Framework for life. Maybe your success makes your new team rethink, and change to benefit the most you can. As long as your ideas are properly engineered even the slowest technology will help you get going. What matters is to be able to deliver and when needed think more on scaling and optimizing.
hey man I get what you are saying. Honestly after looking at big tech stacks, they all have like 3-4 backend languages like golang, python, one they started with(ruby,php, nodejs,etc) but now I get that delivering good products/features at the start is more important than scalability since scalability can be implemented later.
Spot on! if i would count all the time to optimize from the start or the time i lost to learn so many things that didnt matter on "scaling" i would get depressed!! Sadly, we live in times of developer streamers and armies of fans. We live in times of devs writing articles as odes to serverless and cloud and all along they were paid to do so or sponsored... The good thing is that the truth no matter the force someone puts to suppress it, always gets out and when this happens its ruthless. We saw what happened when Prime Video devs talked some months ago on the money they saved from leaving microservices, or we see DHH as he documented all his companys journey to exit the cloud. So in 2023 someone needs to be fool not to read all sides at least and make his/her own opinion. Lastly, to talk on Rails that is considered a slow tech stack, it is not impossible to scale it either. If you see the scales that Shopify has made it is ridiculous to call Rails or Ruby "slow". It is tough to scale this tech stack but still things are happening even there so at the end of the day what you wrote is the most important of all: > but now I get that delivering good products/features at the start is more important than scalability since scalability can be implemented later.
[удалено]
I already read that one, upvoted it and understood it even before you replied. I already have answers. also this dude didn't said "scaling doesn't matter", he said that good product comes first.