

How We Improved Our API Response Time by 95% - mxpxrocks10
http://blog.maxcdn.com/improved-api-response-time-95/?comments=1

======
mxpxrocks10
Hi - there was a comment put in from the blog: "Weird, you built two
prototypes but you have based your decision on theory. Any benchmark of the
two prototypes which could show that your decision was the right one ?"

~~~
tdondich
Hey there! Answered on our blog, but also wanted to post our response here as
well:

Hi Matt! Great question. There was prototype code in both GO and Node.JS. The
code written in GO was not fully tested in a "production" environment because
we made our decision on quite a few factors early on.

GO is fantastic as faster development cycles and performing CPU-bound
operations. However, there are places where GO just isn't the right choice for
this particular scenario.

We use GO in various parts of our infrastructure where the piece is small and
meant to process lots of information. However, provisioning zones is not so
much a CPU-bound operation but an external operation bound operation. We have
to wait for nginx to do various operations before control comes back to us.
We're not crunching numbers, we're writing to the data storage for our
provisioning information. This type of operation is further bound to external
factors.

GO is also a language that doesn't have massive adoptability yet. There's a
lot of 3rd party vendors where we use their technology and rely on their SDK's
to interact. Many of those vendors may not have written a GOlang library.
Sure, there's bindings to other languages; however, this is a small hoop to
jump through. Is our provisioning dependent on such libraries right now? Not
so much. However, you have to keep an eye on the long-term future.

We also isolate our backend systems at various levels and have them
communicate via REST API's. You can certainly write solutions in GO to have a
REST frontend; however, it's not the ideal case for GO, in our opinion.
There's a fair bit more scaffolding to put in place which means more code to
maintain. There are some some great libraries out there for this (check out
[https://github.com/ant0ine/go-..](https://github.com/ant0ine/go-..). however,
we have to compare the amount of code we need to write to support the
environment we run in, versus the amount of code that focuses on the core
problem we are trying to solve.

Also, it's pretty difficult to find GO rock star engineers to hire. We have a
couple amazing ones here in our team and we only hire the best. By the way, if
you ARE A GO rock star, we want to talk to you. Reach out to me.

So, what we really wanted to find was a replacement language that is quick to
develop, does well with asynchronous operations, which are external operations
and I/O bound, and is easy to maintain with our existing engineering team as
well as future members.

When deciding what platform or language to use to solve a customer facing
problem, you sometimes can't make the decision on numbers alone. In the end,
node.js has the right balance of features to give us the ability to rapidly
develop solutions that are I/O bound and has the support and maintainability
to ensure we can keep developing the best customer solution possible for
_this_ specific use case.

