We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:

• Go, the server-side language from Google
• NodeJS, an asynchronous framework in Javascript

We built prototypes in both languages, and decided on NodeJS:

• NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
• NodeJS acts as an HTTP-based service, so exposing the API was trivial

Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.

The first time I actually started using Go was for software on our devices. So on our hotspots we have some custom software running in the firmware. For the first device, that was actually completely built by our manufacturer. But for the second generation most of the parts are built by us in-house and we needed a way to quickly develop software for the device. But we don't have any C programmers in-house, so we were actually looking for something that basically sits in between the friendliness of Ruby, but the performance and the ability to be deployed on an embedded system which you get with C. That's basically what led us to Go and it's been awesome for that. It works so well and so great. Since it works so great, it pushed us into looking into whether we should start using this for some backend services as well.

The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.

All backend code is done in node.js

We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.

We've written a few internal modules including a very simple api framework.

I ended up picking Node.js because the game client is entirely in JavaScript as well. This choice made it a lot easier for developers to cross borders between being "client side" game developers and "server side" game developers. It also meant that the pool of knowledge/best practices is applicable almost across the company.

Node.js is the foundation for the server. Using Express.js for serving up web content, and sockets.io for synchronizing communications between all clients and the server, the entire game runs as Javascript in Node.js.

I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.

As for why I chose Node.js... I just love JavaScript! My code is all original, meaning that I didn't have to inherit anyone's bad Javascript. I'm perfectly capable of creating my own bad Javascript, thank you! Also, npm rocks!

Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.

The following basic API endpoints are implemented on the server written in Go:

• Authorization (Sign Up, Sign In)
• Update user profile
• Community: add post, like post, add comment, delete post, add reply to comment
• Self-diagnosis: send data from the app to the server
• Journal: send user data from the app to the server
• Add groups of community
• Report post, report comment, report reply
• Block user

We wrote our own image processing, resizing, and snapshotting service in Go to allow our clients to send photos and GIFs to each other. Files are stored in S3, resized on the fly using OpenCV, and then cached in GroupCache before being served to clients.

Go allows it all to be quite fast and efficient, and entirely non-blocking on uploads!

Our main web scraping engine is built usign Golang because of the way how efficiently and fast this language is. Also out compilation facility let people who dont know Golang build fast as flash scrapers to run ourside of our platform without any knowledge in programming in Golang.

For some of our more taxing parts of our applications, something able to handle high I/O load quickly and with fast processing is needed. Go has completely filled that gap, allowing us to break down walls that would've been completely impossible with other languages.