|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
https://www.quora.com/What-are-the-biggest-websites-built-with-Node-js-on-the-server-side
- Walmart (Why Walmart is using Node.js )
- E-bay / PayPal ( Node.js at PayPal)
- Microsoft (Node.js Dev Center | Windows Azure) They have extensive support, in fact their Azure CLI tools are actually written in Node.js.
- LinkedIn (Exclusive: How LinkedIn used Node.js and HTML5 to build a better, faster app)
- Yahoo
- Google (Node at scale: What Google, Mozilla, & Yahoo are doing with Node.js)
- Yammer (now part of Microsoft) (Managing Node.js Dependencies and Deployments at Yammer - Yammer Engineering)
- Netflix has a series of blog posts on its use (Search results for node.js)(Updated 2016-02)
- Looks like Uber is using it as well (Updated 2016-03)
|
Just to point out, many of your links do not actually describe large scale websites built with node (e.g. the Google sub article).
|
Hyrule19240 Posts
On August 26 2016 23:59 Hhanh00 wrote:https://www.quora.com/What-are-the-biggest-websites-built-with-Node-js-on-the-server-sideShow nested quote +
- Walmart (Why Walmart is using Node.js )
- E-bay / PayPal ( Node.js at PayPal)
- Microsoft (Node.js Dev Center | Windows Azure) They have extensive support, in fact their Azure CLI tools are actually written in Node.js.
- LinkedIn (Exclusive: How LinkedIn used Node.js and HTML5 to build a better, faster app)
- Yahoo
- Google (Node at scale: What Google, Mozilla, & Yahoo are doing with Node.js)
- Yammer (now part of Microsoft) (Managing Node.js Dependencies and Deployments at Yammer - Yammer Engineering)
- Netflix has a series of blog posts on its use (Search results for node.js)(Updated 2016-02)
- Looks like Uber is using it as well (Updated 2016-03)
Yeah, plenty of companies use Node for some things, but most of them are driven by PHP (likely C# in Microsoft's case), C, and Go. None of those sites are majority node. Like the Azure CLI: only the tools are written in Node.
|
And Java
So much Java
:/
Though also worth pointing out that most places don't need the same kind of scale as ms Google whatever.
|
28102 Posts
On August 26 2016 21:37 tofucake wrote:Show nested quote +On August 26 2016 14:31 Wrath wrote:On August 26 2016 06:28 BisuDagger wrote:On August 26 2016 06:20 Wrath wrote:On August 26 2016 05:39 tofucake wrote:
it's single threaded, which is a huge issue Why? Google is a great resource for these types of questions. I know little about node and now im that much more informed after google research! http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded My question was why it is a huge issue not why it is a single threaded  If you're looking to do some standard website, node is a crap choice. Something like TL would go down in flames if it were made in node, nevermind any big site. Nobody will create the next Facebook/Google/Etsy/Ebay/PayPal/Expedia/Whatever until node gets multithreading.
Unfortunately TL's backend is based on your least favorite language (unless it was someone else that hated PHP).
|
Yea but TL is a tiny website that is very unlikely to need to scale beyond the capabilities of PHP. And that's fine. Most websites don't need scale beyond what MySQL PHP perl node whatever can handle.
Right like I just did an interview today where the candidate and I settled on an approximate db size of 100 billion entries, and it was actually ok to do with fairly simple tech. There's nothing wrong with that.
|
In fact I would say more common is that something does get built in poorly scaling tech, then gets big. And then people scramble to scale (either by hacking on the tech, porting, or what have you).
Designing from the outset wih the expectation of having hundreds of millions of users and petabytes of data to crunch is the exception, not the rule.
|
TL would go in flames if based on node.js, but it's ok for Linked in to use node.js for their mobile backend.
If you're looking to do some standard website, node is a crap choice. Something like TL would go down in flames if it were made in node, nevermind any big site.
“On the server side, our entire mobile software stack is completely built in Node,” said Prasad. “We use a ton of technologies at LinkedIn, but for the mobile server piece, it’s entirely Node-based.
|
Yea but TL is a tiny website that is very unlikely to need to scale beyond the capabilities of PHP. And that's fine. Most websites don't need scale beyond what MySQL PHP perl node whatever can handle.
What do you mean "Scale beyond the capabilities of PHP"? Facebook is built on PHP, isn't that strong enough?
|
|
|
Also Facebook PHP is quite different. See hiphop for example.
|
OK, if PHP is too limited for huge websites, what tools should they use?
Also, could you please give example on how PHP is limited?
|
NodeJS isn't very fast by itself but big companies can offset its low performance by throwing hardware and money at it. For PHP, since it's a language, the result depends on the implementation and the web server that hosts the application.
Here are some raw benchmark numbers for the interested:
https://www.techempower.com/benchmarks/#section=data-r11&hw=peak&test=plaintext
NodeJS low performance can be explained by libuv using a single threaded event loop over I/O abstractions that don't match the underlying systems well resulting in needless memory allocations and context switches. Faster frameworks use native system calls like epoll/kqueue/iocp and/or aio. Some frameworks end up delivering data from disk faster than nodeJS can deliver from memory.
|
Hyrule19240 Posts
On August 27 2016 05:31 TheEmulator wrote:Show nested quote +On August 26 2016 21:37 tofucake wrote:On August 26 2016 14:31 Wrath wrote:On August 26 2016 06:28 BisuDagger wrote:On August 26 2016 06:20 Wrath wrote:On August 26 2016 05:39 tofucake wrote:
it's single threaded, which is a huge issue Why? Google is a great resource for these types of questions. I know little about node and now im that much more informed after google research! http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded My question was why it is a huge issue not why it is a single threaded If you're looking to do some standard website, node is a crap choice. Something like TL would go down in flames if it were made in node, nevermind any big site. Nobody will create the next Facebook/Google/Etsy/Ebay/PayPal/Expedia/Whatever until node gets multithreading. Unfortunately TL's backend is based on your least favorite language (unless it was someone else that hated PHP).
I actually like PHP, especially 7
|
On August 27 2016 18:24 Wrath wrote:
OK, if PHP is too limited for huge websites, what tools should they use?
Also, could you please give example on how PHP is limited?
When it comes to real giants I guess that everything is limited in the end. We're talking about websites that expose thousands of APIs, have user base in the millions etc. When it comes to such monsters it's highly unlikely they'll be limited to a single technology stack.
For example, with data they're most likely using CouchDB for documents, Neo4j for graph data, Redis or BerkeleyDB as primary cache and MySQL/PGSQL/Oracle/whatever as their big data store, with only maybe 10% queries actually hitting it. Then you'll have multiple backends for various parts (Facebook has PHP running on HHVM, some Scala, Node and probably other things thrown into the mix). Then you have front-end tech like Angular or React added as another layer on top of that. To further leverage this complex architecture you have some form of ESB sprinkled into the mix. Then you start to think how it's spread over a gazillion servers with reverse proxies, DB replication etc. and you realize that it's one huge clusterfuck of a mess.
Nowadays you don't limit yourself to a single tech. You pick the tool that best suits your needs for specific parts and then build everything as SOA so you can pretend it's one huge app.
|
On August 29 2016 16:12 Manit0u wrote:Show nested quote +On August 27 2016 18:24 Wrath wrote:
OK, if PHP is too limited for huge websites, what tools should they use?
Also, could you please give example on how PHP is limited? When it comes to real giants I guess that everything is limited in the end. We're talking about websites that expose thousands of APIs, have user base in the millions etc. When it comes to such monsters it's highly unlikely they'll be limited to a single technology stack. For example, with data they're most likely using CouchDB for documents, Neo4j for graph data, Redis or BerkeleyDB as primary cache and MySQL/PGSQL/Oracle/whatever as their big data store, with only maybe 10% queries actually hitting it. Then you'll have multiple backends for various parts (Facebook has PHP running on HHVM, some Scala, Node and probably other things thrown into the mix). Then you have front-end tech like Angular or React added as another layer on top of that. To further leverage this complex architecture you have some form of ESB sprinkled into the mix. Then you start to think how it's spread over a gazillion servers with reverse proxies, DB replication etc. and you realize that it's one huge clusterfuck of a mess. Nowadays you don't limit yourself to a single tech. You pick the tool that best suits your needs for specific parts and then build everything as SOA so you can pretend it's one huge app.
Thanks for the explanation. I decided I'd go with Java for now. I should remember it mostly in a week and then I'll practice on Spring and maybe struts.
I rethought the whole thing and I found that my problem is not that I don't know the language at all. Basically they all have the same syntax with minor differences. But I have 0 knowledge about used frameworks. The shit that really really matters.
Later I may check RoR or PHP my cake.
|
On August 26 2016 21:37 tofucake wrote:Show nested quote +On August 26 2016 14:31 Wrath wrote:On August 26 2016 06:28 BisuDagger wrote:On August 26 2016 06:20 Wrath wrote:On August 26 2016 05:39 tofucake wrote:
it's single threaded, which is a huge issue Why? Google is a great resource for these types of questions. I know little about node and now im that much more informed after google research! http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded My question was why it is a huge issue not why it is a single threaded If you're looking to do some standard website, node is a crap choice. Something like TL would go down in flames if it were made in node, nevermind any big site. Nobody will create the next Facebook/Google/Etsy/Ebay/PayPal/Expedia/Whatever until node gets multithreading.
Why would node go down in flames if it ran TL.net? My realworld test gave me about 20 requests/ second on a amazon micro instance. If you really need more just add more instances behind a load balancer. (might have been 50 requests/ second but honestly 20 is enough to prove my point isnt it?).
|
On August 29 2016 20:20 njt7 wrote:Show nested quote +On August 26 2016 21:37 tofucake wrote:On August 26 2016 14:31 Wrath wrote:On August 26 2016 06:28 BisuDagger wrote:On August 26 2016 06:20 Wrath wrote:On August 26 2016 05:39 tofucake wrote:
it's single threaded, which is a huge issue Why? Google is a great resource for these types of questions. I know little about node and now im that much more informed after google research! http://stackoverflow.com/questions/17959663/why-is-node-js-single-threaded My question was why it is a huge issue not why it is a single threaded If you're looking to do some standard website, node is a crap choice. Something like TL would go down in flames if it were made in node, nevermind any big site. Nobody will create the next Facebook/Google/Etsy/Ebay/PayPal/Expedia/Whatever until node gets multithreading. Why would node go down in flames if it ran TL.net? My realworld test gave me about 20 requests/ second on a amazon micro instance. If you really need more just add more instances behind a load balancer. (might have been 50 requests/ second but honestly 20 is enough to prove my point isnt it?).
I think that the biggest problem with single-threaded apps is consistency. If each request runs in a separate thread then you can expect the same request to take the same amount of time, not so much with queueing since you don't really control what's being executed when.
Another downside of single-threading is that if some process will crash your app it's going to crash it for everyone, not just a single instance.
|
Hey guys, I have a problem again.
I asked it here
So I'm building a data hub. Basically I want to store large amounts of data in a database.
In order to do that there are these pipes of data that my data providers have to make using my APIs.
I want to secure the APIs so I know who's making the streams and I can limit who makes them. As well as who can send to them. Does it make sense to do OAuth for the non-ingestion API methods and use an API key for the ingestion methods?
OAuth tokens tend to expire and ingestion of data is a long running process.
OAuth + API keys doesn't feel like the right solution since then there's 2 separate security protocols being used.
The other option I see right now is to force users to check the expiration time of their tokens and then try to refresh them if it's about to expire and they still need to send data.
|
guys sorry to interrupt your debate about app server threads, but im gonna ask a newb cloud question:
As I see Azure has a way to programmatically control cloud resources/deployments (https://github.com/Azure/azure-sdk-for-java), I'm assuming other cloud providers would have too. Right now have a software that we deploy to cloud by hand (uploading by ftp). We want to sell this web app to numerous small-budget customers.
Do you think such a workflow possible/appropriate/viable:
We build a website that customers can buy our software through. After payment, using the cloud API's above, an instance of our app is deployed to cloud (creating required services like databases etc) and customer is given a domain name to access his product. All of this is done without any handwork.
|
|
|
|
|
|
EPT
