Consumindo Dados de Outros Apps

Todo app IronFlock recebe um backend de dados privado e isolado: suas próprias tabelas, seus próprios fluxos ao vivo, seu próprio realm. O isolamento é o que torna os apps seguros de instalar — mas, sozinho, ele também transformaria cada app em um silo. Os dados que um app coletor reúne de uma máquina são valiosos muito além daquele único app: são a matéria-prima para dashboards, análises, modelos de machine learning e relatórios.

O acesso a dados entre apps transforma apps instalados em blocos de construção. Um app pode declarar que deseja ler os dados de outro app no mesmo projeto — seus fluxos de eventos ao vivo e seu histórico gravado. O usuário dono do projeto decide se permite, por app, com um interruptor que pode acionar a qualquer momento. A plataforma garante o resto: o acesso é estritamente somente leitura, restrito às tabelas que o app provedor realmente compartilha, e nunca cruza os limites do projeto.

O Que Isso Torna Possível

• Análises prontas em cima dos coletores. Instale um coletor de dados nas suas máquinas e depois instale um app de dashboard OEE que consome as medições do coletor — sem projeto de integração, sem exportação de dados, sem código de cola.
• Machine learning sem encanamento. Um app de manutenção preditiva pode treinar com meses de histórico de vibração e temperatura que outro app já coletou, e pontuar as leituras ao vivo à medida que elas chegam.
• Apps especializados em vez de monolitos. Separe coleta, transformação, visualização e relatórios em apps distintos, cada um fazendo uma coisa bem feita — e combine-os por projeto como peças de Lego.
• Um ecossistema, não silos. Publique um app cujo valor inteiro esteja no que ele faz com os dados de outros apps. A página do app na App Store mostra aos usuários quais dados um app compartilha e quais dados ele solicita.

Como Funciona

Três partes estão envolvidas, e cada uma mantém o controle do que é seu:

1. O app provedor (“App B”) define tabelas e transformações em seu data-template.yml, como todo app faz. Tudo é compartilhável por padrão; tabelas individuais podem ser marcadas como private.
2. O app consumidor (“App A”) declara no data-template.yml dele de quais apps deseja ler, e por quê.
3. O usuário instala os dois apps em um projeto e aprova o acesso — no momento da instalação, ou depois, com um interruptor por app nas configurações de apps do projeto. Sem aprovação, sem acesso: a declaração por si só não concede nada.

Os dados nunca saem do projeto. O desenvolvedor do app provedor continua sem acesso aos dados do usuário — a concessão é entre apps instalados dentro de um mesmo projeto, sob o controle do dono do projeto.

Um Banco de Dados de Projeto Padronizado, Muitos Backends Isolados

Por baixo dos panos, todo projeto IronFlock provisiona o mesmo banco de dados de séries temporais padronizado. Dentro dele, cada app instalado possui um espaço de backend privado e separado: suas tabelas vivem em seu próprio esquema de banco de dados, invisível para qualquer outro app, a menos que o usuário conceda acesso de leitura. Esse design de um banco de dados por projeto é o que faz todo o modelo funcionar:

• Reproduzível entre projetos. O backend de dados de um app é provisionado de forma idêntica em todo projeto em que ele é instalado — mesmas tabelas, mesmos tipos, mesmo comportamento de consulta, seja o projeto executado na nuvem gerenciada ou em um appliance on-premises. Desenvolva contra ele uma vez; ele se comporta igual em qualquer lugar.
• Um ponto central de coleta e inspeção. Os donos de projeto veem os dados de todos os seus apps em um só lugar — um único banco de dados para inspecionar, consultar e possuir, em vez de uma dispersão de armazenamentos por app.
• Isolamento por padrão, compartilhamento por concessão. O isolamento por esquema mantém o espaço de cada app privado. Uma concessão entre apps abre uma janela somente leitura para o esquema de outro app — dentro do mesmo banco de dados, de modo que nada é copiado, exportado ou sincronizado. Os dados têm um único lar; o que muda é o acesso.

Declarando a Dependência

O app consumidor anuncia os apps dos quais lê em seu .ironflock/data-template.yml:

consumes:
  - app: machine-monitor
    reason: "Calcula o OEE a partir dos fluxos de estado de máquina e de contadores do monitor"
 
data:
  tables:
    - tablename: oee_results
      columns:
        # ... your app's own tables, as usual

O campo app é o nome técnico do app provedor (exibido na página dele na App Store). O reason é exibido ao usuário no diálogo de consentimento — escreva-o para uma pessoa que está decidindo se confia no seu app.

Lendo os Dados

Em tempo de execução, o SDK se conecta ao backend de dados do app provedor e oferece a mesma API de leitura que você já usa para as suas próprias tabelas:

from ironflock import IronFlock
 
flock = IronFlock()
 
# Connect to the providing app's data backend (requires the user's grant)
monitor = await flock.connect_to_app("machine-monitor")
 
# Discover what it shares
print(monitor.tables)      # shared tables with their columns
print(monitor.transforms)  # shared transforms (views)
 
# Query history
rows = await monitor.get_history("machinestate", {"limit": 1000})
 
# Down-sampled series for charts and models
series = await monitor.get_series_history("measurements", {
    "metrics": ["temperature"],
    "method": "AVG",
    "timeRange": ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
})
 
# Subscribe to live rows as they are collected
async def on_row(row):
    print("live reading:", row)
 
await monitor.subscribe_to_table("measurements", on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Connect to the providing app's data backend (requires the user's grant)
const monitor = await flock.connectToApp("machine-monitor");
 
