IoT considerations — Frontend and Apps

There are some essential design choices to make early on when building the frontend for your IoT application.

Should you run your UI server side? Client side? How about apps — do you need to build separate apps for all the major platforms? What about desktop? How about other ways your user needs to interact with your service?

Let’s run through some of the issues in more detail.

[This article is part of a series of things to consider when setting out on an IoT project. If you missed the previous articles, the overview with links to all the other content is here.]

Where to start

There are many different competing requirements which will affect your Frontend / App design.

The users need it to be slick, fast, easy to use and beautiful.

You need it to run in the browser, in apps on phone and tablet, maybe on a desktop app, or perhaps a touchscreen. It may even need to run on some smart watches or elsewhere.

Your developers need it to be easy to build and manage, and will vastly prefer not to have to build multiple side by side versions for different platforms.

So, how do you reconcile all these and find a strategy which is rational?

Approach — Server side vs Client side

To start with, let’s turn the clocks back a little.

10 years ago JQuery had only just been released. IE6 dominated the market, with Firefox and Safari having just 12% share. To put it in context, Netscape Navigator still had a 1% market share.

AJAX was possible (just about) — IE6 used the (truly wonderful!) ActiveX for this. But it was by no means mainstream. So most websites were almost completely server-side.

Server Side

The traditional approach was to completely render the finished pages at the server, then serve the html, styles and resources down to the browser as a fait accompli. The user clicked a link and the process would repeat itself for the next page.

Benefits? This is very easy to do — you write one monolithic piece of server side code and the clients access the resulting generated pages. Security is easy, as it can all be handled server side. Managing updates to your application is also easier — as there are no clients to update.

Problems with this approach?

The user experience can be poor, taking a lot of time to navigate and move between pages, as each request has to be dealt with by the server and returned once ready. Example — When was the last time someone said “I’m glad I have to wait five seconds for this amazon product page to finish loading”?

Scaling it is difficult as you need to handle all your user’s requests on the server.

Want an app? You’ll have to write a separate client for that and build some APIs for it.

Client Side

Let’s look at how things have changed over the last ten years. User interface is no longer primarily a “web page”.

People access services through phones, tablets, desktop applications, touchscreens, TVs, smart watches and even Fridges (and of course don’t forget the browser!)

Apps are everywhere. Javascript is ubiquitous, as is HTML5. APIs are widely used.

This new, distributed model requires a different approach. Instead of a single monolithic web server, a better approach is to separate the frontend completely from the backend services.

In this case, you write the frontend as a “Single page” application . I don’t mean that you put everything on a single page — but rather that in the case of the browser you serve everything the user will need to interact with your application in one go.

All the HTML, javascript, CSS, images, fonts etc are all served to the user at startup, and from there on the user interface will run entirely locally on the user’s device. From there on, the only data passing back and forth between the server and client is just that — data.

The entire logic for the frontend runs in javascript on the device and is self contained. Various open source frameworks exist for making this easier — Backbone, Ember, Angular and React for example.

We’ll take a look at the benefits of creating a separate client side “HTML5” frontend in more detail shortly. But first — how about the problems?

It’s more complex. It’s harder to debug. You need to test on many more devices. Browser support can be an issue. Security can be tough. Etc. Etc.

But — the benefits are big, as you can use the same code for other things. So let’s explore the positives in more detail.

Apps

Historically, creating apps was separate to building the website. For iOS there was objective-c. For Android or Blackberry, Java. For windows mobile, .NET.

The App store, for example, specifies that the resources for the app must exist locally, so building an app with a simple webview that displays html pages from a server-side website is not allowed. Anyway, this would be a poor experience for the user.

So, as apps grew it lead to massive duplication of effort to build the website on one side, and the app on the other, along with an API for the data.

But — unless you’re writing complex games — a native app is not strictly necessary. Instead, it is possible to take your client-side HTML5 frontend, package it up into an app wrapper to create the app and you’re done. Minimum duplication of effort= big gains.

