It’s been awhile. Look how big my baby is now:
HUGE. And so many teeth. He’s walking all over, including all over his dada, and keeping us on our toes.
But I digress.
Earlier this year I had the opportunity to go to GopherCon. Since I resumed work in March, most of the work I’ve been doing has been in Go:
I rewrote an API service from Java to Go. The service has a handful of endpoints to manipulate filter strings including create, edit, get by id and get (all) by org, and uses some customized middleware based on go-kit for logging and etc. Figuring out my way around all the company-specific middleware was complicated because it was created by a former employee to make Go development easier for Java developers (I am not a Java dev). Luckily, my very talented co-worker Amy had recently built a similar Go service and I was able to use her work as a template of sorts — while still dealing with a number of unique challenges to the project. Today, this “marketer” API runs in production servicing the marketer platform and a number of additional endpoints and services have been added.
Next, I rewrote a Rails web application from Rails to Go. Did I use a nifty framework to take advantage of best practices in web app development with go, like Buffalo?
NO. We rolled our own. I did look into using Buffalo but 1) it didn’t have version control at the time and 2) it wasn’t compatible with the aforementioned
pain-in-the-ass helpful middleware provided by the company specific version of go-kit. So, standard library it is!
This was really a huge undertaking first to just render a webpage with a navigation bar and a footer, and a placeholder login screen (other colleagues took care of the authorization and user permissions), and then to successfully transfer over two BackboneJS apps that were living quite happily in the Rails app minding their own business before we uprooted them over to Go. What made it complicated? Weird problems, like asset management, getting JQuery and some other JS libraries to consistently work across the app, imports and requires that stopped working without their Rails helpers, handlebars, etc. It turns out that Rails does a lot of work behind the scenes to make things nicer.
It took longer than anyone expected and was a true team effort, but we retired the Rails app and all new work for the marketer platform happens in the Go framework.
Then I wrote a Go script to run asynchronously as a job. The previous two Go projects were rewrites of existing work and the structure was heavily impacted by the requirement to use that damn middleware. I had a lot more freedom when it came time to add a feature to the marketer platform that would:
- send a POST call to the marketer-API to create a new campaign results download request in the appropriate MySQL table and launch the job
- fetch raw SQL results for a given campaign (survey results, for example)
- manipulate the data into reader-friendly format, and save it as a CSV file
- upload that file to AWS
- send a PATCH call to marketer-API to update the download request with a link to the AWS url
- email the marketer a link to the download
- send a PATCH call to marketer-API with a “finished at” timestamp
Whew. Easy, right? It’s just adding a button that says “download” what could go wrong?
(I had to add the button too and spoiler: lots went wrong.)
My company recently adopted a service called Azkaban for asynchronous jobs and ours was a great use case to test it out. As a result, after making the necessary changes in:
- *marketer gateway (Ruby)
- marketer API (Go)
- marketer download script (Go)
- email API (Java)
…this project was the first job live in production.
*The marketer gateway is a Rails translation layer between the front-end web app and the various APIs. It was created as a buffer between Rails and Java, and one day to potentially be made available for external parties. We were going to transfer it over to Go, also, until we realized how painful that process was with the marketer web platform.
THROUGHOUT THIS YEAR I have been called upon to work in programming languages and tech stack new to me, juggling multiple product and engineering priorities, and trying to be a good teammate by asking for design input and code review along the way, and documenting like crazy. One of my favorite moments came at the tail end of setting up the Azkaban job, when two of my colleagues working on a different project realized they needed to use Azkaban for their work, and I was able to help them quickly follow through on that plan by sharing resources and my knowledge of the process.
Was I going to talk about GopherCon? I guess I had a lot to catch up on.
NEXT TIME — building a raffle ticket checker for GopherCon!
(It’s nice to be writing about what I’m doing and learning, though I have next to no free time, and probably no readers left.)