LG201: IoT Cloud Server - Micro-Services in the Cloud with Salt!
My path from front-end designer to back-end developer started with Macromedia UltraDev in 2000. UltraDev went on to become Adobe Dreamweaver and was the go-to Web Design software for the Mac-dominated design industry for over a decade.
UltraDev allowed you to use a GUI to connect to data sources and define dynamic regions in webpages. It wrote inline code in Classic ASP which designer, like myself, started to hack about to achieve what we wanted. Extensions were developed and some amazing websites were created without a Computer Science graduate in sight!
Then ASP .Net replaced Classic ASP, and with it came .Net Web Forms and then MVC, far superior programming languages, and compiled code. Designers were never going to make this leap, and Dreamweaver was never going to be able to automate the creation of .Net ASP websites. Dreamweaver swapped to PHP which arguably started a decade of PHP based websites, and kickstarted the whole open-source CMS revolution.
By this time I was working in regulated industries and, reluctantly, had to make the transition to ASP .Net as Microsoft still dominated the enterprise software market. PHP was regarded as slow and financial software was never going to be developed using a non-typed programming language.
Razor Pages in .Net Core
Fast forward another decade, and Microsoft has had a change of direction… .Net Core is a cross-platform and open-source development environment that can be deployed almost anywhere.
The new Razor Pages pattern is offered as an alternative to MVC and has a real retro feel to it, it’s like the good old days… but faster!
In fact, its speed is comparable with Java backends, as illustrated by the extensive testing (link) in Kristiāns Kronis and Marina Uhanova’s research. [1]
Would .Net Core have edged it if they’d chosen Windows servers over Linux… I wonder?
I kind of feel it’s ten years too late to gain the market share this technology deserves, but I love it.
You can read more about it here.
https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-3.1&tabs=visual-studio
Razor Pages in .Net Core is now my go-to solution for building web applications. The CMS running this site is developed in it and the Website where I implement the web-socket server will be too. It enables me to quickly develop sites using a combination of static and dynamic files, and also gives me access to all the incredible features of .Net.
Importantly the middleware pipeline and singleton patterns used to handle web requests and responses allow us to do magical things.
.Net Core Pipeline
The official .Net Core documentation describes middleware in the following way. Middleware is software that's assembled into an app pipeline to handle requests and responses. Each component chooses whether to pass the request to the next component in the pipeline and can perform work before and after the next component in the pipeline. Request delegates are used to build the request pipeline. The request delegates handle each HTTP request.
I can’t improve on that, but, here is an example to illustrate it. One of the standard request delegates is the pipeline is UseStaticFiles(). If the request URL is “/css/styles.css” the UseStaticFiles() delegate will look in the ‘wwwroot’ folder of your WebApp and return the contents of that file. If it doesn’t find the file, it will pass the request on to the next delegate to deal with. The next delegate might be UseRouting() which will pass the URL to Controllers or Razor Pages to render a response.
This is how we will separate Web-Socket requests and pass them to a class that deals with them.
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.1
Azure Cloud Services
As I mentioned, you can run .Net Core pretty much anywhere, and I can develop and debug this offline on my laptop. But for multiple users to use it and for our IoT devices to reach it, it needs to be on the internet. Microsoft Azure has all the services we require and we only pay for what we use.
The services I have set up for the initial build are illustrated below, each node can be scaled almost infinitely and we can add additional services as and when we require.
Once we have the .Net Core WebApp up, the development covered by this module falls into the following broad categories, I’ll explore each in more detail as I go along:
Database Design & Development
Azure SQL Server Database to save details of all our users, projects and devices. We will make life difficult for ourselves by ensuring this is implemented securely.
Class Library Development
Are link between the WebApp and the Database, we’ll automate the creation of the Classes as a starting point, then add some Encryption functions, some Extensions and a couple of Singletons.
Socket Server Library
Add our Middleware to the Pipeline, keep track of connections, handle incoming messages and send requests to the Message Router.
Message Routing
“Jon’s sensor sends Temperature data to his ‘Flat 4’ project twice a second, Simon would like to use that data too in his ‘Brighton Indoor Temperatures’ project, but he only wants it once an hour or his system will be flooded” Message Routing is a major part of this project, secure and fast is key.
Payload & Data Management
SQL or NoSQL, that is the question… The diagram above gives away the way I think I’m heading with this, with the inclusion of the NoSQL Cosmos DB, but we have both options open to us. We’ll also develop the bare bones of an API so we can access the data.
Client Development
With a JSON message structure, and the ability to deliver messages by WebSockets or HTTP POST we have huge flexibility to develop clients. We will also explore the possibilities of developing clients that access sensor data through the REST API.
References
1. K Kronis, M. Uhanova, “Performance Comparison of Java EE and ASP.NET Core Technologies for Web API Development”, Applied Computer Systems, Volume 23, (2018).