Sviluppare app companion white-label per prodotti connessi
Gli utenti finali si aspettano che il loro dispositivo connesso sia accompagnato da un'app curata e con il brand del produttore. Non una dashboard IoT generica, ma un'esperienza costruita su misura che riflette l'identità del prodotto e offre i controlli che contano per il loro caso d'uso specifico.
Costruire il backend per l'app di un prodotto connesso è un compito oneroso e indifferenziato, che nulla ha a che fare con ciò che rende unico il tuo prodotto.
Autenticazione utente, associazione del dispositivo, feed di dati in tempo reale, push notification, gestione dei permessi: gli stessi requisiti compaiono sia che tu stia sviluppando un'app per termostati, un'app per piscine o un'app di monitoraggio industriale.
La sfida
La parte visibile di un'app companion, l'interfaccia, è solo una frazione del lavoro. Per ogni funzionalità che l'utente vede, c'è un requisito backend:
- Account utente e autenticazione: registrazione, login, reset password, OAuth, autenticazione multi-fattore. Ogni piattaforma (iOS, Android, web) richiede lo stesso comportamento backend.
- Device ownership: un utente deve reclamare la proprietà del proprio dispositivo dopo l'acquisto, e quell'associazione di proprietà deve essere applicata a livello API, non solo nell'interfaccia.
- Architettura multi-app: un produttore con più linee di prodotto ha bisogno di app separate con brand dedicato, ma mantenere backend separati per ognuna è costoso. Un backend condiviso con isolamento dei dati per app è il modello corretto, e costruire quell'isolamento in modo affidabile non è banale.
- Dati in tempo reale: le app di automazione domestica e monitoraggio richiedono feed a bassa latenza; il polling non è sufficiente per una buona esperienza utente.
- Push notification: consegna su iOS e Android, con preferenze per utente e tracciamento della consegna.
- Controllo degli accessi: un installatore deve vedere dati diversi da quelli di un utente finale; un rivenditore deve vedere dati diversi da quelli del team interno del produttore.
- White-labeling: ogni app ha il proprio brand, set di funzionalità e dominio, ma girano tutte sulla stessa infrastruttura backend.
Cosa serve per farlo bene
Un backend progettato per app IoT companion white-label ha bisogno di:
- Design API-first: un'API REST e WebSocket ben documentata su cui qualsiasi team frontend possa costruire, indipendentemente dal framework o dalla piattaforma.
- Isolamento multi-app: più app condividono la stessa infrastruttura ma vedono solo i propri dati; la contaminazione incrociata è impossibile a livello di modello dati.
- Modello di device ownership: un concetto formale di quale utente o organizzazione "possiede" quale dispositivo, applicato a livello API, con semantica di trasferimento e condivisione configurabile.
- Eventi in tempo reale: subscription WebSocket o MQTT alla telemetria del dispositivo, in modo che l'interfaccia dell'app si aggiorni senza polling.
- Consegna notifiche white-label: push notification inviate con l'identità del mittente della tua app, non di una piattaforma IoT generica.
Come Connhex risolve il problema
Connhex è stato progettato intorno a un'architettura app-centrica: il principale output è un insieme di API e strumenti per costruire applicazioni su misura, non una dashboard di gestione dispositivi.
Connhex Cloud fornisce il layer API REST e WebSocket. Ogni funzionalità (ingestione della telemetria, controllo dei dispositivi, gestione utenti, subscription) è esposta come API che il tuo team frontend chiama per costruire interfacce branded completamente personalizzate.
Connhex Auth gestisce l'identità utente: registrazione, login, flussi OAuth, gestione delle sessioni e autenticazione multi-fattore, su tutte le app che girano sullo stesso backend.
Device Ownership è un concetto di prima classe in Connhex: un dispositivo può essere reclamato da un utente, trasferito e condiviso con permessi definiti. È il modello che permette all'app di un utente finale di vedere solo i propri dispositivi, mentre la dashboard di un installatore mostra tutti i dispositivi che gestisce.
Connhex Resources fornisce un key-value store flessibile, con scope per app, per dati applicativi specifici del prodotto, accessibile via API. Invece di gestire un backend separato per la logica di dominio, Resources agisce come layer dati integrato: un'app di monitoraggio piscine memorizza qui la configurazione degli impianti; un'app HVAC memorizza i parametri di installazione per ogni termostato. Il modello dati è completamente personalizzabile.
Connhex Notifications consegna push notification native su iOS e Android, oltre a messaggi in-app, inviati con l'identità mittente della tua app. Le preferenze di consegna per utente e le ricevute di consegna sono integrate.
Più linee di prodotto e brand girano su un'unica istanza Connhex: ogni app ha il proprio namespace, brand e configurazione delle funzionalità. Non è necessario gestire deployment backend separati per ogni prodotto.
Vedi come funziona in pratica
Ho scoperto Connhex dopo un'accurata fase di ricerca tecnologica. Si è dimostrata di gran lunga la migliore soluzione per le nostre esigenze: non c'è paragone con le altre soluzioni.
CTO - Astrel Group
Astrel Group gestisce quattro applicazioni branded separate (Energy, Home, Wellness e Fire) su un unico backend Connhex condiviso. Ogni app ha il proprio modello dati, regole di accesso ed esperienza utente, senza alcuna contaminazione tra le business unit. Quattro app di prodotto connesso distinte, un unico team backend, senza costruire quattro backend IoT separati.
Un'app companion per termostati costruita con Connhex. La stessa interfaccia è disponibile sia in tema scuro che chiaro, configurata tramite il sistema di temi integrato.
I prodotti connessi app-centrici sono centrali in diversi settori: Connhex per la smart home · Connhex per HVAC · Connhex per piscine e SPA