Node.js on the Road: Two Years of Node.js at Sport Ngin

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.

A guided tour of how we use Node.js at Sport Ngin including why we chose Node.js, what has worked well for us, what has not, and our plans for the future.

Mike Frey, Senior Software Engineer
Sport Ngin

So as he said my name is Mike Frey, mikefrey on Twitter and GitHub. I work at Sport Ngin, it's a fantastic company. We do tournament and league management tools for sports organizations, amateur, youth. It's a lot of fun, check us out. As he said, I run NodeMN. It's hosted at Sport Ngin, second Tuesday of every month. Come check that out, nodemn on Twitter and

Why did we choose Node? There's a number of reasons. Node is fast, right? Everybody knows that V8 is a very fast JavaScript engine. JavaScript in general has benefited from the competition of browsers over the last 15 years, 20 years. There's also this odd promise of Code Reuse, kind of the holy grail of JavaScript.

I can run the same JavaScript on the server that I run on the client, and I can reuse that code, those templates, everything and gain a lot of value and a lot of speed of development from that. Another reason is the community. So the Node community has always been very vibrant and very lively, and especially over the last several years, it's just exploded. The number of packages on NPM is just about to break 80,000.

A year ago it was sitting around 30, so the community has gained so much speed. Look at the number of people that are here today, look at the meet ups that are happening, and all the talking about Node, it's fantastic. So that's why we decided to start using Node, but how do we use it? So in order to understand how we use Node, you kinda got to understand a little bit about our architecture. We made a transition from a giant monolithic Ruby on Rails application to splitting up and building upon this service oriented architecture.

Along with that we broke up a number of services out of this giant Ruby app, and we also built a number of Node apps on top of that to serve web pages. So at current count, I think we have about 22 apps and services sitting on our platform right now. We manage all of this on AWS. Sorry, Joyent. We do use AWS, and we've built a fantastic system on top of that to be able to very easily manage our applications.

So primarily, we use Node as a proxy point, and an aggregator. When web requests come in, we need to proxy them because of cross origin request issues, and we need to do aggregation because a lot of our Ruby services have a certain API that they want to expose, but it's not necessarily the API that the web application itself needs, right?

So each individual service is trying to serve out to possibly five or six different web apps, and mobile apps as well, so in order for us to make sure that we have the right data for the right needs for a particular application, we use Node to aggregate that data. And Node is particularly suited for this because of its evented nature. So I can make four requests that are also asynchronous out to four different services, get back all that data, massage it into the format that I want, send it off to the web app, and it has all of that how it needs it.

It also allows us to do complex saves, and pushes up data so the same thing, I can send one payload from the browser to do a complex save operation, it will go, maybe hit a couple of different services, sync with some other things, and then get one response back to the web browser about whether it failed or succeeded.

So let's talk about what went well. At Sport Ngin when we started using Node a couple of years ago, maybe 30 months ago, we didn't feel that the necessary—that the framework landscape was very mature. There's I think, Express was the predominant one available at the time, and there was also this talk in the Node community about, "you don't need a framework, why do you need a framework? Just use Node core, it'll be better, you won't be shackled to this thing." And so, out of that, a lot of people built frameworks, including Sport Ngin, so we build a framework called Nokomis, it has actually serviced very well. It's Rails-y in a sense. It kind of takes away the data access portion of that, because we just use use rest services and models on the server don't necessarily need to be long lived, so we skip that part.

But it does have a lot of really nice things like routing, first class controllers (which things like Express don't have), it has life cycle events for "I want to do this before the request happens, after the request happens, or in the middle of the request," so kind of a pseudo-middleware system, and it also has a rich plugin architecture.

So, building Nokomis has it's goods and bads, but it's something that was good for us, and worked really well for us, and continues to work really well for us. Another success that we had was Code Reuse. We're reusing hundreds and hundreds of templates. We're using dozens and dozens of individual modules on the client and on the server. We utilize browserify to run node modules on the client. It's been a big success which was kind of surprising because a lot of the community tends to have difficulty with this, but libraries and systems like browserify help with that tremendously.

Another big success for us was the development speed. On the Node side, development was very fast. Utilizing Nokomis, we had no problem building up responses to our web requests very, very quickly.

So let's talk about what didn't go
well, and the problems that we had were not necessarily problems with Node.

There're problems with—kind of soft problems. Problems that aren't really solvable by applying Node this way or applying Node that way, or applying any other technology. But we did have issues. So one problem right now that we are now facing is that we are in the framework business. We have Nokomis, we use Nokomis.

It's in 8 different Apps right now, and if security vulnerabilities pop up, we're on the hook for those. We got to maintain it, we have to make sure that it's—we're completely on the hook. Our developers internally are completely on the hook for upgrading to 0.12 when it releases. Making sure that our apps can continue to operate on the latest and greatest versions of Node.js. So that kind of sucks.

Another problem that we had is in perception management.
Internally at Sport Ngin, our vernacular says that a front end developer does Node and browser side development, and so our Node development has always been very fast, so speed of development has always been very fast. Our speed of browser development has always been kind of slow for a number of reasons that I won't get into, but it's been slower.

Perception-wise at the company, front end development was slow because of those two things combined, and since Node was the predominant new technology that we were trying out and using, the perception then was that Node.js was slow, and the development speed on top of Node was slow, which isn't the case.

So what's next for Sport Ngin and Node?

Consolidation is a big one. We have, like I said we have eight apps, I think that are running Node now. 21, 22 overall. There's a thought going around, being passed around that maybe we attacked the service oriented architecture thing a little too hard, and broke everything up a little bit too much, which may be true.

So we're going to try to consolidate some of our apps, including some of the Node's apps, so we're actually looking at new ideas around architecture with that one.

We also want to get out of
the framework business, we don't want to be running Nokomis, we want to defer to people like TJ Holowaychuk—sitting right there I think, right?

We want to defer to the people that can actually take the time to maintain these things, which is basically the open source community, right? So it's all of us. So instead of relying on just two or three people inside of Sport Ngin, let's leverage the strong arm of the open source community.

Another bigger thing that we want to do is continue to support the Node community.
NodeMN is sponsored by Sport Ngin, and we're going to continue to support that meet up, continue to support the Node community through events and conferences, and through open source as well. So that's all I've got, so thank you.

Sign up now for Instant Cloud Access Get Started