Choosing a platform
Published on 2015-12-31
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
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
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
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
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
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
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!
(games for mobile along with frontends for cloud services is separate categories)