Building a Web Application using Golang


As a software engineer, it is always interesting to learn a new programming language. At Osprey Security, when it turned out that I would be involved in a project with Go or Golang as it is also referred to, as the primary back-end language, it was a really exciting feeling. The fact that Golang was designed to be a good fit for server side programming added more spice to all this.

Here I’m going to share my first impression on the language. Quite a few features of Golang will be described in the prism of Java which I used a lot last years.

Syntax Description

What is striking for a Java developer is that Golang is not an object oriented language in a pure sense of this word. Yes, it has structures and you can call functions on those structures, as if you call methods in OOP language but there is no inheritance. Golang uses composition instead. Go front end vs. backendis not functional, but it has anonymous functions, high order functions and so on. As for me, I see Go as procedural language. If somebody asks me to describe Go, I would say… like C.  As in C, there is no exception handling, but functions return error codes instead. There is no function overloading as it regarded a bad practice, but there is support for pointers! (more…)

Using Docker Compose to create a Build Pipeline for Web Applications

Docker is perfect to make the developer’s life easier. Thanks to containers, one can engineer the many facilities that make their application into many microservices, dividing their problem into more manageable blocks. For instance, you can trigger a container for a redis database, along with a container fueled by an node.js / express image, and you can have your infrastructure up and running with no hassle.

Docker can prove handy even for optimizing the building pipeline. Indeed, using docker-compose, the Docker orchestration tool, and volumes, you can build your app stage by stage, passing through shared docker data *volumes* the result of any of these build steps to the next one. At the end of the pipe-line, you would have a container, with access to all of the artifacts that have been built so far – via the shared data volumes – launching the very services of your application.

Docker Compose in Action

But let’s see an example in action.

Say you have a web single page app, architected around a Golang back-end, and a modern front-end, managed by some of the fanciest JavaScript asset management tool of the time, so most probably using node.js / npm.

You have two stages of building here:
1. First, you have to build the *JavaScript* artifacts: you have to launch npm, bower, gulp, etc… to stage your front-end assets for production.
2. Then, you have to build AND run the *Golang* server, going first through downloading your project’s dependencies (assuming you used Godeps), building and installing the *Golang* service, and running it as a daemon at the startup of your app (containerized or not)

If we want to use containers to approach such a situation, we’d have

  1. Prepare a container running node.js to install the JavaScript staging dependencies and tools, generate the Production-ready front-end assets
  2. Store these generated front-end assets in a data volume so we can persist and hand them over to the back-end
  3. And spin off a container running Golang, mount the previously prepared data volume on it, run the dependency fetching, the building and assigning an entry point (that is, the command firing the service upon launch of the container).

As we can proceed to these steps by hand jsut fine, or script them using Shell or whatever, we can use docker-compose, the very useful orchestration tool that comes with the docker toolbox distribution. (Linux users might have to install it by hand) (more…)