Node.js on the Road: Q&A

Node.js on the Road is an event series aimed at sharing Node.js production user stories with the broader community. Watch for key learnings, benefits, and patterns around deploying Node.js.

SPEAKERS:
TJ Fontaine @tjfontaine
Node.js Project Lead, Joyent

Mike Frey @mikefrey
Senior Software Engineer, Sport Ngin

Chris Montgomery @chr_montgomery
Application Architect, Dow Jones

Lloyd Benson lloydbenson
Architect, Walmart

[audience] I do have a question, really quickly before I ask it I want to give an extra shout out to James and Kevin who run the JavaScript meetup here. You've heard a lot about community tonight. Corporations and people who work at them are one thing, but I know that the vast community that I've seen here are the user groups around town. You should totally go to them.

[audience] These people work tirelessly handing out T-shirts and doing other things, and I'm not just saying that because I'm speaking at the next JavaScript user group. So seriously come. John runs a PHP one also, and if you also run a user group and I don't know you, I'm sorry.

[audience] But that out of the way,
actual question, mostly for TJ, there's been a ton of interest recently in JavaScript as a compile target for other languages, and I'm curious if that trend has influenced thinking in the development of Node at all. Like do you a future where Node is a tool that supports, like almost like the JVM that supports other languages, and is that influencing the design at all?

Yeah, I mean there are a lot of people doing very interesting things with Node, both in an embedded way and as a compile target. I think what we are going to see moving forward, at least in the short term is a lot of people, like LineRate out there, I don't know if any of you know what LineRate does, they build switches—bought by F5—where they embed Node right in there. You can like basically do your load balancing by writing a Node application right there.

If what you need is like a super high frequency trading maybe hypothetically as an example. So I think that embedding Node is one thing that we're going to be seeing going forward happening a lot, and as a compile target. Or at least our APIs. I think one of the benefits that we've had from the community participating so much with the APIs and getting it solid, is that people really like the abstractions the we've picked in Node and how we expresse them in JavaScript and so people targeting our API's in that way I think is a fantastic—is a ringing endorsement of the maturity of Node right now.

And so I'm excited to see as many people do that, and if people want to treat us like the JVM, I would love to see Node continue to break Java out of the enterprise and put Node in there, so…

[audience] What
was the hardest other technology to integrate with Node, and maybe what was surprisingly easy?

I think for us, essentially, the
hardest is always just because it's such a big company, like every little thing you can think of that has a service we might poke into, and some of those are great, some of those or not, and so just how awful that you can actually help these problems along is pretty big for us. We actually have again APIs that would take like 30 seconds which is really, really, really bad. So Node a lot of times in many cases kind of saved the day because we can like put a little caching there if we need to, or we can hide a lot of some of the bad stuff that's happening in the background and we actually recently got into a lot of like server-side rendering as well, and that's been relative—especially on the phones, it's been really really huge for us and it took a little bit to kind of get going but that's been really cool.

Yes I'd say at Dow Jones we've had a very similar experience. It's another large company trying to integrate all these different services, and we have services in C#, and Java, and Perl, and Python, and just about any language you can think of. It's such a blind spectrum that we have to connect with, interact with. So it really kind of just depends on the API that you're interacting with, and we've had to put in a few things to very similar situations where like the API is taking way to long, and what do you do to handle that?

You know, you drop it, you ignore it, you do what you need to do. But a lot of what we've been doing is swapping out a lot of these old services, a lot of these old apps and moving them to the 21st Century and putting them in Node, and we've seen a ton of speed up in a lot of areas because of that.

So partially because it's apples to oranges, right? You're comparing a 20 year old Java—10 year old Java stack or whatever it is, to this brand new Node app, so it's hard to compare, but really it's ripping out old things and trying to connect it all together I mean, with the Wall Street Journal for example its huge and we have all of those languages combined in our one app, and they all have to talk to the various different pieces to make up the app, and we've sub apps inside of that and a couple of different Node sub apps along with a couple of other languages mixed in there as well, so it's tricky for sure, but you can't do it all once. You have to do it in pieces, and so try to figure out a way to communicate is difficult but it can be done, I guess.

I have nothing to add. Everything that they said rings true for Sport Ngin as well.

So I'm going to pick that question
up. Just from what I've seen other people have problems with and really, where I think one of the big problems that people have is like I've got existing business logic that I want to incorporate into Node.

