The four speakers — from Intuit, PayPal, BBC and WB Games — provided valuable information on how they use node.js. Here are my meeting notes:
DevOps and Node.js – Build and Deploy Principles in hosting Node.js
Chetan Desai, Intuit (@chetanddesai) sharing lessons learned one-year into introducing node.js into their organization. They picked their Application Services SOA Layer to test run node.js
- Shared build farms
- Build Once / Deploy Multiple
- Minimize failure points during deployment
- Availability: upstart, systemd
Optimizing Node.js services with JMeter and N|Solid
Daniel Racanelli (@elrasguno), WB Games on why they are simulating 15M users using JMeter.
- js is really just C: its really in the V8 JS Engine
- Everything is asynchronous. Easy to optimize “hotspots” when applying general best practices
- Stress vs. Representative Testing: Find max throughput through Stress Test
- JMeter is my friend. N|Solid “Completes Me”
Moving fast with Node.js at the BBC
Robin Murphy, BBC handling 1Mio concurrent web socket connections with node.js backend. Migrated their API Backend based on Java to multiple node.js API services.
- How do you move with the speed of a startup in an enterprise organization: Confidence & Trust
- I have Confidence deploying my app in prod through TDD (Test-Driven Development)
- I Trust your team to deploy into production
- Cosmos: deploying into AWS -> Automated!
- Real-Time Monitoring to really know if the app behaves correctly once deployed: check out codeascraft.com -> original article on using statsd from Etsy
- Consumer-Driven Contracts: github/bbc/consumer-contracts
Trevor Livingston (@tlivings), Paypal discussed how they replaced Java with node.js as the preferred technology for frontend. Over 700 active node.js devs at PayPal.
- js as Open Source vs Internal JS
- When people belong to a shared experience they begin to engage and take ownership
- Building a community: develop I the option; engage stake holders; share knowledge; ask for contribution
- We – the framework team – are our own product managers by engaging with the application teams to figure out what they need
- Guiding principles: provide capabilities not rails; consume over provide; Say “no”, especially to edge cases; Design for re-use -> http://innersourcecommons.org