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.
Go, or Ruby or ExpressJS for an API?
1–10 of 19 posts
Re: Go, or Ruby or ExpressJS for an API?
#2It 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.
Re: Go, or Ruby or ExpressJS for an API?
#3Depends 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.
Re: Go, or Ruby or ExpressJS for an API?
#4I'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.
Re: Go, or Ruby or ExpressJS for an API?
#5I'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 -…
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!
Re: Go, or Ruby or ExpressJS for an API?
#6Depends 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…
Do you have any benchmarks between go and node? I'm so curious about this.
Re: Go, or Ruby or ExpressJS for an API?
#7It 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.
Why do you consider it wrong? It seemed almost ideal especially expressjs when breezing through the dev docs
Re: Go, or Ruby or ExpressJS for an API?
#8I 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.
Re: Go, or Ruby or ExpressJS for an API?
#9It 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.
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.
Re: Go, or Ruby or ExpressJS for an API?
#10We 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.