Beyond the MEAN Stack: Thinking Small with Node.js for the Enterprise
•Télécharger en tant que PPT, PDF•
9 j'aime•9,567 vues
Presentation from Node Summit 2013. You could be using Node as one component of a larger stack, but to do so would be wasting a lot of Node's most powerful features, including its huge ecosystem and thriving community.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Beyond the MEAN Stack: Thinking Small with Node.js for the Enterprise
Similaire à Beyond the MEAN Stack: Thinking Small with Node.js for the Enterprise (20)
Dernier
Dernier (20)
Beyond the MEAN Stack: Thinking Small with Node.js for the Enterprise
- 1. Getting small for the enterprise. Beyond the MEAN stack @othiym23 forrest@newrelic.com github.com/othiym23
- 2. you chose Node for a reason Node is fast Node is modular Node is fun
- 3. so why turn it into something else?
- 4. Node is built on the sound engineering values: low coupling high cohesion
- 5. “ is the of Web development is more pattern-driven: is this social media? is this a storefront? is this… is this a cms? .”
- 6. moduletopia™ Node loves modules: more all the time available for almost every use case pretty easy to understand (mostly) on GitHub (mostly) freely usable
- 7. stacks: khakis of the internet familiar: faster to build things you already know comforting: already integrated / tested / shipped easy: developers only need master one set of tools
- 8. stacks are sticky opaque: full of implicit assumptions and requirements complicated: hard to master, easy to break monolithic: have to pay for the whole thing (but only using some of it)
- 9. Node says: build only what you need.
- 10. one size does not fit all
- 11. one size does not fit all
- 12. one size does not fit all
- 14. some Node use cases streaming json apis multiplexing soft realtime proxying …you know, fast web servers
- 15. & some legacy glue dat: scraping & etl dinosaur taming: Oracle & xml ~50k modules: there’s a pony in there somewhere Windows: best support of any of the major scripting languages
- 16. the zen of Node self-contained: code over configuration modular: inversion of control & direct dependency injection simple: one small thing in one short file and so: easy for new people to pick up, easy to maintain
- 17. be nice, not mean
- 18. MEAN: MongoDB
- 19. instead of MongoDB: Redis fast: data lives in memory powerful: many different data types, lots of operations flexible: many options for high availability and clustering a veteran: battle-tested in Node
- 20. instead of MongoDB: MySQL* “simple” and “fast” are its best features time-tested some data are just plain relational can actually be managed * or PostgreSQL (<3 )
- 21. instead of MongoDB: leveldb a do-it-yourself dbms rapidly-growing ecosystem simple not all there yet, but built on a solid foundation
- 22. MEAN: Express
- 23. instead of Express: hapi plugins instead of middleware configuration-centric optimized for large teams
- 24. instead of Express: Restify api “compatible” with Express’s meant for building restful apis optimized for json instrumented for operational monitoring
- 25. instead of Express: Sails actually built on top of Express feels like Rails (including scaffolding) realtime stack-like, but still a creature of parts
- 26. MEAN: AngularJS
- 27. instead of Angular: browserify puts Node modules in your browser puts Node ideology in your browser everything’s on npm flexible packaging pipeline good for Node-first developers
- 28. instead of Angular: component similar to browserify built on GitHub not so much with the asset pipeline more focused on client-side development than browserify
- 29. instead of Angular: bower / Yeoman an integrated, browserfocused workflow very rich asset pipeline good for client-first developers
- 30. MEAN: Node.js
Notes de l'éditeur
- • the name of this talk comes from a thing I’ve seen out there: the “MEAN (or Mongo-Express-Angular-Node) stack” • this isn’t actually a thing, but I understand why some people want it to be, and will go into both what I think their motivations are and why I ultimately think they should let it go
- • Facts and Fallacies is a wonderful book, pragmatic and filled with evidence • it provides an empirical basis for a lot of software engineering’s core principles • and these cornerstones of good software engineering are pretty simple: they’re low coupling and high cohesion • put another way, each piece should do only one thing, and do it well • the Node community honors these values in a pretty plainspoken way • publish everything as its own module • don’t put in anything you don’t need
- • web development tends to be more pattern-driven: does this new product look like Facebook? does it look like Amazon? does it look like Wordpress? [the Instagram of fax machines / the Netflix of underwear / the Klout of bail bond services (one of those is real)]
- • this is practically an ideology in the Node community – modules are plentiful and very focused, and tend to be simple enough that a moderately experienced developer can understand a new module in less than an afternoon [the biggest problem with Node’s module ecosystem is discoverability]
- • it's tempting as a business owner to spec projects out this way, because it feels faster to frame new products in terms of things you already know • and it's comforting to think in terms of frameworks or stacks, because you know they've already been integrated, tested and delivered at least once • this reduces risk and gives some sense of the scope of work • and some devs prefer frameworks because it allows them to master one set of tools and use them to quickly put together new things
- • but stacks are sticky – they contain implicit assumptions and requirements that may not match yours – and adapting them can be difficult • the more comprehensive the stack, the more difficult it's going to be to understand it, and the more likely you are to overlook something, duplicate functionality with slightly different implementations, or introduce bugs or security holes
- The nice thing is that Node modules, being designed to do one thing, are generally easy to combine, making it fast to build an app that does what you need – and no more – in a reasonable amount of time.
- Node isn't omakase: it’s not an opinionated framework made up of curated components, optimized for a single use case
- nor is it a swiss-army chainsaw: it doesn’t try to do everything, and it’s not good at everything
- nor is it whatever the hell this is: Node eschews the abstract and formal in favor of getting things done [google “java abstract factory”]
- • it has a double handful of solid use cases, of which some are highly relevant to enterprise projects: • streaming: good for serving large files (GitHub’s use case for a couple years now) * multiplexing: lots of I/O on an economical amount of server (good for games!) • JSON APIs: good for talking to mobile and modern web clients * proxying: good for pulling together a complex back-end network (just look at Walmart) * soft realtime: presence notification and status notification
- • pretty much whatever legacy components you have to interoperate with have at least one module out there (except maybe tn3270 emulation) • Azure is already the second-largest cloud, it’s competitively priced (and MS invoices!), and MS is improving it all the time
- • Node tends to favor a style of simple composition: • code over configuration • inversion of control via callbacks or promises • direct dependency injection • one thing exported from one short file – you can reason about one whole small problem at a time
- • let’s look at some alternatives to the popular components in the MEAN stack • not judging, just showing some of the many different ways Node can be used to solve different engineering problems • choosing the best tool for the job rarely ends up being an objective process anyway
- Voxer uses it less than they did, but it was handling thousands of transactions per second for sustained periods of time.
- • driver is bare-bones, but that’s a feature — there are other modules for connection pools, ORM-like things • “time-tested” – legacy isn’t always a dirty word
- • explosively growing ecosystem, via npm • scale up or down as far as you want
- • hapi is still relatively new, but already in large-scale production use • plugged into all kinds of legacy systems, being used as a shim for mobile • grew out of Express, but was tailored to suit Walmart’s needs – a model for other enterprise projects
- • follows the same routing syntax, but has its own architecture • great for mobile apps [too cool for a logo]
- …and there’s always Geddy if you want something like Rails but smaller, simpler, and more conceptually unified than Sails.
- • ideology isn’t necessarily something you want to deal with when writing web apps, but it’s pretty par for the course with large frameworks like Angular or Ember • and browserify really isn’t a framework, it’s a module that glues components together, but it’s meant to be used (with lots of small browser modules) instead of Angular • flexible packaging pipeline without complex external tools
- • component is even less of a framework than browserify – not really about control flow and logic, more about putting widgets on a page • easy to use with another browser-hosted framework
- • yeoman is an impressive tool for client-oriented developers • focused on integrated workflow over integrated abstractions • not necessarily incompatible with a framework like Angular or Backbone, but not necessarily required, either
- • the point of this presentation is: consider your options, and use the right tool for the job • I really like Node – I’ve sunk more than two years of my life into working with it and making it better, pretty much 24/7 – but I’ll be the first to admit it’s not appropriate for everything • it’s easy to malign platforms like PHP and the JDK, but they have a lot of valuable things to offer • choose what you need to solve your problem, and try to design products to use it for what it’s best at