Einbetten oder auswerfen
„Bring mein Dashboard in meine eigene App" hat hier zwei Antworten, und das sind wirklich zwei verschiedene Produkte und nicht zwei Einstellungen eines einzigen.
- Einbetten — wir rendern das Dashboard; Sie setzen es in ein
<iframe>. Sie schreiben keinen Dashboard-Code und besitzen keinen Build. Ein Dashboard einbetten. - Auswerfen — wir übergeben Ihnen den React- und SQL-Quellcode; Sie rendern ihn. Wir verlassen den Render-Pfad vollständig und behalten nur die Daten-Engine darunter. Ihr Dashboard auswerfen.
Beide lassen die Plattformhälfte — Verbindungen, Datensätze, Aktualisierungen, Zeitpläne, die Query-Engine, Governance — auf unserer Seite betreut. Die Frage ist nur, wer die Pixel zeichnet.
Die kurze Antwort
Einbetten, wenn Sie Filterung pro Betrachter auf Zeilenebene brauchen, oder wenn Veröffentlichen das gesamte Deployment sein soll. Auswerfen, wenn das Dashboard aussehen und sich verhalten muss wie der Rest Ihrer App, oder wenn es dort laufen muss, wo wir nicht hinkommen.
Nebeneinander
| Einbetten | Auswerfen | |
|---|---|---|
| Wer rendert | wir | Sie |
| Was Sie integrieren | eine URL (plus ein kurzlebiges Token auf der geschützten Spur) | einen Quellbaum, den Sie bauen und hosten |
| Wer eine Änderung ausliefert | niemand — neu veröffentlichen, und der Frame liefert sie aus | Sie, mit Ihrem eigenen Build und Release |
| Filterung pro Betrachter auf Zeilenebene | ja, serverseitig aus einem signierten Token durchgesetzt — nur hier gibt es sie | nicht auf der Spur ohne Zugangsdaten; braucht Ihren eigenen Server im Pfad |
| Kontrolle über Optik und Interaktion | unser Renderer, unser Rahmen | vollständig — es sind Ihre Komponenten |
| Filterzustand mit Ihrer eigenen UI geteilt | nein, in keiner Richtung | ja, es ist Ihr Zustand |
| Routing, Auth, Layout-Integration | die Iframe-Grenze | nativ in Ihrer App |
| Zugangsdaten, die Sie halten müssen | keine auf der öffentlichen Spur; ein API-Schlüssel in Ihrem Backend für die geschützte Spur | keine auf der Spur ohne Zugangsdaten; ein API-Schlüssel auf Ihrem Server für die Backend-Spur |
| Braucht ein eigenes Backend | nur für die geschützte Spur, um Tokens auszustellen | nur wenn Sie Zeilenbeschränkung oder lebende Abfragen wollen |
| Datenaktualität | lebende Abfragen pro Aufruf | lebend auf der Backend-Spur; der veröffentlichte Snapshot auf der Spur ohne Zugangsdaten |
Einbetten wählen, wenn
- Verschiedene Betrachter verschiedene Zeilen sehen müssen. Das ist das entscheidende Kriterium. Zeilenbasierte Filterung lebt in der Embed-Spur mit signiertem Token und nirgends sonst: Ihr Backend stellt ein kurzlebiges Token aus, das die Filter trägt, die Plattform schreibt jede Datensatzreferenz in eine gefilterte Relation um, und die Seite kann das nur weiter einengen. Nichts, was Sie auf einem ausgeworfenen Baum bauen, reproduziert das, ohne Ihren eigenen Server vor jede Abfrage zu stellen.
- Veröffentlichen soll das Deployment sein. Eine Neuveröffentlichung ändert, was jedes Embed ausliefert. Kein Release auf Ihrer Seite, keine im Bundle festgenagelte Version des Dashboards.
- Sie wollen keinen Dashboard-Code besitzen. Kein Build, keine Abhängigkeits-Updates, kein Hin und Her der Diagrammbibliotheken.
- Das Dashboard ist ein Ausschnitt, nicht das Produkt. Ein Reporting-Tab, ein Auszug für Kunden, eine Admin-Ansicht.
Auswerfen wählen, wenn
- Es muss wie Ihre App aussehen. Ihr Design-System, Ihre Typografie, Ihre leeren Zustände, Ihre Lade-Skelette. Ein Iframe ist ein Rechteck mit dem Rahmen eines anderen darin.
- Es muss mit Ihrer App interagieren. Ihre Filter steuern seine Diagramme, seine Auswahlen steuern Ihre Seite. Die Embed-Spur gibt den Filterzustand in keiner Richtung weiter, also ist Cross-Filtering zwischen einem Dashboard und Ihrer eigenen UI dort nicht verfügbar.
- Sie brauchen Ihr eigenes Routing, Auth oder Layout. Deeplinks in ein Kachelelement, Ihre Session, Ihre Shell, Ihre Breadcrumbs.
- Es muss dort laufen, wo wir nicht sind. Ihr eigenes Hosting, Ihre eigene VPC, ein CDN, das
Sie kontrollieren. Der Quellcode ist reines React und SQL und baut mit
npm install && npm run dev. Beachten Sie: Auswerfen verlegt das Rendering in Ihre Infrastruktur, nicht die Daten — ein ausgeworfenes Dashboard erreicht weiterhin über das Netz die Query-Engine dieses Kontos oder dessen Parquet-Auszug. Wenn die Anforderung ist, dass überhaupt keine Daten Ihre Umgebung verlassen, dann ist das Vibedasher Server und nicht Eject. - Sie wollen überhaupt keine Zugangsdaten und kein Backend. Ein öffentliches, veröffentlichtes Dashboard wird auf eine Spur ausgeworfen, die einen Parquet-Auszug herunterlädt und jede Abfrage im Browser des Besuchers ausführt — kein Schlüssel, kein Token, nichts von Ihnen zu betreiben oder zu bezahlen. Was das kostet, steht in der Wasm-Abfragespur.
Drei Unterschiede, die sich schwer zurücknehmen lassen
Bei allem oben können Sie es sich günstig anders überlegen. Diese drei sollten Sie entscheiden, bevor Sie bauen.
Zeilenbeschränkung ist eine Architekturentscheidung, kein Schalter
Wenn Sie ein ausgeworfenes Dashboard auf der Spur ohne Zugangsdaten ausliefern und später Betrachter A weniger Zeilen sehen soll als Betrachter B, gibt es keine Einstellung zum Aktivieren. Der Auszug im Browser ist der ganze Datensatz, also hat jeder Besucher schon jede Zeile. Die Beschränkung zurückzubekommen heißt, einen Server von Ihnen zwischen Betrachter und Daten zu stellen und die Abfragespur des Dashboards gegen ihn neu zu schreiben — oder auf die Embed-Spur zu wechseln, was eine andere Integration ist. Siehe wer sieht was.
Sobald Sie einen ausgeworfenen Baum bearbeiten, ist die App nicht mehr die Quelle der Wahrheit
Eject ist ein echter Fork, und genau das ist der Sinn. Sie können einen bearbeiteten Baum zurück in den Entwurfszweig schieben und weiter im Kreislauf arbeiten; wenn Sie den Quellcode aber in Ihr eigenes Repository nehmen und ihn dort zu ändern beginnen, fließen spätere Änderungen aus der App nicht in Ihre Kopie und Ihre nicht zurück. Entscheiden Sie, welcher Seite der Code gehört.
Sichtbarkeitsentscheidungen auf der Embed-Spur sind nicht symmetrisch
Die geschützte Spur verlangt, dass die Sichtbarkeit des Dashboards protected ist, und lehnt
ein public-Dashboard glatt ab — damit Sie nicht glauben können, Zeilenfilter zu haben, wenn
Sie keine haben. Ein private-Dashboard ist über keine der beiden Spuren einbettbar. Und ein
Dashboard für die ganze Welt lesbar zu machen, ist der einzige unumkehrbare Schritt im
Veröffentlichungsablauf; siehe veröffentlichen und teilen.
Sie können beides tun
Sie schließen sich nicht aus, und eine häufige Form nutzt jede für das, worin sie gut ist: die kundenseitige Ansicht einbetten, wo Zeilenfilterung die ganze Anforderung ist, und die interne Ansicht auswerfen, die in Ihrer eigenen Admin-Shell sitzen muss. Dieselben Datensätze, dieselben Aktualisierungen, dieselbe Governance darunter.
Weiter
- Ein Dashboard einbetten — beide Embed-Spuren, die Token-Aktualisierungsschleife, die Nachrichten, die Ihre Seite tatsächlich empfängt, und wo die Grenze des Rahmens liegt.
- Ihr Dashboard auswerfen — die drei Aufrufe, der Paging-Vertrag, und wie Sie die Daten wieder anbinden.