Beyond the MEAN Stack: Thinking Small with Node.js for the Enterprise

Editor's Notes

• #4: • 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
• #5: • 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
• #6: • 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)]
• #7: • 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]
• #8: • 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
• #9: • 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
• #10: 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.
• #12: Node isn't omakase: it’s not an opinionated framework made up of curated components, optimized for a single use case
• #13: nor is it a swiss-army chainsaw: it doesn’t try to do everything, and it’s not good at everything
• #14: nor is it whatever the hell this is: Node eschews the abstract and formal in favor of getting things done [google “java abstract factory”]
• #15: • 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
• #16: • 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
• #17: • 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
• #18: • 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
• #20: Voxer uses it less than they did, but it was handling thousands of transactions per second for sustained periods of time.
• #21: • 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
• #22: • explosively growing ecosystem, via npm • scale up or down as far as you want
• #24: • 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
• #25: • follows the same routing syntax, but has its own architecture • great for mobile apps [too cool for a logo]
• #26: …and there’s always Geddy if you want something like Rails but smaller, simpler, and more conceptually unified than Sails.
• #28: • 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
• #29: • 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
• #30: • 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
• #31: • 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