Zero Sheets: Google Spreadsheets als App-Backend/API nutzen

 (zerosheets.com)
3 Punkte von GN⁺ 2024-04-13 | 1 Kommentare | Auf WhatsApp teilen
  • Zero Sheets ist ein Dienst, der Google Sheets in eine RESTful-JSON-API umwandelt, damit sich Daten in Prototypen, Websites und Apps ohne separates Backend verarbeiten lassen
  • An die erzeugten Endpunkte können HTTP-Anfragen gesendet werden, um Daten abzurufen und zu bearbeiten; auch Authentifizierung und die zu verwendenden Sheets lassen sich konfigurieren
  • Der Einstieg besteht aus drei Schritten: Sheet-URL einfügen, API konfigurieren, Anfragen an den Endpunkt senden — das senkt den Aufwand für die erste Anbindung
  • Der Fokus liegt darauf, Spreadsheets wie ein clientseitiges CMS zu nutzen, um Ideen mit echten Daten zu testen
  • Die Tarife reichen von kostenlos mit 1 API und 200 Anfragen pro Monat bis zu Scout für 4,99 $/Monat und Craft für 19,99 $/Monat; die öffentlichen Tarife umfassen Lesen, Schreiben, Aktualisieren und Löschen

Google Sheets in eine RESTful API umwandeln

  • Google Sheets-Spreadsheets werden in eine RESTful API umgewandelt, sodass sich Daten mit einfachen HTTP-Anfragen abrufen und bearbeiten lassen
  • Das Tool richtet sich an Entwickler, die schnell Prototypen, Websites und Apps erstellen wollen
  • Bei der API-Konfiguration können Authentifizierungsmethode, zu verwendende Sheets und weitere Einstellungen festgelegt werden
  • Der Ablauf ist in drei Schritte gegliedert
    • Die URL des Google Spreadsheet wird ins Dashboard kopiert und dort eingefügt
    • Die Authentifizierungsmethode der neuen API, die zu verwendenden Sheets und weitere Optionen werden festgelegt
    • Nach Erhalt des Endpunkts werden HTTP-Anfragen gesendet

Nutzung wie ein CMS und Preismodelle

  • Das Spreadsheet kann wie ein echter Datenspeicher genutzt werden, um Ideen zu testen, und zugleich die Rolle eines CMS für Kunden übernehmen
  • Hervorgehoben wird, dass sich Ideen günstiger und schneller umsetzen lassen als mit einem eigenen Backend-Panel
  • Die öffentlichen Tarife sind wie folgt
    • Free: 0 $/Monat, 1 API, unbegrenzte Sheet-Tabs, Lesen, Schreiben, Aktualisieren, Löschen, 200 Anfragen/Monat
    • Scout: 4,99 $/Monat, unbegrenzte APIs, unbegrenzte Sheet-Tabs, Lesen, Schreiben, Aktualisieren, Löschen, 400 Anfragen/Monat, 24/7-Support
    • Craft: 19,99 $/Monat, unbegrenzte APIs, unbegrenzte Sheet-Tabs, Lesen, Schreiben, Aktualisieren, Löschen, 2000 Anfragen/Monat, 24/7-Support
  • Maßgeschneiderte Tarife sind auf Anfrage verfügbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-13
