Day 2 - Coding the backend server

Published by Michael Banzon on Tue Feb 14, 2017

This is the second part of the going full stack series. You can read the first part if you missed it or read the introduction if you haven’t yet done so.

In this post we will start programmig the backend of our application. This post will have some code snippets - but mainly reference changesets in the repository to illustrate changes while focusing on the overall structuring of the code.

Before beggining to program it we must first settle on a development environment and/or deployment stack - mainly the programming language we are going to use.

Choosing a programming language

Let’s cut to the chase.

For a long period of time I have really enjoyed programming Go - especially for backend projects excactly like this one - and it is the choice in this series.

There are many langauges/stacks capable of delivering a solid result in projects like this. The nature of the project is actually so generic that every possible common choice for web service development should be a valid choice.

But Go it is.

Handeling dependencies

I actually suspect that we won’t need any dependencies for this project. At least not the backend.

If this proves not to be the case Go has excellent vendoring support - which will make sure that everything needed to build and test the backend is in the repository.

Routinely doing a task

When programming Go you make the server - your programming is always running (in the following there are some examples where this is not the case - and this will highlight the advantage further).

In the previous post we specified that the currency rates should be fetched every hour - this is an relatively easy task in Go. The standard library makes it possible to do the following:

go func() {
	for {
		updateCurrencyRates()
		time.Sleep(1 * time.Hour)	
	}
}()

I won’t dive into the details - but this will actually call updateCurrencyRates() every hour. Simple as that.

Alternative stacks

As mentioned earlier there a plenty of alternative software stacks for creating and running the backend. Several come to mind:

  • PHP
  • Ruby (Ruby on Rails)
  • Node.js
  • Java
  • Scala
  • ASP.NET

… and there is plenty more - new ones emerging all the time. All of these are actually perfectly valid choices - but they all come with their various advantages and disadvantages.

One of the bigger reasons to choose Go compared to PHP and Ruby is actually in the routinely task management described in the previous section. Normally the stacks running PHP or Ruby handle requests in a separate server (like Apache) handling one request per PHP/Ruby process/thread - in this case this means that our code is only running when requests are made to the server.

Usually in scenarios like this a cronjob is set up to request a special page (possibly with token eg.) to do the actual update of currency rates. This brings a new deployment dependency to the system and the updating request would usually be subject to normal request contraints - maximum request/response time and memory limits come to mind.

Putting it together

… and we’re done. I admit - a little time magic has been applied!

The initial commit has a working implementation of the currency conversion server written in Go. I’d really recommend you read it - it is under 600 LOC in total - with comments package declarations and everything. The code should be fairly easy to follow.

Check out the inital commit.

The code is written as a standard Go project - if you’ve got the Go toolchain set up properly you can:

go get github.com/goingfullstack/currencyconverter

and you’ll have the project in the proper location.

There is no external dependencies except the standard Go library.

What’s next?

Running it!

We are going to run the server we just made. For that we need a machine and that machine needs to be configured properly. We will pick an operating system and go (no pun intended) from there.

Go to day three…