And a lot of people approach that like I've got this C library or C++ library hat I need to bring in, and it's difficult right now there's not a lot of documentation for it and there's not—you are relying mostly on V8's non-existent documentation for how to use V8, and so a lot of it is like on that side of like integrating, I have all these other things that I need to bring in, and so there's some frustration on that side and if you approach it the wrong way, and you do something blocking inside that binary add on, you kind of ruined what, you're like, well Node sucks, it doesn't do what I thought it did, and it's just like you have to make sure when you're writing that binary module, you approach it in the right way. And we just need to provide better documentation and better interfaces to make that approachable for people.

[audience] What was the difference in the open source formula that led Walmart to have a framework that they're happy with, and then Sport Ngin and Dow Jones have a framework that they chose to walk away from?

On the Sport Ngin
side, we didn't have someone that could spend maybe the time to maintain and push the framework forward, nor really the marketing presence to make it known either.

When Walmart says it's using something, people are going to listen, right? Because it's Walmart. When Sport Ngin says it's using something, people are going to say, who's Sport Ngin? Maybe not in this market, I mean I think we are fairly known in this community, but outside of twin cities tech, Sport Ngin is a pretty small name. Eran Harmer is also a lot smarter than me.

Yeah I think for us,
I mean we didn't really set out to [feedback]
Sorry.

We didn't really set out to do
a whole framework, and Eran talks a lot about a lot about this. We tried a lot of frameworks, and we just kept running into things that—either we ran into some sort of issue with it, where it just would not scale for us, and it doesn't necessarily mean a technical limitation. It means just like we have like big teams; we don't want to just have like tons of code because we have 100 people trying to make applications right?

And we can't all just share the same, you can't all vi this lib file, right? And have 100 people try and work on the same file, so we just needed a better way to kind of separate it out, and we didn't really want to spend a lot of time again making all this callback stuff going on, and instead we just really focused on what do we need, what can we configure, and do it in a nice way that can be sane for—it's more of a large enterprise way of doing things. That doesn't mean that doing it other ways is bad, for us it just we ran into scalability issues so that's why we ended up tackling it, and because Walmart is obviously a little bit bigger we can spend the time. And even though Eran works a lot on Hapi, its core there lots and lots and lots of people at Walmart that are actually working on those modules that I described in my talk. And we're trying, sometimes the community takes them over, sometimes we're helping the community or sometimes we're just taking ownership of doing those, so.

Yeah I should mention that Dow Jones is definitely not giving up on its framework, and it won't. Really I think the big thing is that we want to swap up pieces where it make sense. But it does solve a lot of big problems, and we have a ton of huge apps running with Tesla, and we've done it successfully.

So we're not going to give up on that by any means, but pieces where it make sense to swap out, and I think the story would have been different maybe if we would have open sourced it from the beginning, or started open sourcing it earlier, but since we've had to maintain it solely by ourselves, there's only a couple people really including myself that really maintain it at this point, and when you have such a big framework that's used throughout the company that's supported by a couple of people competing, not competing but when you have that up against things like Hapi, or other really large frameworks you just can't keep up.

There's just to many good developers out in the community that are giving back to these huge projects, that at some point you are going to start to lose out on all these really fancy features that you don't have time to add to your framework too. So that's really the situation we're in, and we're starting to just pull out pieces where it makes sense, but as a whole it will stay and we'll slowly farm it out to open source where we can.

[audience] Working with a smaller dev shop and being new to the Node.js community, one of the patterns that we've found ourselves following is the promise pattern—a lot other libraries following promises—but the Node.js core very much adhering to the callback pattern, and maybe this has been answered before and I'm sure debated internally, but do you guys see the Node.js core APIs moving to a promise pattern, have you used the promise pattern, and what would you found good or bad about using these promises?

Excellent question somebody want to answer that.

I'm sure you you'll never get that question ever.

Never heard that question before, so
I'll answer this in a couple of different ways.

In the short term, Node's not moving its core APIs to promises. I mean it's not easy to actually add promises to core and continue to support everybody else, and how they are using Node today. And it's really, it's relatively easy for people to promise-ify the core with a bunch of different other modules today. So in the short term, we're not focused on it, but it's something that clearly the community has a desire for. I mean we are still kind of, I don't know if it's 50-50, I don't know if it's more like 70 callbacks and 30 promises. It's not really about that.

I want to be able to provide an API, or the core team everybody wants to be able to provide an API that everybody can feel comfortable with. Some of the concerns that I've had with promises is that some of the implementation details of it can be particularly slow. The V8 implementation right now is moving along faster, it's still kind of brand new to the V8 ecosystem of what they're doing. It takes time. V8 always works really hard about getting it right eventually, it's just that sometimes they release it out there to let people use it so they can see where they need to improve it.

So having a native implementation of promises there that we can work with and try and make a future for Node and people who want to use that is a way forward. And so it's something we're actively talking about and always keeping an eye on, but the idea is to support whatever decision people want to have. Like I want people to write code that they can maintain first and foremost. So if you like promises you should use promises. If you like async or vasync you should use those things to write that code. And control flow libraries are particularly helpful for mitigating some of the memory leak conversations that people have had, because it helps you think about it in a better way, though if I had to give my answer about promises or callbacks, I'd actually tell you the best control flow library for Node is our Flow Control library in the form of streams. And if like you can describe your problem in terms of input and output and a transform, the Node streams API is actually a wonderful abstraction, and it feels monatic, and it feels functional for all those people who want those things.

It's great! You can put dot on every new line, and just like say pipe, pipe. It's great. So we are looking at all those things. We want to enable the community to do whatever they want with Node and that's participate in the discussion is what, if you are a promises lover, we just need to make sure we can support everybody.

Yeah I was going to say at Dow Jones, I think we have this debate every six months or so, and just the last couple of months it came up again, and really it depends on the part of code of where you are at, where it makes sense. In our core framework in particular, we mostly just use callbacks for performance reasons. There have been a few good modules that have come out recently that I like for promises, and I personally like to use promises in various places where it makes sense especially not really really key hot paths, but I like that control flow, but the control flow that we end up using a lot in a lot of our other apps is async, and that's worked relatively well.

Has its good and bads to it as well, but a little bit of everything I think, but there are some promise packages that have come out recently that are much more performant, and make using promises in Node actually viable because performance has been so bad in the past, but they've really improved it quite a bit so it might be something that you could check out again going forward.

[audience] My question is about testing. Loyd you mentioned you are at 100% code coverage, or at least striving for. How hard is that to maintain coverage, and what's your framework?

Code coverage at 100% like I said can be a little bit of a lofty goal, so a big way we accomplish, try to accomplish that is again just kind of simplifying everything as best we can. When you work really hard and get your code actually 100% covered, the really important part is enforcing it. So essentially if you're doing something like NPM test right, and you're doing like Travis or whatever, you actually want to fail, so if you do not meet your code coverage of 100% fail, do not taking anymore PR's unless somebody does that test and we especially do this in an open source too. If it's not green, we're not even going to look at the PR.

We going to say fix the test. You did this new little piece of code, and you need to make sure that you have a test that actually checks this condition. And we go like pretty crazy with lab, where we actually if you have like if check and then you're doing something or set it to empty, you have to have a test that sends an empty bracket and things like that, so whatever you can do is always better than nothing, and the big advantage for us for tests again is that we actually find bugs because we're doing testing in code coverage for us that—it's nice to test all the things and you hope the code doesn't go wrong, but you kind of look at it like why isn't that covered.

Well, that function is actually never used, so let's get rid of it and you can find some really useful things there, or why would I ever run into this condition? This is stupid that I did this, so let's like reorganize the code and it actually helps you write a lot cleaner code.

Eran is pretty hardcore about

He's pretty hardcore.

My understanding is that
he reviews every line of code.

In certain areas, that's true.
I'm fearful when I do a PR, like let's see if Eran is going to be looking at this, I want to make sure and there's like style guide and everything else.

Should almost have little about what would Eran do bracelets.
I've lost an arm, this is actually a replacement.

[audience] So one of the biggest issues people tend to run into especially with large enterprises ,is resistance to introducing new technology. So I'm just curious, from your guys's perspective, where does the conversion start? How do youget people comfortable with the adoption of something like Node?

I'll kind of
start. I don't work at giant company.

I think at last count we had about 160 people, which is the biggest we've ever been. We started using Node about 30 months ago when we were a company of about 60. So convincing the boss is a talk that I've been really interested in giving at some point. Maybe at Node MN or something. But really it's about justification, it's about showing proof. You know, articles about and stories about what happened at Walmart, things that have happened at Linkedin, Groupon, Paypal, Microsoft. The list goes on and on and on and on about companies that have had great success with Node.

The proof is kind of in the pudding at that point. You show success in other giant enterprise scenarios, show some sort of cost saving, some sort of cost benefit analysis, and make the case—make the pill easy to swallow, I guess. And maybe position it as a "we'd like to experiment with sort of technology, we think it's beneficial in these particular use cases, we can dabble, and we can integrate in these ways," and go from there.

