Node.js at Walmart: Front End Tool Chain


Kevin Decker, Mobile Web Architect, Walmart

Alright, so I'm going a little bit of a different direction on this talk. Most of our prior topics were covering server side use of Node. What my team focuses on is the front end which we revamped about two years ago using a Node stack that's entirely rendered on the front end. So, there're team that evolved around that is one this kind of JavaScript everywhere. Hopefully the guys on my team who're in the room agree, but basically we're able to choose Node as our tooling stack because it let's us stay in one environment, we're able to develop in the same sort of mentality that we are developing for the front end obviously with a bit more sanity. But the biggest thing that I think Node provides for us is an excellent ecosystem.

Eran touched on this during his presentation, but there's just an amazing amount of tools for developing a front end website within the Node eco-system. There's stylus, there's uglify, there's our own contribution lumbar and mach server, and there's just about anything that you're looking to do, you can probably find a library that is out there that does it reasonably well.

Recently we put together a report that would publish the changes that we have pending in production, and with the juice module, we were easily able to generate nice emails that can be easily consumed. Almost no additional work, just piping it through after an NPM install. Even these slides were developed using a markdown to a slide system which just made a breeze to develop. So one of the things that we have had to tackle on our front end infrastructure was app growth over time. We are now covering multiple different markets; we have many different people who are asking for a large variety of features, and it's an exponential growth that is hard to deal with, and we are taking the standard approach that almost everyone has gone, and that's components which are great, but we've had some problems with trying to figure out what exactly is deployed when, and how to make sure that everything is in place when we are doing the release. Most of this is based off of bower, but there's also some NPM issues that we have throughout our deployment process. And this can be dealt with by a bunch of manual processes, checking everything each time, but I really just don't like to do that, I'm kind of lazy, and I would much rather just have something do it for me. Automation is very big in my book.

So to that end, we've
developed a variety of tools that help us track these sorts of things. We have git-todo which is both local git and GitHub API integration that will tell you what you have in your local repositories both in terms of uncommitted changes, unpushed branches, a slide that's not complete.

It will also provide you with up-to-date information on the pull requests that you have opened in any of your GitHub repositories, issues, changes since a tagged version which I think is one of our bigger things that helps us figure out what is going into where. And it's available on NPM, pretty simple to use, just install it globally, there's a bit of config which is documented. I can't show you that because there's some oauth keys involved, but the output ends up having something that's not particularly readable on the screen. But for those of you who can see it, it's just a listing of all the things that you need to take a look at pending. I'm not the best at keeping track of my own apparently.

So in addition to that we
have a release generator tool which allows us to simplify some of our tasks that we have associated with creating NPM or bower packages. One of the approaches that we chose to go was to have release notes for pretty much everything, and we found that those were a bit difficult to generate manually, but with a nice integration on the GitHub API, we can pull in anything that might be pertinent, and dump that out immediately.

Which I have an example of here from handlebars, so you know a pull request went in for a particular version, you know any additional information as well as any compatibility concerns that you might have. This is mostly automated. There's still some element of human involvement because compatibility, it's not going to be as simple like automated solution.

And this is actually the script that I use when I'm releasing the Handlebars project, the only point in here where I have any manual interaction is going to be in between these two steps, the release and Node steps where at that point I have to go in and edit the file that you just saw, and make sure that everything there is sensible, and any human information is in place.

So hopefully I don't botch this one, but I have a pending project that needs to be released. It also has sanity checks. And I know exactly what's in here, so normally I'd spend a bit more time on this, but just making the pertinent changes, and it's going to run all the tests, it's going to tag everything, it's going to—depending on the type of project that you have—notify any related GitHub pull requests that this is a version that you should expect this feature to be in, and for this particular project, it's NPM only, so I just need to do a NPM publish, and we now have the latest version of this tool that generated it's own release.

So all of these are available on GitHub,
at either of these repos or just NPM search for them, and that's my contact information, and thank you very much.


Sign up now for Instant Cloud Access Get Started