Apache Cordova and Adobe Phonegap allow you to package your HTML5 frontend into an application for the major platforms, for example spitting out a .apk file ready to submit to the play store, or an app for iOS, Windows Mobile or Blackberry. They also expose many “Hybrid” APIs letting you access things such as the camera or network on the device.

Other options also exist — Frameworks such as Ionic let you build a mobile app using HTML5 and angular, so you can reuse a lot of your frontend code.

So — build multiple apps or port your current frontend as-is into a packaged app? I know which I would prefer!

Desktop

How about if you wanted to create a desktop app, targetting Windows, Mac and Linux?

You could build some native apps using a platform suitable for each (think .NET on Windows), or perhaps find a cross platform option (QT — but the UIs here were traditionally terrible).

This leads to additional development effort, more code to write, and another thing to support.

How about if you could package your frontend directly into a desktop app? Companies like Slack have done it, and others such as Spotify build hybrid apps where chunks of HTML5 code are tied together using C++.

This is easier than it sounds — take a look at the open source Electron framework from Github — where you can build cross platform desktop apps for Windows, Mac and Linux using HTML5 (and if your client side frontend runs in a browser, it’ll work here.)

Other devices

What if your shiny IoT gadget you’ve created has a touchscreen? How do you run the app on there? You could write a custom application for embedded linux, or maybe you could just create a custom QT wrapper or use electron and package up your client side HTML5 frontend.

What about smart TVs? If they’re running android — just package a new app targetted at them.

How about smart watches? Well, this one is a bit of a stretch as it’s unlikely your frontend will be suited to the tiny screen, and they often have limited resources. But take a look at CocoonJS for example of what might be possible.

Does it tick all the requirements?

So, how does client-side stack up to the requirements of all the stakeholders I mentioned at the start?

Benefits for you

You’ve ticked off all the platforms from your list. If you get the planning right a single set of specs will cover all interaction between the user and your service.

Benefits for the user

A client side HTML5 frontend is much faster than server side. Look at gmail — try the standard interface and then go back to the html only one. See the difference?

The user can interact with a beautiful UI, with CSS goodness aplenty. If you can make it look good in a browser, it can look good anywhere.

They only ever need to interact with one UI. Sure — it may be smaller on some screens and bigger on others — but as long as you keep it logical, the user experience is consistent across every platform.

Benefits for the developer

Development — while conceptually tougher — is much easier in the long run.

While you will need to test on all the platforms, you are only supporting one core code base — and that is preferential to having many different code bases for each platform.

You don’t need an Android dev, an iOS dev, a .NET dev, a backend dev, a frontend dev, and more. Everyone works in a common language — javascript. Instead of hiring experts in each of these technologies, you may be better off having a team of excellent “full stack” javascript developers with some good UI people.

If you are using something like Node.js on the server side, then you could re-use a lot of code client side. This minimizes duplication of effort.

Conclusions

I set out to compare the options at the start of this article, but as I wrote it it became clear to me that a server-side frontend is far from the best choice for an IoT application. I’ve worked on projects using both server side and client side frontends in IoT applications, and I know which one I would choose!

Building a client side frontend is a big timesaver, if done right. But it’s not as straightforward as it appears as you really need to nail your specs and infrastructure plans early on in the project.

I’ve barely scratched the surface of the how — you will still need to think about how to deal with security (think tokens or OAuth), connecting to the API (maybe REST and some real time transport), and many other issues.

Make sure you think carefully about the frontend before you start your next IoT project!

Next edition, I’ll take a look at Open source and licensing — how you can accelerate your development by using existing libraries safely.

Update — Part 9 is now available: Open source and licensing

—

Des Flynn is CTO of Lattice Research, who help companies to design, build, deploy, operate and service innovative and cost-effective IoT control systems to meet their customer’s needs. More information at www.lattice.ie