That's kind of what we did at Sport Ngin. And we have critical systems that we need to keep up all the time. It's not necessarily enterprise to the scale of Dow Jones or a Walmart, but there's people that are relying on the technology that we build everyday to run their organisations, so injecting Node into that system was a battle that we actually still fight today.

Yeah, at Dow Jones it really came down to the proof of concept, I think, and I talked a little about that in my presentation. But really it was showing something that worked that you could take to a manager or CEO and say, "I wrote this app. It's running in Node, and here's why it's better than the Java app that we had previously." So, it's really showing that Node can perform well in a use case and at the end of the day, I mean pretty much all these companies are just trying to make money, and we want to have fun along the way right?

So we want to make a good use case for using Node, but it really does have some good use cases, and just proving that. In Dow Jones it's really been kind of a community grass roots kind of thing, and so people here and there have tried it out, and started writing apps. People that are passionate, and so it just comes down to small Node communities inside of a large organization that come together and say, like hey we want to do this in this technology because we think it makes sense, and just being the person that does it, so really it just comes down to I guess everyone of you guys at your own company and just trying it and seeing how it goes.

There's also the idea of acting first and asking for forgiveness. I actually read an article about that happening with PHP years and years ago back when PHP was a new thing, and how now it's with Node and people are excited about Node and using it and writing little scripts to help them with their job here.

Writing little things to help them with this other thing over here and you know getting—having that get noticed and say "oh how did you do that so quickly?" "Oh I just wrote this little Node script." Just starting grassroots, revolution from the inside, that's totally a thing, it works.

I'd
say just start out small. Again, we didn't try to solve all of the problems right away and if you start out kind of small and do like a group of concept, just try it out. You probably find that if you started developing and it's taking you forever, right?

And you do this Java stuff and it's really fast for you, that is actually your use case, it's probably not a good solution for you, but I think you'll find when you start using it, you'll be like wow! This is, I can—when I looked at Node code for the first time, I was like, really this actually works? Like there's only like 20 lines of code here, I don't understand how this is a functional web server.

It's not. I'm sorry, I hate to break the news to you.

So, it's just, for me
that was a really really incredible experience for me, so just having that small footprint is really handy from an administration standpoint as well.

I
think the two kind of ways that you've heard it, like if you want to do a skunkworks stealth kind of thing, and you just like put into production, you're like, "Hey I really would like to do a project in Node," and they're like well no you're not allowed, and you're like, well I already deployed it sorry.

I mean like if that's what you want to do you can do that. But I think I think that the Walmart mechanism, like going in like actually we're going to give you analytics about your existing platform, of being like oh see look here, built in Node, and you use Node as this glue layer to sit there on top of these things that you already have, and like give it this composable unified interface out to something else and say, look we can now give this out to the mobile team and we can do something with it. It's an easier way to do that. That's kind of the first step like getting the code done, but then the other side is like the operational question. So you have to win two battles, one of getting approval to use Node and then the other of getting operations to say, yeah I know that we can actually deploy Node. And that's part of the Node on the Road show is about, is like making sure that everybody knows that there're ways to achieve this in production, and so hopefully if you're looking to figure out how to get Node into your enterprise, you brought your boss to Node on the road, and maybe we'll just like, we'll make that a hash tag. I don't know how to make that a hash tag. I'm not in marketing, but I think we should make that a hash tag, like #bringyourboss.

[moderator] So, interesting on that if you flip it on it's end which is OK you are developers; you want to get your boss to be interested in using Node. If you're an engineering manager, and you are trying to figure out how to recruit top engineering talent today, let them develop in Node. In Silicon Valley over the last few years, and now these large companies have started to adopt it, we were seeing little start up companies recruiting people on Facebook and Google, because they were excited about developing in Node, and they Great, Google has good food, but I want to go do something cool, and Node is cool.

And we were literally seeing companies here who decided to use Node because it was the only way they could get the absolute best of the best from an engineering perspective. So, the people in the organisation who are saying, "hey, we should be using Node," those are probably people to keep your eye on as engineers you may well not want to lose to the companies like the guys on stage here are willing to hire them to use Node.

I'm going to ask one last question and then we'll wrap up, and these guys will be around, and I'm going to preface it so that you guys have a minute to think and give my answer, but the question is going to be, a resource, a talk, a video, something you've seen that you think for you is one of the more compelling talks about Node, and it could be how get into it, and how to use it.

