Today we’ll be kicking off the first in a series where we go into more technical stuff than we have in the past. Not everyone will enjoy or even understand these posts, but we hope that it will give those of you familiar with javascript some neat ideas.

Our experience with TagPro made us weary about large monolithic servers. The DDoS problems grew out of control and there was no great way to get around it. As long as we have large servers, we’re vulnerable to simple DDoS attacks. While thinking about the design of Next, we realized that many of our problems could be alleviated by switching to microservices.

We have a microservice for database access, a microservice for player management, stat management, the joiner, and more. This gives us great flexibility and a lot more resilience than in the current model. However, any of you who have tried using microservices before know that communication is problem number one. There are lots of prerolled solutions out there, but all of them have issues in one way or another.

All we wanted was a dead simple RPC library, and no active library we could find would support what we wanted without significant hacking. So, we decided to build our own. We call it Intercom.

Before delving into any of the code, some background. We are using ES6 extensively throughout this project; most of it is transpiled via babel (formerly 6to5), but there are a couple of features of ES6 that are not transpilable. The one we care most about for the purposes of this discussion is the Proxy object. There’s not a huge amount of documentation for it out there, and its syntax is fairly wonky, but it’s immensely powerful.

A good comparison for it is __getattribute__ in python. Any time you attempt to look up a property on an object, the proxy will intercept it and allow you to override it. So if I call x.blah(), the proxy (x) can decide to send whatever it wants for the “blah” member, which will then be invoked. It’s a great way to accidentally get into infinite recursion.

Why does this matter? It allows us incredibly clean syntax, as you’ll see shortly.
There’s one more thing you should know. We’re using the wonderful ‘co’ library to make our async much cleaner. As a tl;dr, it abuses ES6 generators simulating the async/await features coming in ES7. So for example, it turns this:

Into this:

While it may not seem that amazing in such a small example, when your results depend on 8 different callbacks it makes all the difference in the world.

So, with that out of the way, let me show you how this library is actually used. It’s gone through a lot of iterations, but I think we’re rapidly approaching what the final syntax will look like. Here’s an example of its use from the tests:

Now, this is with an already connected RPC client, but if you have any experience with JS rpc libraries you can see a big difference, in that you can call the actual method name as a method. Before we implemented the proxies, here’s what it looked like:

While still usable, it certainly wasn’t clean. We also had a version that didn’t require the []’s, and also another one that use objects instead, but none of them were satisfying to me. I knew we could do better.

So, how does this magic proxy work? I’ll deconstruct the code below:

It’s a formidable block of code, but we’ll take it one step at a time.

Pretty simple start. We’re just creating a proxy to be used later, and requiring a scope argument. Due to the fact that a proxy is an object we need to provide an explicit outside scope as this can’t be rebound in an object, and that’s what self is.

This is where the magic begins. The Proxy object is a built-in in ES6, and we can only use it using a special experimental flag on io.js, but it’s worth it.

This is called whenever a lookup is done on the object in question. Spoiler alert, we assign this proxy to .rpc, which means if we called yield client.rpc.add(99, 98), then o will be the actual object (not actually used), and name will be add.

This just checks if the object actually has the property we want, and if it does, return it.

This uses the new ES6 syntax allowing a variable number of arguments. Basically we’re creating a decorator function which can accept any number of arguments and will pass it along the network and handle everything else.

Creates a promise, pretty standard stuff.

This allows us flexibility over how long we want a request to hang for. Due to the microservice nature of Next there’s always the potential for a server to be down or hanging, and we want to be able to deal with that if that’s the case.

We’re just grouping together the options to be received by the intercom library on the other side. Nothing fancy, except args is that array from before that I mentioned.

This uses (for now, we may change to something more low level eventually) to just emit the RPC call to the server, and reject it if it had an error, or resolve it if it didn’t.

So, that’s the client side code. The server side code is quite a bit more complex!

Boy, that’s a lot less clear than the client side code.

All this is doing is handling connections, and once connected it checks if we’ve defined a server api. Let me show you what a server API looks like so you can understand what it’s doing from here on out:

All this does is create a server on 9090, and put those functions into the API. So in the previous code, it’s just looping through those functions.

So now we set up a wrapper. We accept any args and a callback. If there are no arguments, we make an empty array. We push the callback onto the end so if a function wants to handle the callback manually it can.

Then we check if it’s a generator function. If it’s a generator, we want to run it in co before we do anything (like slowEcho above.) So if it is, we apply it with socket as this and then handle the callbacks. If it’s not, we run the function and check if it returned anything. If it did, then we complete the callback with that return data. If it isn’t a generator and it isn’t returning anything, we assume the function is handling the callback itself.

Then we just store that wrapper as what should be called whenever that name is called. This is a Map, a new ES6 data structure very similar to dictionaries in other languages.

Finally, we set up the listeners. If we get any data on the ‘rpc’ channel, check if it has a command. If it has a command, check if we have it. If we don’t, error that back to the caller. If we do, run that wrapper function!

It’s a bit of behind the scenes setup, but it allows us to very easily talk to microservices without the usual syntactic overhead. A simple connection and we’re calling dot methods without ever having to communicate with the original server to get a list. This is also useful as it allows us to modify the API on the fly without the client needing to be notified about it.

As an aside, this library will be open-sourced as we feel it has a lot of utility outside of TagPro.

That’s all for this week. If you have any questions about this code, please do feel free to ask!

Discuss this post on Reddit