// Discover what it shares
console.log(monitor.tables);      // shared tables with their columns
console.log(monitor.transforms); // shared transforms (views)
 
// Query history
const rows = await monitor.getHistory("machinestate", { limit: 1000 });
 
// Down-sampled series for charts and models
const series = await monitor.getSeriesHistory("measurements", {
  metrics: ["temperature"],
  method: "AVG",
  timeRange: ["2026-07-01T00:00:00Z", "2026-07-04T00:00:00Z"],
});
 
// Subscribe to live rows as they are collected
await monitor.subscribeToTable("measurements", (row) => {
  console.log("live reading:", row);
});

Se o usuário não concedeu o acesso (ou o revogar mais tarde), connectToApp falha com um erro claro e tipado — seu app deve tratar a fonte de dados como opcional e degradar com elegância.

Consumindo Todos os Dados do Projeto (Curinga)

Alguns apps são bancadas de dados de uso geral — um runtime Node-RED, um notebook, uma ferramenta de relatórios — cujo valor inteiro está em deixar o usuário trabalhar com quaisquer dados que estejam no projeto. Um app assim não consegue nomear os provedores de antemão; ele não sabe quais coletores ou apps de análise o usuário vai instalar. Para esses, declare um curinga: acesso de leitura aos dados de todos os apps do projeto.

consumes:
  - app: "*"          # the quotes are REQUIRED — a bare * is a YAML alias
    reason: "Permite que você crie fluxos sobre os dados ao vivo e históricos de cada app deste projeto"

O curinga "*" concede acesso de leitura a todos os apps do projeto — incluindo os apps que o usuário instalar depois, sem novo consentimento. Todo o resto do modelo permanece inalterado: continua sendo somente leitura, as tabelas e transformações privadas continuam nunca sendo compartilhadas, e os apps de plataforma ficam fora do escopo. O usuário aprova o curinga com um único interruptor de tudo ou nada (em vez de uma lista por app), e pode revogá-lo a qualquer momento.

Como um app consumidor com curinga não conhece os nomes dos provedores de antemão, ele os descobre em tempo de execução:

from ironflock import IronFlock
 
flock = IronFlock()
 
# Discover every app whose data you may read (name + shared-table catalog)
providers = await flock.list_consumable_apps()
for p in providers:
    print(p["app"], p["stages"])   # e.g. "energy-monitor", {"prod": {"tables": [...]}}
 
# Open one by name (works because you hold the wildcard grant)
energy = await flock.connect_to_app("energy-monitor")
rows = await energy.get_history("meterdata", {"limit": 1000})
 
# ...or open them all at once
all_apps = await flock.connect_to_all_apps()
for app in all_apps:
    await app.subscribe_to_table(app.tables[0]["tablename"], on_row)

import { IronFlock } from "ironflock";
 
const flock = new IronFlock();
await flock.start();
 
// Discover every app whose data you may read (name + shared-table catalog)
const providers = await flock.listConsumableApps();
for (const p of providers) {
  console.log(p.app, p.stages);   // e.g. "energy-monitor", { prod: { tables: [...] } }
}
 
// Open one by name (works because you hold the wildcard grant)
const energy = await flock.connectToApp("energy-monitor");
const rows = await energy.getHistory("meterdata", { limit: 1000 });
 
// ...or open them all at once
const all = await flock.connectToAllApps();
for (const app of all) {
  await app.subscribeToTable(app.tables[0].tablename, onRow);
}

listConsumableApps() é a primitiva — uma única chamada, não abre nenhuma conexão, retorna o catálogo não privado de cada provedor para que você possa renderizar um seletor. connectToAllApps() é a conveniência que abre todos de uma vez. Apps recém-instalados aparecem automaticamente na próxima chamada a listConsumableApps(). Se o usuário não concedeu o curinga, ambos falham com um erro tipado NO_GRANT.

Somente Leitura por Construção

A concessão é garantida pela camada de mensagens da plataforma, não por convenção. Um app consumidor pode:

Compartilhando os Dados do Seu App — e Guardando Alguns

Se você constrói um app que coleta dados valiosos, compartilhá-los é o que torna seu app uma fundação sobre a qual outros constroem. Você não precisa compartilhar tudo: marque tabelas ou transformações internas como private e elas desaparecem completamente do catálogo compartilhado — não são listadas, não podem ser consultadas, não são transmitidas.

data:
  tables:
    - tablename: measurements        # shared (default)
      columns: [ ... ]
    - tablename: calibration_state   # internal — never visible to other apps
      private: true
      columns: [ ... ]
  transforms:
    - tablename: hourly_aggregates   # shared views work like shared tables
      sql: "SELECT ..."

O Usuário Permanece no Controle

• No momento da instalação, o usuário vê exatamente de quais apps instalados o novo app deseja ler, e por quê — e pode recusar qualquer um deles. Recusar nunca bloqueia a instalação; o app simplesmente não recebe os dados.
• Cada acesso concedido aparece como um interruptor nas configurações de apps do projeto, onde pode ser revogado (ou concedido depois, por exemplo, após a instalação do app provedor) a qualquer momento.
• As concessões são por projeto. Instalar o mesmo par de apps em outro projeto começa do zero.

Uma Composição Típica

O padrão que torna isso concreto — coleta, análise e visualização como apps separados e componíveis — é descrito de ponta a ponta em Extração de Dados de Fábrica: coletores de protocolo extraem os dados das máquinas, e dashboards OEE, modelos de manutenção preditiva ou análises de energia os consomem, cada um instalado e autorizado de forma independente.