You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Installs ImageMagick --with-librsvg on Amazon Linux
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Continuation monad in JS. just run $ node continuation.js
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On an architectural level, the way we craft large-scale applications in JavaScript has changed in at least one fundamental way in the last four years. Once you remove the minutia of machinery bringing forth data-binding, immutable data-structures and virtual-DOM (all of which are interesting problem spaces) the one key concept that many devs seem to have organically converged on is composition. Composition is incredibly powerful, allowing us to stitch together reusable pieces of functionality to "compose" a larger application. Composition eschews in a mindset of things being good when they're modular, smaller and easier to test. Easier to reason with. Easier to distribute. Heck, just look at how well that works for Node.
Composition is one of the reasons we regularly talk about React "Components", "Ember.Component"s, Angular directives, Polymer elements and of course, straight-up Web Components. We may argue about the frameworks and libraries surrounding t
Anivia is Walmart's mobile analytics platform. It collects user-interaction metrics from mobile devices -- iPhone, iPad, Android, and mWeb. It also processes logging and other metrics from a bunch of mobile services. Anivia allows the business to have real-time insight and reporting into what is going on in the mobile business and provides vital capabilities for developers and ops folks to monitor the health of their services.
Anivia is built on Node.js, Hapi, RabbitMQ, and a multitude of downstream systems including Splunk and Omniture. Anivia is taking in 7,000 events per second on average (as of this writing), which after some fan-out and demuxing comes out to around 20,000 messages per second in flight. These rates are expected to soar leading up to and including Black Friday. The platform has grown in recent months to over 1,000 node processes spanning multiple data centers, gaining features such as link resiliency in the process.
This year marks the first year that we are doing full scale rendering of our SPA application on our mobile.walmart.com Node.js tier, which has provided a number of challenges that are very different from the mostly IO-bound load of our prior #nodebf.
The infrastructure outlined for last year is the same but our Home, Item and a few other pages are prerendered on the server using fruit-loops and hula-hoop to execute an optimized version of our client-side JavaScript and provide a SEO and first-load friendly version of the site.
To support the additional CPU load concerns as peak, which we hope will be unfounded or mitigated by our work, we have also taken a variety of steps to increase cache lifetimes of the pages that are being served in this manner. In order of their impact: