Permanent Presence
Service workers enable offline experiences for Progressive Web Apps (PWAs).
But what happens with external services, clients, and devices that need to interact with your offline app, or your offline IoT devices? They all have to wait.
And most IoT devices are not directly exposed to the Internet, otherwise they would be compromised in minutes. Connectivity is not always symmetric, making remote interaction even more difficult.
With Caf.js, devices and web app instances are accessible at any time, from anywhere. Reverse Service Workers (RSWs) keep these interactions safe. A three-way isomorphic framework enables quick prototyping of new sharing experiences.
Let's look at use cases first, and then describe the technology.
Safe sharing of Bluetooth devices
So many Bluetooth devices around us. An indoor exercise bike, a heart rate/ECG monitor, a connected toy, an smart light bulb, a speaker, a temperature sensor, a thermostat, a drone, a fridge, a watch, a battery, a car diagnostics tool...
What if you could instantly share them across the Internet? With your doctor, your fitness instructor, your friend in a Zoom session, your colleagues working from home, a remote expert...
And do that safely, with no complex setup, with just a browser. E-mail or text a URL to your peer, and with a click on the link they control the device. And you can revoke access at any time, or let the link expire.
With Caf.js you can do that with a few hundred lines of JavaScript. Some examples in GitHub: HealthyPi (watch video), a cheap ECG/Body temperature/SPO2 monitor. Puck.js (watch video), a programmable beacon with many sensors. And it is easy to build your own with our app generator tool.
Integration of physical devices in VR/AR
When your real home is embedded in a virtual world, an action in VR could switch off the lights of your home, thousands of miles away.
You can implement this today. Design an avatar for your lamp, and make it forward actions to your home across the Internet.
But this is hard to get right. Any visible delays, or connectivity issues, will ruin the virtual experience. And directly exposing your lamp to the Internet is risky.
Instead, Caf.js can take care of the backend for your lamp avatar, ensuring safety and predictable latency. And then you can focus on making the avatar more realistic.
What about AR? In AR you are likely to share the room with the physical lamp. And when you look fixedly at it, a user interface will pop up to, for example, change its color hue.
The connectivity challenges with AR are not any easier. What if the lamp is in a vacation rental, or in a shop, or at the office? It would be much easier if the AR client device just needed Internet connectivity, and the access policy was centrally managed. This is what Caf.js enables.
But the real fun starts with some remote team members in VR, and others local in AR. And they all collaborate in real-time by interacting with shared physical devices. With Caf.js all these user interfaces, and the state of the connected physical devices, are always in sync.
For example, a remote interior designer can configure the lights at your home using VR. As you see changes in the physical world, you can also make modifications with an AR interface. And your suggestions are immediately visible to the designer in VR.
A bare bones example to do just that is in GitHub. Hue (watch video) controls a color smart bulb using three interfaces VR, AR, and html, keeping all of them in sync, and in sync with reality.
How are these experiences implemented with Caf.js?
Reverse Service Worker
A service worker is a custom script that mediates network access, and caches data, for a Progressive Web App (PWA). When the app is offline, it pretends that the network is still functional by fetching data from the local cache, or delaying sends.
A Reverse Service Worker (RSW) lives in the Cloud, and has a dual role to a service worker in the browser. It mediates requests from the Internet to an endpoint, such as an IoT device, or an app instance.
An RSW is implemented with a Cloud Assistant, following the Actor Model, and thousands of them can run on one Node.js process. An RSW has
- an stable URL that provides a public name for the endpoint,
- some private state,
- a set of methods that can be called remotely,
- and a managed security policy that restricts who can call them.
RSWs have two modes of operation:
Pass-through, when the endpoint is connected with a web socket. In this mode, when it receives a request, it performs security checks, updates local state, and notifies the endpoint and other clients connected with web sockets. Notifications can then trigger actions in the physical world, or keep other user interfaces in sync.
Impersonation, when the endpoint is not connected. In this mode it pretends to be the endpoint, making decisions on its behalf based on local state, and helping the rest of the world to move forward.
An RSW transparently switches between modes. For example, it could start in impersonation mode, negotiate some actions, and then relay these actions in pass-through mode, when the endpoint eventually connects.
Clients never have direct access to endpoints. They use short-lived signed credentials for authentication. Access policy is centrally managed, and consistent for all your devices. More importantly, only the minimal functionality required by your app is exposed, keeping the endpoint safe.
Three-way Isomorphic
Most applications in Caf.js are made of three JavaScript programs: front-end, cloud, and device bridging code.
Why bridging code? It is impractical to modify the firmware of an IoT device, or patch an existing application. Instead, write JavaScript code that interfaces with the real endpoint over Bluetooth, or other local protocol.
In Caf.js these three programs are developed, debugged, and deployed as a single unit. They also share many software components. In fact, using our tools, you can emulate all of them in a laptop. And then, trace a request through the system without leaving the Chrome web developer tools.
But that's not all. Caf.js is a three-way isomorphic framework. The device bridging code runs in a Raspberry Pi, but it can also run in a browser, or in the Cloud.
And that opens many doors. You don't need to carry a Raspberry Pi, or a laptop. Your phone, with a browser that supports the Web Bluetooth API, such as Chrome for Android, can also bridge Bluetooth devices.
Some applications will still require a dedicated bridging device, but many will benefit from the convenience of the phone. And for Android phones it is even better, the default browser is all you need!
What is the benefit of running bridging code in the Cloud?
- Simplifies endpoint impersonation,
- enables realistic load testing by emulating thousands of devices,
- and dynamically creates interfaces with bridging code introspection.
Read our technical documentation to learn more.