A fresh look at embedding a web server - Embedded.com

A fresh look at embedding a web server

Embedding Web Servers has been used as an easy to use device management solution for eons. As an embedded engineer, chances are that you have already worked on this type of technology and have an understanding of the HTTP protocol. Chances are that you have also worked on some of the newer technologies such as AJAX and REST.  However, the traditional GET/POST and/or using AJAX for transferring data between the browser and device may not be the best option. In this article, I will show you how to enhance your web based device management application and show you possibilities that will make your customers stand in awe at your new sexy user interface.

Stop Using HTTP

The first thing you must do is to stop using HTTP. OK, so if you stop using HTTP for communication, how do you exchange data between the browser and the server? The answer is WebSockets, which is a relatively new standard that brings real-time communication to the web. WebSockets is supported by all modern browsers and is designed to provide a full-duplex asynchronous communication channel over a single TCP connection.

The fact that Websockets  provide a bi-directional communication channel between the browser and server immediately opens up some very interesting opportunities for web based device management applications. Because the connection is persistent, the embedded web server can now initiate communication with the browser. The embedded web server can send alerts, updates, notifications, etc.. This adds a whole new dimension to the types of web based device management applications that can be constructed.

Most embedded web device management applications currently operate by simply responding to user interactions. You click a button and this causes the browser to submit the data to the server.  The server performs the command and responds with a new HTML page. This old technology works, but it is a very limiting model. OK, you may have moved beyond the simple GET/POST submit button horror and embraced AJAX/REST. However, the fact remains that AJAX is still a one way asynchronous message sent from the browser to the server and any real-time updates you want to display in the browser require dreadful polling of server resources. You may still think AJAX and REST are the best technology since sliced bread; however, in point of fact, the entire AJAX protocol could be built using Websockets technology. This makes Websockets literally a superset of AJAX so it makes sense that we might abandon a limiting technology for a broader technology.

Single Page Applications

A traditional web application refreshes every time a new page is loaded or the user clicks a submit button. This design concept is basically a no no when using WebSocket technology. If you embrace WebSockets then all communication between a browser and the server should preferably be via one WebSocket connection.

If you have a Facebook account or if you are using Gmail you may have noticed that these web applications do not refresh. There's a new name for these type of applications, they are called Single Page Applications or SPA for short. You can find plenty of information on this technology if you Google “Single Page Application”.

Single Page Applications and WebSockets go hand in hand. In its most basic form a single page HTML5 app is a browser-based application that does not refresh as the user interacts with the page. The best way to look at an SPA is to compare it to a standard desktop application.

Reactive Applications

You must embrace JavaScript when designing an SPA and using WebSockets. None of these two technologies can function without writing client side JavaScript code. Just as a standard desktop application is implemented in some kind of programming language, so is an SPA.

An SPA must dynamically update the HTML in the application as the user interacts with it. Most developers today would consider directly using the browser interface and the DOM crazy talk. There are several JavaScript libraries that simplify  hassling with the DOM such as JQuery; however, most up to date developers have embraced reactive programming using one of the many modern frameworks such as AngularJS, ReactJS, or Vue.js.

Reactive programming is a programming paradigm oriented around data flows and the propagation of change. These events must be propagated to all connected browser user interfaces. For example, say we are designing a simple application for turning a light bulb on or off; the propagation of a user clicking the on/off switch must be propagated across all connected browser windows:

If the click event in one browser is not propagated to all connected browsers, the user interfaces become out of sync and the ones not updated will provide stale information to the user.

WebSockets enable us to respond to user inputs in real time and enable us to reactively update all connected browser user interfaces simultaneously.

A Real Working Example

A fully functional reactive WebSocket application has been prepared by Real Time Logic. The complete example includes two Single Page Web Applications that can be loaded and run directly in the browser without having to install any software. Simply drag and drop the two web applications into two browser windows and watch how the multiuser real time device management application communicate in real time. See the complete tutorial Modern Embedded Web Server Technology for more information.

Wilfred Nilsen, Founder & CTO of Real Time Logic, has 28 years' experience in designing embedded software. Powered by a vision of connected embedded systems, he designed the Barracuda Application Server, tailoring it for the small footprint, real-time needs of embedded microprocessors.

5 thoughts on “A fresh look at embedding a web server

  1. “Well, since your company provides websockets libraries, I'm certain that you would think that is the best way to do things.nThere is however, a broad category of small embedded systems based on lwIP which thrive to work with the minimum possible memory f

    Log in to Reply
  2. “Good article on a perfectly viable development option for new communicating processors.nI use this technique on the ESPRESSIF ESP8266 and ESP32 processors. The libraries are available under Github and they work perfectly.nhttps://github.com/me-no-dev

    Log in to Reply
  3. “Jean-Claude,nnYes, the ESP8266 is a great choice for systems that simply need a small micro controller. However, this article focuses on larger embedded systems where multi user UI capabilities are required. An ESP8266 is not a good candidate for a mult

    Log in to Reply
  4. “Scaprile,nnThis article focuses on embedded systems that require multi user capabilities, such as a PLC. A small microcontroller has limited memory and should focus on user interfaces that one person can use at a time. nnHaving said that, a solution b

    Log in to Reply
  5. “I struggle to think about how we are going to adapt to yet another language, but I guess don't knock it til you've tried it right? I'm sure that someone will eventually come up with the comparisons to say whether or not we should really make the jump to a

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.