Meinungen auf Hacker News

  • Man sollte sich vor der modernen Excel-Anfängerfalle in Acht nehmen. In den 80er- und 90er-Jahren sind viele Investmentbanken hineingeraten: Tabellenkalkulationen sind als universelles Rechen-Framework hervorragend, sodass Risikomanagement, Pricing und operative Funktionen auf riesigen Stapeln von Excel-Dateien aufgebaut wurden.
    Mit Plugins und Erweiterungen lässt sich wirklich sehr viel machen, aber am Ende werden Tabellenkalkulationen zu einem Albtraum, der nicht wartbar und intern schwer nachvollziehbar ist, während zentrale Geschäftslogik in den persönlichen Sheets verschiedener Leute eingeschlossen bleibt. Umfassende Änderungen werden schwierig oder unmöglich, und selbst Änderungen, die in einem normalen Software-Framework einfach wären, erfordern das Anpassen unzähliger Sheets, was Risiko und Prüfaufwand erhöht.

    • Bei Visual Scripting in der Spieleentwicklung entsteht eine sehr ähnliche Situation. Eigentlich sind solche Werkzeuge dafür gedacht, Designer oder Artists kleine Aufgaben erledigen zu lassen, etwa dass sich eine Tür öffnet, wenn man auf eine Druckplatte tritt, ohne einen Programmierer rufen zu müssen. Aber das Ergebnis gerät leicht außer Kontrolle.
      Es gibt sogar eine Website nur mit Beispielen aus der Unreal Engine: https://blueprintsfromhell.tumblr.com/. Persönlich sehe ich gute Refactoring-Unterstützung als Lösung. Man sollte Dinge mit Methoden wie „Methode extrahieren“ aufräumen können, ohne dass ein Programmierer alles neu schreiben muss.
    • Es ist nicht immer eine Frage der Wahl. An meinem Arbeitsplatz dauerte es mit allen möglichen Prozessen etwa 4 Stunden, nur um eine Umgebung zu bekommen, in der ich ein richtlinienkonformes Python-hello world ausführen konnte.
      Es ging nicht um eine vollständige IDE oder pip-Module, sondern einfach nur um hello world, und das war im Vergleich noch eher gut. Manche Finanzunternehmen bieten von vornherein keine andere Option. Ein verbreitetes Muster ist, Büroangestellten nur Excel zu geben und sich dann zu wundern, dass sie damit Monster bauen.
    • Stimme völlig zu. Mein aktuelles Unternehmen hat seit über 10 Jahren das verschlungene Geflecht aus Tabellenkalkulationen und Pipelines zum Export von Datenbankabfragen nicht refaktoriert, und weil es nicht skaliert, verlieren wir jetzt laufend Geld.
      Solche Probleme werden erst sichtbar, wenn alles zusammenbricht. Gleichzeitiges Arbeiten in Tabellenkalkulationen gehört zu den riskantesten Dingen überhaupt, daher entstehen in allen Kernprozessen Engpässe. Datenintegration ist riskant und dauert lange, und Konsistenz zwischen Tabellenkalkulationen ist schwer sicherzustellen. Man flickt weiter mit Code herum, der nicht nötig gewesen wäre, wenn man früher auf passende Werkzeuge umgestiegen wäre.
    • Zusätzlich zu „umfassende Änderungen werden schwierig oder unmöglich“ gibt es keine Versionsverwaltung.
      Man kann Tabellenkalkulationen zwar in RCS speichern, aber kann man ein Diff sehen, um zu prüfen, ob die Änderung, die man pushen will, wirklich beabsichtigt ist? Kann man die Diff-Historie durchsehen, um zu verstehen, wie sich das System im Lauf der Zeit verändert hat? Kann man Änderungen mehrerer Personen mergen? Gibt es überhaupt eine separate Arbeitskopie für Experimente, oder bearbeitet man ohne Sicherheitsnetz direkt die Produktionskopie?
    • Sheets nur als Speicher zu verwenden, könnte vielleicht in Ordnung sein. Ich frage mich allerdings, wo die Größenlimits liegen.

  • Interessante Geschichte. Bevor das Startup zu Loom pivotierte, war es ein User-Testing-Unternehmen namens Opentest. Statt eine Datenbank und ein Dashboard zu bauen, damit die Mitgründer bestimmte Anfragende für User-Tests sehen konnten, packten sie einfach alles in Google Sheets.
    Das war großartig. Es gab keine Downtime, der Zugriff war offen, und weil es nur 3 Betrachtende und Bearbeitende gab, gab es auch keine Konflikte. Man musste sich auch nicht um Datenbank-Upgrades oder Wartung kümmern. Ich denke oft an diese Entscheidung zurück und habe das Gefühl, dass vieles von dem, was ich als „gute Engineering-Praktiken“ gelernt habe, verblasst gegenüber der Tatsache, dass wirklich schnelles und pragmatisches Vorgehen in jeder Phase ein genialer Durchbruch sein kann.

    • Stimme zu. Google Sheets ist für Startups oder kleine Unternehmen eine gute Option, um schnell über die Runden zu kommen.
      Ich habe es für Daten mehrerer Systeme genutzt, die nur von sehr wenigen Personen geändert werden mussten. Mit etwas sorgfältigem Code und Caching kann man es leicht als CRUD-Frontend für wichtige Systemdaten verwenden, etwa indem man nach der Validierung nach S3 synchronisiert. Es eignet sich auch gut für Ad-hoc-Dashboards, und wenn man es an APIs anschließt oder eigenen Google-Scripts-Code hinzufügt, kann man sogar private APIs bedienen. Ich habe auch schon recht umfangreiche Reports mit mehreren Ansichten, Pivot-Tabellen, Abfragen und Lookups automatisch nach Zeitplan aktualisieren lassen. Eine Eigenentwicklung muss schon deutlich besser sein als Google Sheets, aber schneller bauen lässt sie sich nicht. Bis man etwas Größeres und Besseres braucht, sind die Anforderungen klarer und man kann sich die Entwicklungsressourcen leisten.
    • Ich bin Software Engineer in einem Großunternehmen, aber mehrere Projekte, an denen ich arbeite, basieren auf Google Sheets. An manchen Stellen nutzen wir es als Frontend, an anderen als Backend.
      Das liegt auch daran, dass selbst für einfache Engineering-Tools wie React oder Postgres viel zu viele Prozesse nötig sind.
    • Google Sheets kann man auch als verwaltete NoSQL-Datenbank mit eingebauter Admin-UI betrachten.
    • Wenn nur ein unidirektionaler Datendump nötig ist, klingt das nach einer guten Idee. Die Probleme beginnen, wenn sieben Sheets andere Prozesse authoritative steuern müssen.
      Wer in die Tabellenkalkulation schreibt, kann faktisch jede beliebige Veränderung vornehmen, daher geht sie sehr leicht kaputt.
    • Klingt okay, aber bevor man Unternehmensdaten in Google Sheets legt, sollte man zuerst eine Genehmigung einholen.

  • Man braucht nicht unbedingt ein schickes Wrapping. Wenn man einfach https://script.google.com/ öffnet, hat man bereits Zugriff auf mehrere Google-APIs und kann Sheets mit Gmail zum Versenden von E-Mails, Kalenderänderungen, Seitenerstellung, Formularverarbeitung usw. integrieren.
    Das Problem ist, dass es keine transaktionsbasierten Operationen wie in einer echten Datenbank gibt. Wenn man zum Beispiel eine bestimmte Ressource sperren möchte, kann das fehlschlagen.

    • Auf dieser Seite sagt jedes Mal, wenn jemand eine einfache Lösung für ein Problem baut, jemand anderes, dass es bereits eine viel komplexere Option gibt.

  • Es überrascht mich, dass noch niemand Spread API genannt hat: https://spreadapi.roombelt.com/
    Es ist kostenlos mit Google Sheets / Apps Script und macht daraus vollständiges CRUD, indem man es einfach in ein Sheet einfügt. Es gibt allerdings gewisse Rate Limits, aber es ist komplett kostenlos. Ich habe früher einmal über ein auf Sheets basierendes Unternehmen nachgedacht, aber sobald man an den Punkt kommt, an dem Leute „bereit sind zu zahlen“, ist das meist auch der Zeitpunkt, an dem man über Sheets hinausgewachsen ist. Wegen der Einschränkungen will man dann eher zu Turso, Cloudflare D1 oder PocketBase wechseln, statt bei Sheets oder SpreadAPI zu bleiben.

    • Es freut mich wirklich, dass mein kleines Projekt nützlich ist.
      Verbesserungsideen oder PRs sind jederzeit hier willkommen: https://github.com/ziolko/spreadapi
    • Sieht gut aus. Allerdings scheint man nicht einmal mehrere Zeilen in einer Anfrage einfügen zu können, daher wirkt es ziemlich eingeschränkt.
    • Ich frage mich, wie die Rate Limits von Spread API aussehen. Auf der Website konnte ich keine Informationen dazu finden.

  • Für einen ähnlichen Einsatzzweck würde ich PocketBase empfehlen.
    Letzte Woche habe ich nach einem beliebigen Datenspeicher mit API-Zugriff gesucht und überlegt, ein Google-Sheets-Backend zu bauen, aber PocketBase war einfach und hatte auch kein Limit von 60 Anfragen pro Minute. Die Bereitstellung per CapRover auf einem günstigen VPS war ebenfalls sehr einfach.
    https://pocketbase.io/
    https://developers.google.com/sheets/api/limits

    • Eine Stimme für PocketBase. Für die normale Datenerfassung nutze ich PocketBase und exportiere per API CSV nach Google Sheet, um die Daten dort anzusehen und zu bearbeiten.
      Es ist sehr einfach für Prototyping und echte Arbeitsabläufe; Google Sheet als Backend zu nutzen ist auch gut, aber Dinge wie Authentifizierung waren nötig.
    • Ich habe mir PocketBase angesehen, aber nicht wirklich verstanden, wie ich es verwenden soll. Ich kenne SQLite und kann gut SQL, aber ich hatte kein Gefühl dafür, wie man es konkret einsetzen sollte.
    • Meine Infrastruktur ist zu 100 % auf Skalierbarkeit ausgerichtet, daher könnten wir vermutlich zusammenarbeiten. Wir müssten nur die Kosten teilen.
      Schreib mir gern hier, damit ich deine Kontaktdaten bekomme: https://www.zerosheets.com/contact

  • Ich habe kürzlich eine vollständige Web-App gebaut, die nur Apps Script und Google Sheets als Datenbank nutzt, darüber hier geschrieben: https://thetechenabler.substack.com/i/142898781/making-a-sim... und sie hier veröffentlicht: https://github.com/eeue56/simple-link-aggregator
    Es war eine neue Erfahrung, und besonders reizvoll fand ich die Idee, einen für Nichtentwickler leicht handhabbaren Datenspeicher zu haben und davor eine Web-App zu setzen, die keine Servereinrichtung braucht. Aber Apps Script ist für diesen Zweck viel zu langsam, als dass daraus eine gute Erfahrung werden könnte. Zerosheets sieht gut aus, und wenn ich auf diese Idee zurückkomme, werde ich es mir näher ansehen.

    • Ist „eine Web-App an einen für Nichtentwickler leicht handhabbaren Datenspeicher hängen, ohne Servereinrichtung zu brauchen“ nicht einer der Use Cases von Airtable?

  • Für meine nächste Userscript-Projektidee brauche ich so etwas. Es ist für den privaten Gebrauch, aber ich muss Zeugnisse über eine extrem schmerzhafte Web-UI ausfüllen.
    Die Daten in eine Tabellenkalkulation einzugeben wäre viel einfacher. Früher habe ich das tatsächlich so gemacht, aber die Schule hat, um es „einfacher“ zu machen, etwas eingeführt, das wie eine schreckliche Parodie auf eine sehr grundlegende CRUD-Web-App wirkt. Deshalb möchte ich ein Userscript bauen, das aus einer Tabelle liest und damit ein umständliches Webformular ausfüllt. Ich habe noch nicht angefangen, weil ich meinen Blogpost über meine bisherigen Userscript-Erfahrungen noch nicht fertig habe und Angst vor dem Authentifizierungs-Albtraum habe. Im Userscript-Kontext könnte es einfacher oder schwieriger sein; weil es innerhalb der Webseite läuft, könnte man dort vielleicht einen normalen OAuth-Flow oder Ähnliches machen.

    • Hast du dir Apps Script schon angesehen?
    • Wenn du Google Sheets nutzt, wirst du wahrscheinlich einen normalen OAuth-Flow machen müssen. Alternativ könntest du Excel verwenden und es mit einem einfachen Makro automatisieren.
      Persönlich halte ich es für den einfachsten Weg, den komplizierten Teil des Skripts – die Authentifizierung – zu überspringen, Werte über die Zwischenablage zu kopieren und einzufügen und dann die Daten zu verarbeiten.

  • Vor ein paar Tagen habe ich mir Templates und CMS-Alternativen angesehen und dabei das interne Tool von NPR zum Veröffentlichen von Artikeln mit Daten, Charts und Visualisierungen gefunden: https://github.com/nprapps/dailygraphics-next
    Interessant fand ich, dass darin eine Methode enthalten ist, Google Sheets als CMS zu nutzen.

  • Unter https://github.com/kellpossible/avalanche-report/ habe ich etwas sehr Ähnliches gemacht. Wir sind mit Google Sheets gestartet, weil sich der Dateneingabe-Flow damit schnell iterieren ließ.
    In Kombination mit einem Server konnten wir auch die konfigurierten URL-Queries in die IMAGE-Funktion stecken und so maßgeschneiderte Charts und Diagramme erzeugen. Lesezugriffe werden in einer lokalen SQLite-Datenbank gecacht. Inzwischen migrieren wir weg von Google Sheets, weil die Einrichtung etwas umständlich ist und wir in unserem Use Case nicht vollständig verhindern können, dass Nutzer die falschen Felder bearbeiten. Trotzdem hat es sich bisher sehr gut gehalten, und als Ausgangspunkt würde ich es jedem sehr empfehlen.

  • Früher habe ich die Menüseite einer Restaurant-Website über ein Google Sheet betrieben. Es war perfekt.
    Wann immer sich im Restaurant etwas änderte, aktualisierten sie die Tabelle und es erschien sofort im Web; wenn sie etwas falsch angefasst hatten, konnten sie es einfach rückgängig machen.

    • Vor ein paar Wochen habe ich für ein Restaurant genau dasselbe eingerichtet. Es war simpel und kostenlos.
      Ich habe Apps Script so eingerichtet, dass es die Website bei Updates baut; dadurch löste jede Bearbeitung jederzeit einen Rebuild aus und die Seite wurde wieder als statische Website deployt.