Michael Banzon

Choosing the right development platform is important. Very important!

Think of the platform as the language and library choices along with the environment where the solution is to be deployed - the full stack.

In this article I'll go over some of the choices for platform I have made and why.

The right tool for the job...

Everybody keeps saying you'll need to choose the right tool for the job and that is correct - altough there is more to it.

We need to work with the definition of job to find out exactly what this means.

As I see it the job is a odd type with an array of factors influencing:

The requirements from the user/client
Any legal and other environmental requirements
Runtime requirements
The team working on the solution

Mixing all these factors together in the right amounts gives you the job at hand - but this is not a complete and exact science - which means that most of the time you go with your gut feeling and/or make the team element weigh most (by far) in the equation and let them decide according to their preferences.

The following cases are examples of problems I've faced along with the solution I went with.

Case: An API for currency rates

I was building an API for currencies. It should be able to give the rates of the currencies supplied by the ECB with a given base currency. The currencies renews every night and should be updated accordingly.

First off I started with a regular LAMP stack. With a working system the only problem was updating the currencies every night. As far as I could tell the index wasn't updated on a regular basis - but I set up a cronjob to run every 3 hours to update. The rates was stored in the MySQL database.

This system didn't quite feel right - which made me rewrite it in Go. The Go version didn't need a cronjob it just had a goroutine to make the update every 3 hours. Furthermore the Go runtime eliminated the use for a database as the rates are simply stored in memory. The overall solution in Go was much cleaner and faster than the PHP version - at least for this very specialized and simple system. A nice side effect caused by the simple stack is that the API could now be tested by itself (no extra runtime and database needed) and updates could run through CI/CD very easilly.

Case: Adding functions to a legacy system

Recently I was doing maintainance on a legacy system written in PHP on a standard LAMP stack. I needed to add a page that used a websocket to get live updates.

The changes in the frontend was heavy on javascript and it was easy to also write the backend in javascript (having the frontend it pretty much wrote itself).

To make this composed monster work I moved the LAMP stack behind a nginx proxy and put a Node JS stack beside it exposing the new page and functions.

After doing this change it was trivial to add events to the PHP that made calls to the Node JS backend (internally, not through nginx) to make the websocket events fire properly.

Case: Wedding website

After getting married we wanted to have a site that displayed some pictures from the events of the day.

I ended up writing a very simple web application (for dynamic routing and templating) on a LAMP stack - actually it had no database, it was more a LAP stack.

Case: Desktop application

I have done many desktop applications in my career. I usually write applications that should run exclusively on Windows - and that environment always make me go with a Visual Studio developed application made in C#.NET - usually I do WinForm applications.

For a couple of applications I've been expirimenting with recently I have been using electron (formerly atom-shell). The ability to make a desktop application in HTML (modern HTML5 with CSS3 and javascript) is very exciting - the feeling is very liberating compared to WinForms.

Bonus: Mobile applications

Use native apps!

There is no doubt in my mind that when you are doing anything more than a very trivial application on a mobile operating system you should use the native development environment to make a native app.

You can spice up that app with rendered HTML in selected views - but in general: Go native!