Thomas McGoey-Smith

The Stack

Side: This is a post in my on going series about Rewriting Has It Shipped Yet in Go.

I have a bit of an obsession with software stacks. Usually it’s just a matter of hitting the BuiltWith icon on Chrome and checking out which framework tokens are being used, but sometimes I go straight to the source - the career’s page.

This weekend I’ve been recovering from a bit of burn out from working on Has It Shipped Yet. It’s not too much but I’m starting to feel the pain of the stack I chose.

Originally, I thought Go was the perfect decision. It just made sense. Think about it, I want to display this widget on someone else’s store without worrying about the performance hit, and I just need to expose a single JSON endpoint.

But, things started to break down. To support that single endpoint I needed to create several more endpoints to listen for webhook requests, I need to interface with a MySQL DB (luckily for sqlx), I needed good background processing support since I have several long processing jobs to run i.e. fetching product images from Shopify’s product API.

This was all pretty manageable until I ran into working with background jobs. So far I’ve used Job Runner, but it’s pretty limited (there isn’t a good way to try a retry a failed job).

I thought that it might be best to look at introducing beanstalkd to the mix, but then I started thinking about moving away from Go altogether (at least for the main portion of my app - maybe I’ll use it for a tiny microservice).

But where to?

I’ve been attending a local Ruby meetup each month and it’s been really amazing. The ruby community is extremely welcoming (last meetup we were joined by the local Python meetup).

I’ve also had a soft spot for rails. Despite this past year of me wanting to avoid it at all costs - because I wanted to write my own SQL instead of using an ORM, I’m finding that this was a huge mistake.

Has It Shipped Yet, is pretty much a CRUD app plus I’m never going to run into Twitter style scale problems, so it shouldn’t be an issue.

Plus by moving to rails I can see a few noticeable benefits:

  • It’s old & mature: Now that I have a couple of paying customers, I want to deliver a better more stable product.
  • It’s community is huge
  • Ruby is designed for programmer happiness: This is mostly a side project to test the waters. I really want something that is a joy to program with.
  • Rails is constantly improving: With Rails 5 is almost out of beta and I’m pretty interested in learning more about ActionCable
  • Convention over Configuration: I’m pretty excited about this. Rails does have a bit of a steeper learning curve, but once I get going things should be released much sooner.
  • Better Resale Value: I’m not heading into this for money, but if the time does come. I rather not have technology be a limiting factor to the sale.
  • Testing Frameworks: One of my struggles was figuring out testing my app from top of bottom (integration tests). I’m looking forward to see what the community has in place.

So I’m going to rewrite Has It Shipped Yet again - but this time (and hopefully the last time) it will be done using rails.

I’ll be writing about it along the way - so maybe if you run into some beginner rails problems we can hash them out together.

Till next time.

@tamcgoey on Jan 10, 2016

Enjoyed the article? Subscribe to my newsletter for more.

© Thomas McGoey-Smith (2014-2018). RSS.