Sunday, 8 March 2015

Go


Last year I was trying out some of the cool features in Postgres and Postgis for generating JSON and GeoJSON in the database.  I wanted to try these features for making a web service and I decided to try a new programming language for the task. 

Here's a teaser of the conclusion - more open data from GeoNet.

The image shows a slow slip event or silent earthquake recorded at the Gisborne GPS site.

Going Go


I had already run through the Tour of Go.  A lot has been written about Go syntax and language features.  I liked what I saw well enough to do some investigation where the hard work often is - putting code into production. 

The Web Server


We've been embedding Jetty in our Java apps and deploying them via RPMs for a long time.  I wanted to write a web service in Go and assumed I would need some sort of additional server application to deploy a Go app, or at the very least something to run in front of it.  Nope!  First mistake.  There is a fully functioning web server in the core libs.

Runtime


So I'm bound to need some kind of runtime on production, right?  Nope!  Go apps compile to a single binary. 

Deploying a Go web application looks like this: Drop binary on system. Start it up. Job Done.

Dependencies and Compilation


There are a lot of powerful features in the core Go packages but external dependencies are inevitable at some point.  I expected some binary package management tool.  Dependency repos in the clouds.  Broken meta data.  Version skew in production and general gnashing of teeth.  Nope, nope, and nope!  The Go compiler is so fast you compile all your code and its dependencies from source in single digit seconds or less.  It's straightforward to get or vendor drop dependencies for your code. 

Given the C-like syntax, surely I was going to have to write a Makefile?  Noooope.  If you organise your code as suggested the go tool can build it for you with no further help.

Sold on Go


By this point I was hooked.  No Russain Doll JVM+Container+App deployment.  No dependency hell.  No compile and package time taking so long that I could forget what I was doing while I waited.  It is so easy to compile and deploy Go code.  It looks like someone really cares about making our jobs easier.

A Real Project


I turned the web services experiment into a real project - FITS (Field Time Series) - storing low data rate field data collected for the GeoNet project.  FITS code is available on Github.

The fledgling first version of the FITS api is available to use now.

Here's those JSON and GeoJSON functions in action. They return site information as GeoJSON.

Visualizing the data easily from FITS is important.  I used the excellent svgo package.  SVG browser support is now very good and an SVG image handles well in a responsive web page.  The image at the top of this post is SVG straight from the FITS api.


Deployment - Docker


Having gone trendy with the code, I went full trendy with the deployment.  It's deployed in a Docker container.  The Docker build, including compiling the Go code in the container, is done in Quay.io.  The build is triggered from Github commits.  The FITS Quay repo is available.  Getting code to production this way is embarrassingly easy.  Go and containers work together like two things that go really well together... for example, a glass of whisky and another glass of whisky.

FITS runs in production in Amazon Web Services (AWS) in the Sydney region.  FITS uses AWS Elastic Beanstalk and AWS Relational Database Service running Postgres+Postgis for the database. 

Going Forward


I've done a few projects in Go now.  I still really like it.  Go makes building and deploying code as easy as it should be.  Most importantly to me - I'm really enjoying programming like I javan't done for quite a while.

No comments:

Post a Comment