My FeedDiscussionsHeadless CMS
New
Sign in
Log inSign up
Learn more about Hashnode Headless CMSHashnode Headless CMS
Collaborate seamlessly with Hashnode Headless CMS for Enterprise.
Upgrade ✨Learn more

Interview with Steve Kaliski, CTO of Bowery - The tech stack that powers Bowery, Moving from Node.js to Go lang and more

Sandeep Panda's photo
Sandeep Panda
·Feb 4, 2015

I recently got a chance to interview Steve Kaliski, CTO of Bowery. Bowery is a service for keeping your development environment in sync. Last week they blogged about moving from Node.js to Go and the post was trending on Hacker News. So, I talked to Steve to know more about the technology that powers Bowery and understand why they moved from Node.js to Go and the challenges they faced while migrating. So, let's find out what Steve has to say!

Bowery

Sandeep : Please tell us a bit about Bowery and what it is all about.

Steve : Bowery is a service for keeping your development environment in sync. It’s a terminal that sits right alongside your text-editor and browser, but unlike your normal terminal, it connects you to an exact replica of your production environment, shared with your team. This makes it super easy to get up and running on a project and avoid bugs that comes from discrepancies between your development and production environments. You can learn more at bowery.io.

Sandeep : What's your tech stack? How do you leverage technology?

Steve : Our service is comprised of micro-services all written in Golang. These services share a common set of libraries (web framework, system tools, etc) making them very easy to build and prototype. Our desktop application is built using Atom-shell alongside a tiny Go client and Pusher for receiving updates from our services. And for our database, we’re in the process of phasing out MongoDB in favor of Orchestrate.io. We use both AWS and Google Cloud Platform for hosting. Presently, we use Docker for managing our containers.

Sandeep : We learned that bowery.io recently moved from Node.js to Go language. Why did you take this step?

Steve : When I worked at Poptip we underwent a similar transition (in late 2012 / early 2013). A combination of performance issues from Node.js and a planned overhaul of our architecture gave us a good opportunity to make that switch. When we began Bowery we stuck with Node, which was the most familiar for my co-founder (who had been writing it at Medium) and myself.

We first dipped our toe in when re-writing our command line interface. Our first engineer, Larz, and I both had some experience in Go and decided it was worth pursuing so that we could easily deliver a cross-platform cli. As the team gained confidence in this one switch, we started migrating our other services over as needed.

And coming from a Node.js background, writing in a statically typed language and not dealing with callbacks has become a blessing. The opt in for asynchronous behavior using goroutines and channels is a much easier model to work with in my opinion. I’m a stickler for code readability and transparency. The presence of that behavior visually, rather than intrinsically, increases both.

Sandeep : What was the biggest challenge that you faced while migrating to Go lang?

Steve : As with any change, the biggests challenges are in familiarity and usability. It requires the whole team learning how to write and use Go. And I put the distinction there because understanding the syntax can happen pretty quickly for a affluent programmer. Learning how to use the language is something we’re still working on. There are node modules and practices we would often rely on that we no longer had. It requires some adjustments to the understand new language community, the offerings of the core libraries, etc.

Sandeep : What are some cool features of Go that you didn't find in Node.js?

Steve : Goroutines, channels, and cross-compiling are definitely the coolest. Though Node is async, being able to jump into it using go func() { … } is super awesome. It’s a relief to not write in callbacks, but be able to make use of async when it is beneficial. The cross-compiling is obviously super helpful for us since our application has to work on Mac, Linux and Windows and 32bit / 64bit for the latter two. And on top of that, the testing framework being built into the language is so helpful.

Sandeep : If you could improve one thing in Go what would that be?

Steve : Package management. There are some great efforts like Godep to keep stability within your application’s dependencies, but it lacks the same utilities (and networking effects) that NPM has. That is not to say I was a fan of NPM. It’s another point of failure in your system and it often results in confusion regarding what packages to use. The quantity of open source projects is also limited (JavaScript/Node.js is the #1 most popular language on GitHub). We’re working to help improve this by releasing lots of open source projects.

Sandeep : Tell us a bit about your future plans for Bowery from technology point of view?

Steve : Improving performance for loading/saving containers is a huge priority for us and will likely involve some type of distributed file system. We’re also working to provide better integrations with existing provisioning tools (think Puppet, Chef, Vagrant, etc). Bowery sits inside your workflow, right alongside your text editor and browser. Thus it’s crucial to be able to integrate well with other technologies and services. If you want to use Bowery and have ideas for necessary integrations we’d be happy to hear them!


I hope you enjoyed reading the interview. Here are a few resources in case you want to learn more about Bowery.

If you have any questions, please add a comment.

Thanks!