The one I'm going to share is about how to get your boss to use it in a big enterprise. So I'll give you guys a minute to think about that, and I'll come around and just ask you for those sort of pointers, and the one I point to is a talk that Eran Hammer gave. It was actually at a meetup that we've put on April of last year in Palo Alto, and it's called The Billion Dollar Question.

It's on the Joyent website, so I have a link if you guys want to it's too long to speak out, but essentially it's at their developer blog, search for The Billion Dollar Question Palo Alto, and Eran walks through very eloquently the process that they went through, the work that they did to get folks within Walmart to really start to think about Node, and allow them to finally do what they've done. I think it's a phenomenal video.

Eran is a great speaker, but really does a good job if you're trying to get some ideas for how to get people in your organisation to start thinking about it. So with that, I'm going to go straight down the line and let you guys share, and I'm guessing that you guys can give Emily at Joyent the links or whatever.

So if you look for them, I'm sure we could put a blog post up for Node Road or something, so you can find these if you can, get the details.

Sure.
It is kind of a hard question because there's a lot of good stuff out there, so it's hard to point to one thing, but for me personally I'm kind of a hands on kind of guy.

So just really jumping in, and there's a lot of great documentation on each of the little frameworks that you might use, so like just going out and building an Express app, and trying it out for yourself and seeing like, a mean stack kind of app and see what happens. Each of those really will just teach you better than reading any documentation ever could.

But even the Node site has some good articles. One in particular I read recently that I really enjoyed, maybe this is a little bit of a higher level not a beginner, but the error handling section I thought was really, really interesting and just gives you a good perspective on what's going on under the covers, and how you should organize and how you should think about your code.

So yeah I guess that's the biggest thing. That and just kind of trying to use some of the newer APIs like streams I've been personally really enjoying as well. So there's some good stuff out on the Node site for that, that I would check out.

I'll answer
this kind of in two parts. The way that I got into Node was a good friend of mine, his name is Blago.

He showed me Node back when I was working at Dow Jones, and he actually pointed me to Ryan Dahl's talk that he gave where he first showed off here's a HTTP server and its four lines of code or whatever, and I was like, wow this is a really, this is a big deal, but the resources that I point people to nowadays when they want to learn Node or when they want to check it out is Nodeschool.io

So Nodeschool.io, go there, they have an ever increasing number of courses, I guess that you run from your console, on streams, express leveldb, I'd love to see one on Hapi…

It's coming. and then it's working on it.

Fantastic.

It was supposed to be here a while ago, but
it's being actively, heavily committed right now.

Excellent, so
I found those incredibly valuable myself. I think the first time I worked through them was at NodeConf last year, working through streams adventure from sub-stacker James Halliday.

Brilliant learning tool. Very hands on kind of just forces you through the entire front to back using streams. So Nodeschool.io. Definitely check that out.

That was going to be mine, he stole it.

Sucker.

He heard it. I was
thinking it. I was thinking too hard about it. I would think another one is actually either Bill Scott's talk from NodeConf EU last year, where he talked about how Paypal brought in Node is a fantastic talk about what they were doing, and they ended up benchmarking a Java deployment right against a Node deployment of the same thing.

Feature parity and that was what the compelling case was for Paypal to make their switch, so that's out there on NodeConf EU from the video.

Yeah.
I would say for me personally when I actually had to learn Hapi right? Because I wasn't Eran, so Eran gave a 2.0 talk and I actually went through it and he has this huge feature like, here I'm going to talk about every feature of Hapi in an hour and a half.

I paused and watched that whole video and decided to actually make a presentation while I'm learning it, that I could give to the local, to the Node MN group, and that's how I actually learned how to do a lot of the Hapi, and he has like tons and tons of these examples, and like just trying to do these little 10 line programs, and say wow! I just uploaded a file, and that's all that is required, and it was really a good learning experience for me. Non-Walmart related for me getting—talking just on the Joyent website for videos and listening to Bryan Cantrill, because I'm really interested in how things are actually, operating rather than necessarily all the nuts and bolts of every little development function and that kind of thing, so there was a lot of good talks on that, so I'd recommend those.

[moderator] Thanks guys. So, thank you guys all for coming and for staying. Hopefully it was useful and appreciated. Hopefully you guys are getting more energized if not already to use Nodes, and very big thanks Chris, Mike, TJ, Lloyd for taking the time to come and do this.
:

Sign up now for Instant Cloud Access Get Started