(...)
Frameworki: Loopback, Hapi, Sails?
Serwisy korzystające w większości z Node.js, m.in.: Netflix, Linkedin, Uber, PAYPAL(!). To są małe serwisy?
Era monolitu się kończy, teraz duże serwisy i tak buduje się w oparciu o mikrousługi, a Node do tego jest najlepszy.
GitHub Netflixa zawiera głównie projekty Javowe: https://github.com/Netflix
Np https://github.com/Netflix/conductor - Conductor is a microservices orchestration engine - https://netflix.github.io/conductor/
LinkedIn? Oto artykuł o architekturze: https://engineering.linkedin.com/architecture/brief-history-scaling-linkedin
By using JSON over HTTP, our new APIs finally made it easy to have non-Java-based clients. LinkedIn today is still mainly a Java shop, but also has many clients utilizing Python, Ruby, Node.js, and C++ both developed in house as well as from tech stacks of our acquisitions.
Do serwowania stron używają Play framework (napisany w Scali):
We’ve rethought our frontend approach, adding client templates into the mix (Profile page, University pages). This enables more interactive applications, requiring our servers to send only JSON or partial JSON. Plus, templates get cached in CDNs and the browser. We also started to use BigPipe and the Play framework, changing our model from a threaded web server to a non-blocking asynchronous one.
Playa chyba dość polubili
https://engineering.linkedin.com/blog/2016/12/pemberly-at-linkedin
We decided to build up a solution, dubbed Pemberly, combining open source software we were already using in the mid-tier (Play) along with a web framework (Ember) for JavaScript that would deliver strong conventions, easy ability to manage state, a robust build and testing methodology, and the delightful, app-like user experience we were targeting.
A Node to używają do server-side rendering:
The next piece of the architecture is the Base Page Renderer. The Base Page Renderer provides the head of the document and early flush capabilities. It also allows the app to load in several modes: Vanilla (browser does the heavy lifting), SSR (server-side render for DOM complete), and BigPipe (the ability to let the browser boot the Ember app while simultaneously streaming data and DOM to the browser by delegating that work to separate Node processes, which are running the Ember app).
PayPal używa Scali (chodzącej na JVMie) z Akką jako backendu:
http://highscalability.com/blog/2016/8/15/how-paypal-scaled-to-billions-of-transactions-daily-using-ju.html
https://www.lightbend.com/blog/how-reactive-systems-help-paypal-squbs-scale-to-billions-of-transactions-daily
Uber natomiast zaczął od Node.js i mają dużo starego kodu napisanego w Node.js, ale przesiadają się chyba na język Go. Używają także Javy dla wysokiej wydajności:
https://eng.uber.com/tech-stack-part-one/
At the lower levels, Uber’s engineers primarily write in Python, Node.js, Go, and Java. We started with two main languages: Node.js for the Marketplace team, and Python for everyone else. These first languages still power most services running at Uber today.
We adopted Go and Java for high performance reasons. We provide first-class support for these languages. Java takes advantage of the open source ecosystem and integrates with external technologies, like Hadoop and other analytics tools. Go gives us efficiency, simplicity, and runtime speed.
https://eng.uber.com/tech-stack-part-two/
Uber’s core trip execution engine was originally written in Node.js because of its asynchronous primitives and simple, single-threaded processing. (In fact, we were one of the first two companies to deploy Node.js in production.) Node.js gives us the ability to manage large quantities of concurrent connections. We’ve now written many services in Go, and this number continues to increase. We like Go for its concurrency, efficiency, and type-safe operations.