Go, or Ruby or ExpressJS for an API?
I'm building out an API and I would like to know your thoughts on the benefits and pitfalls of the three language options. I'm a Ruby Pro but I am considering both express and Go for my API.
12 comments
We use Node.js with Express and some pretty simple but very effective middleware we wrote to make API development a little more robust, like automatic metrics collection, logging, proper error handling etc. I have 0 Ruby experience so I can't comment as to how it would compare.
I would say neither Go or Node would be a bad choice, each having their tradeoffs. Node honestly is very performant overall given the time in which it takes a developer to code, test and deploy (tradeoffs). Also IMO Node has a little more available in terms of examples and people that have already hit the issues ahead of you. So if time to completion is important, it might be faster for that purpose alone. Then if you find a hot path, work to optimize it etc.
For what it is worth too, I hear people complain about Node occasionally and it is usually when they are trying to do longer running tasks, like huge sorts etc. Node is not a good candidate for work that blocks the event loop for long periods, there are better tools for that as you probably already know. The other complaints I hear/see often are when people choose the wrong 3rd party plugins to base their systems on. npm makes it easy to install almost any module, and sometimes that low barrier makes for easy but less than stellar choices; its like anything research the module first and try real scenarios as a POC before committing.
Also there are other frameworks other than Express for Node, for example you can check out HAPI which some people have switched to for RESTful API work.
I would say neither Go or Node would be a bad choice, each having their tradeoffs. Node honestly is very performant overall given the time in which it takes a developer to code, test and deploy (tradeoffs). Also IMO Node has a little more available in terms of examples and people that have already hit the issues ahead of you. So if time to completion is important, it might be faster for that purpose alone. Then if you find a hot path, work to optimize it etc.
For what it is worth too, I hear people complain about Node occasionally and it is usually when they are trying to do longer running tasks, like huge sorts etc. Node is not a good candidate for work that blocks the event loop for long periods, there are better tools for that as you probably already know. The other complaints I hear/see often are when people choose the wrong 3rd party plugins to base their systems on. npm makes it easy to install almost any module, and sometimes that low barrier makes for easy but less than stellar choices; its like anything research the module first and try real scenarios as a POC before committing.
Also there are other frameworks other than Express for Node, for example you can check out HAPI which some people have switched to for RESTful API work.
I've just finished building an API in Go, and my experience was:
You have to write more actual code than in Rails (or even ASP MVC), so it takes longer to develop, but it's much more satisfying.
I'm not 'web-scale' so the speed differences didn't actually matter that much. I didn't optimise for speed and the benchmarks were still impressively exceeding our requirements.
The standard library is amazing in places, but there are some libraries (gorilla in particular) that are almost obligatory.
If you have to write 2 API's you'll re-use a lot of code... you've effectively rolled your own API framework.
If your editor can handle snippets, make one for "if err != nil{" since that's a good 25% of any go program it seems ;)
Go is deep; the tools are deceptively simple and amazingly powerful. I refactored a lot as I went along and discovered better, more elegant ways to do things I'd brute-forced on the first iteration.
It was fun! Go is a really lovely language to code in.
You have to write more actual code than in Rails (or even ASP MVC), so it takes longer to develop, but it's much more satisfying.
I'm not 'web-scale' so the speed differences didn't actually matter that much. I didn't optimise for speed and the benchmarks were still impressively exceeding our requirements.
The standard library is amazing in places, but there are some libraries (gorilla in particular) that are almost obligatory.
If you have to write 2 API's you'll re-use a lot of code... you've effectively rolled your own API framework.
If your editor can handle snippets, make one for "if err != nil{" since that's a good 25% of any go program it seems ;)
Go is deep; the tools are deceptively simple and amazingly powerful. I refactored a lot as I went along and discovered better, more elegant ways to do things I'd brute-forced on the first iteration.
It was fun! Go is a really lovely language to code in.
Depends on your needs. If you need to get something up and running quickly, I would recommend you stick with Ruby.
If you can afford some extra time to learn a new framework then both Go or Express/Node.js are great options that would enhance your skill set.
Node.js and Go are both growing quickly in popularity. They're much faster on the execution side than Ruby and provide additional optimization opportunities via the ability to query more than one external resource simultaneously and combine the results into your API's response.
If you do decide to go with Node.js or Go, Node.js is currently the more popular of the two. You're more likely to be able to land a job or freelancing gig with Node.js skills today, whereas you're more able to contribute something meaningful to the Go ecosystem by getting into it now.
Personally I prefer coding in Go, but most of my client's request Node.js.
If you can afford some extra time to learn a new framework then both Go or Express/Node.js are great options that would enhance your skill set.
Node.js and Go are both growing quickly in popularity. They're much faster on the execution side than Ruby and provide additional optimization opportunities via the ability to query more than one external resource simultaneously and combine the results into your API's response.
If you do decide to go with Node.js or Go, Node.js is currently the more popular of the two. You're more likely to be able to land a job or freelancing gig with Node.js skills today, whereas you're more able to contribute something meaningful to the Go ecosystem by getting into it now.
Personally I prefer coding in Go, but most of my client's request Node.js.
Do you have any benchmarks between go and node? I'm so curious about this.
Here's a couple links that touch on Node.js vs Go performance.
http://jaxbot.me/articles/benchmarks_nodejs_vs_go_vs_php_3_1...
https://news.ycombinator.com/item?id=6649606
http://jaxbot.me/articles/benchmarks_nodejs_vs_go_vs_php_3_1...
https://news.ycombinator.com/item?id=6649606
Ruby if you want quick /initial/ development.
Go if you need performance, but slower development time.
ExpressJS/Node for neither. Just kidding, it might be sort of like a combination of the two, moderate development and moderate performance. Though, this sort of makes it's usefulness moot for me, but that's /just/ me. I either the fastest development time, or fastest application. Both usually ends in a clusterf*ck of some kind (IMHO).
Personally, though, I wouldn't use any of the above except Ruby and would use something JVM based. Play! is a mature framework, it's fast, and is easy to use/deploy. It also comes in both Scala and Java varieties.
I've used everything mentioned but Go, and the JVM keeps coming back to haunt me because it's fast as hell and has TONS of libs.
Go if you need performance, but slower development time.
ExpressJS/Node for neither. Just kidding, it might be sort of like a combination of the two, moderate development and moderate performance. Though, this sort of makes it's usefulness moot for me, but that's /just/ me. I either the fastest development time, or fastest application. Both usually ends in a clusterf*ck of some kind (IMHO).
Personally, though, I wouldn't use any of the above except Ruby and would use something JVM based. Play! is a mature framework, it's fast, and is easy to use/deploy. It also comes in both Scala and Java varieties.
I've used everything mentioned but Go, and the JVM keeps coming back to haunt me because it's fast as hell and has TONS of libs.
I think the best platform to begin with is the one you are most familiar and comfortable with. Node and Go both have performance benefits over Ruby. If you are a fan of the intricacies of javascript, you can give Node a shot. I don't think Go has much of an ecosystem compared to Node yet.
I've developed/am developing an API in Go.
Go's not quite mature, and it shows at times. For example, if the tcp connection underlying your database connection dies, it won't reconnect automatically.
The standard library is neat; net/http is friendly and easy to use but unless you want to spend half your time munging request.URL.Path with regexes you'll want to use a different mux / router from the standard library - there are many good ones available.
Channels make realtime (ie, websockets) quite simple, and the type system means you can iterate quickly without so much fear of introducing bugs.
I can't speak much for the performance; we haven't tested it under much load yet.
Go's not quite mature, and it shows at times. For example, if the tcp connection underlying your database connection dies, it won't reconnect automatically.
The standard library is neat; net/http is friendly and easy to use but unless you want to spend half your time munging request.URL.Path with regexes you'll want to use a different mux / router from the standard library - there are many good ones available.
Channels make realtime (ie, websockets) quite simple, and the type system means you can iterate quickly without so much fear of introducing bugs.
I can't speak much for the performance; we haven't tested it under much load yet.
I think the performance question is the one I am most interested in. Go seems to boast about its speed and efficiency. I'd be curious to know your results in the future!
I built the Steam integration API for a semi-popular MMO using Go. It's type system, marshaling/serialization and concurrency features made it ideal. The compile & load times are faster than even just loading a Rails app.
As mentioned in another comment, yes, most Go database drivers do not reconnect for you. It's an easy enough pattern to code for yourself. Some PHP & JDBC adapters don't either.
Memory usage was under 10MB and Valve eventually called us asking to throttle our calls, as their servers couldn't keep up and exhibited race conditions. Delays needed to be added to our job queues.
As mentioned in another comment, yes, most Go database drivers do not reconnect for you. It's an easy enough pattern to code for yourself. Some PHP & JDBC adapters don't either.
Memory usage was under 10MB and Valve eventually called us asking to throttle our calls, as their servers couldn't keep up and exhibited race conditions. Delays needed to be added to our job queues.
It seems that Go is fast, so if you expect a very high volume and want to keep the server bill low (I don't know about the developer cost comparison) it might be the way to go.
I've used Sails.js (built on top of Express.js) and can't say it's anywhere near Rails yet.
Also, Node maybe be the "wrong" tool for building APIs. By wrong I mean it's not its particular strength.
I've used Sails.js (built on top of Express.js) and can't say it's anywhere near Rails yet.
Also, Node maybe be the "wrong" tool for building APIs. By wrong I mean it's not its particular strength.
Why do you consider it wrong? It seemed almost ideal especially expressjs when breezing through the dev docs
As I said, I've used Sails.js. Their ORM is subpar, doesn't even support associations yet.
By wrong I meant that where Node.js shines most is in its unified approach to client/server relationships. Since you're building an API (as in server-side logic with world-facing endpoints) you may want to stick to Rails, since it's great at that out-of-the-box, for tried-and-true.
You can't judge the platform by one framework. Node.js also shines in concurrency and networking, which are valuable things for an API, and allows you to offer streaming endpoints with ease.
I would say: Go with the language you're familar with if it's a serious project (API).
In the past, I build APIs using nodeJS with restify. Here's a boilerplate made by a good friend of mine: https://github.com/dominiklessel/restify-api-boilerplate
In the past, I build APIs using nodeJS with restify. Here's a boilerplate made by a good friend of mine: https://github.com/dominiklessel/restify-api-boilerplate
I am writing an API in Ruby right now, and absolutely loving it. It's quick and simple. I am using Grape framework (rack based) : https://github.com/intridea/grape
If you're interested in other Node options, the good folks at WalMart Labs have built this "Express for APIs" framework:
http://spumko.github.io/
http://spumko.github.io/
If you go with Ruby, try sinatra-synchrony.