Building a smart (IoT) product is more an art than it is a science because it is about unifying the physical world with the digital one. When you put a piece of hardware on the web, magic happens. But one device on the web is one thing. Think about tens of them, interconnected, forging an automated ecosystem of pure reverie. Now imagine tens of thousands of these ecosystems spread throughout the globe. Seems profound, no? But developing an IoT product and then managing it is just as profoundly difficult. It involves development across a huge technology stack (your IoT hardware itself, your apps to monitor/control your hardware and a server back-end to manage them) to make such products work in production. And then in production comes the hardest challenge; you are going to have to scale it up as your user base grows.
Therefore making your system event-driven goes a long way and simplifies processes as you scale. An event-driven system is highly scalable and resilient to failures as components are loosely coupled and can be scaled independently. One part of the system does not need to know about other parts. An event can be generated at one point of the system and is processed at several other points without the source or sink knowing about any who or hows. This makes it a very powerful choice for distributed architectures.
And in the IoT world where thousands of nodes can be connected via web, having event-drive in your system quickly becomes crucial. Switching off most of your appliances and regulating others to power-saving mode when you go out on vacation, fire alarm notifying all members of the house about a could-be emergency, theft-detecting sensors enabling your building's security system and updating the guards about the status — you can't achieve these use cases efficiently, if at all, solely by polling.
And that's why Grandeur is designed as an event-driven architecture (EDA). Devices can listen for updates from their users, users can listen for updates from their devices, users can publish updates to their devices which the devices can react to instantly, and devices can publish updates which the users can make decisions on. And all of this happens almost instantly (with latency of ~200ms 😮).
This tutorial will help you get comfortable with the EDA of Grandeur. Like the last time, we will build an app to publish data to a device in real-time, but this time, we'll put the event-driven nature of Grandeur to use. This tutorial is part of a whole introductory series and we urge you to checkout our previous one too where we simply published some data to a device through polling. If you've read it already or just want to skip over, keep reading 👇.
Step 1: Getting Started
We will continue from where we left off and use the same project and user-device pair we created then. We were sending random data from web app periodically after every five seconds and were receiving it on hardware-end by polling every five seconds. That method, while gets the work done, had one inherent problem. Since you have to check for the updates every few seconds, critical ones may not reach your device as frequently as they need to be. There will always be a delay equal to the time difference between when you polled and when the update really occurred. This time we'll do things in a better way. Instead of polling to get updates from the cloud, we will put a listener which will get us the updates as soon as they occur.
Step 2: Web App
Just like the last time, we have two files: index.html and main.js and the code remains pretty much the same.
Here's the index.html:
<!-- @file: Index.html --> <!DOCTYPE html> <html> <!-- Head block of our page--> <head> <!-- Title of our page--> <title>First Grandeur App</title> <!-- Link to SDK's CDN --> <script src="https://unpkg.com/grandeur-js"></script> </head> <!-- Body block of our page--> <body> <!-- Heading of the page --> <h1>Events with Grandeur</h1> <p...Read more »