Architecting a product for the Internet of Things (IoT) is fundamentally different from architecting for web or mobile.

At Tempest House, we’ve built dozens of high-quality, scalable apps, both IoT and otherwise. From this vast experience, we’ve distilled 7 tips for architecting an IoT product (and an example architecture at the end):

1. Expect large amounts of data

IoT products create a huge amount of data. There are many ways to structure your data, and the best design will necessarily vary on a case-by-case basis. Our process for choosing a design, however, is relatively consistent:

First, we ask:

• What is required of the data?
• What needs to be passed to the server?

Then, we work closely with the firmware architect, asking questions like:

• How should they structure their data?
• How much speed do we need? (If the ideal format is too large for the pipe, for instance, we’ll need an abbreviated way to pass that data.)

Finally, we write transformers that turn the data into what we need to pass to the server.

Once someone understands their needs, they can design a structure that will withstand even the needs of large quantities of data. In designing this structure, the most important part is having clear communication between the data transit architect, web architect, and a competent firmware team.

2. High-quality firmware is worth every penny

While high-quality firmware will dramatically increase a device’s functionality and reliability, low-quality firmware prompts all sorts of headaches.

What does high-quality firmware look like?

• Everything is read/write capable.
• Notifications are written clearly, effectively, and efficiently.
• All security verifications are handled appropriately by both the mobile application and the device.
• Applications have full insight into the device (which can be especially important for resolving issues and errors).

How can you recognize low-quality firmware?

• Device abilities are locked away.

The structure is disorganized (typically due to poor planning).

• The API is illogical.

3. Communication is key

Since connectivity is fundamental to an IoT product, communication from IoT devices is of the utmost importance. For that reason, we built a messaging queue into our standard toolkit that keeps sending messages until the message is received. This queue, built using Redux, also allows us to flag priorities to dynamically reorder the queue on demand and set contingencies for failed requests. Since communication is so important, it’s key to ensure each message arrives at its desired destination.

4. Recognize IoT’s unique security threats

Due to their increased connectivity and increased points of vulnerability, IoT devices have unique, heightened dangers. To combat these vulnerabilities, adhering to industry-standard security practices will take you far. These three practices are especially important:

1. Encrypt your data, both in the back-end and when passing it.

There are best practices for data encryption…but most people don’t use them. When used properly, however, it’s nearly impossible for a hacker to decrypt your data without full access to your systems.

2. Use tokens for authentication.

At Tempest House, we store encrypted tokens that ensure our front-end is properly authenticated with our back-end. Personally, I like the Ionic Identity Vault because it prevents hackers from retrieving tokens from our mobile devices. While this sort of security measure costs a little extra, it can be invaluable in avoiding breaches.

3. Partner with a company to test your security.

At the end of the day, our security experts can’t offer every service that we recommend to our clients on their own. We build secure software for our clients, but we also recommend that one of our partner companies, EdgeScan, provide manual and automated penetration testing. They check all of our endpoints and probe further when they find problems. As an added benefit, they offer a security certification when a device/service passes their tests.

5. Consider compliance… or expect costly consequences.

While compliance is not exclusively an IoT-related topic, the added communication between devices does make it more complicated.

GDPR is currently the most-complicated compliance issue. Anytime we architect something, we walk through a personal checklist of GDPR requirements. It’s a long, multi-page document, but undoubtedly worth the time. If anyone from the European Union uses your application and you’re not following GDPR, you can be liable for up to 4% of your company’s global revenue.

6. Build for scalability.

A scalable product is key to a company’s success. This is even more important for IoT devices, as much of their value comes from being networked.

For a scalable back end, we use often Tempest Tools, which we developed in-house. It has lots of built-in features and can build back-ends quickly.

For some high-load projects, we like to combine Tempest Tools with already-scaled back-ends like Express or Lumen. We determine which requests provide large amounts of load and use a microservice architecture with thin endpoints to balance the load.

Beyond the above options, we also have developers that can create backends in all the popular coding languages and frameworks. We are well-aware of the pros and cons of using each one, so we will always recommend the best toolset for the job.

7. Consider a hybrid approach for apps

When building apps, we prefer a hybrid approach (i.e. a virtual browser that runs JavaScript inside an app). This approach allows for easy and inexpensive development, as JavaScript developers are plentiful. It also makes each developer’s work portable, as the same code can work on Android, iOS, and web, with very few changes.

This hybrid approach does have its downsides. Some activities—especially processor-intensive ones—run too slowly inside a virtual browser. For these processor-intensive cases, we employ plug-in architects to write native code. It’s a trick that most companies aren’t familiar with, but which allows us to optimize battery and CPU usage.

An example architecture

Here’s how Tempest House typically architects an IoT product using a hybrid application:

A.) We run a virtual browser inside a mobile application that uses Bluetooth Low Energy to connect back and forth with the IoT device, using a plugin that runs natively on the mobile device.

B.) After the device communicates with our server, our load balancer finds the proper node to process it.

C.) The node communicates a response through HTTP or real-time messaging. (We like to use Pubnub because it’s easy to set up, saves time, and works reliably with a low development cost).

D.) That back-end node also communicates with the cache and database (either SQL or NoSQL).

E.) Additionally, if we need to send push notifications to a mobile device, we send those through an Apple/Android messaging service.

Going forward

While these tips and example are what we could easily share here, it’s far from everything we know. Building an IoT product is a complicated endeavor.

‍

‍

‍

‍

‍