Zero Sheets, utiliser Google Sheets comme backend d’application/API

 (zerosheets.com)
3 points par GN⁺ 2024-04-13 | 1 commentaires | Partager sur WhatsApp
  • Zero Sheets est un service qui transforme Google Sheets en API JSON RESTful, afin de permettre de gérer des données dans des prototypes, sites web et applications sans backend séparé
  • Il est possible d’interroger et de manipuler les données en envoyant des requêtes HTTP aux endpoints générés, avec configuration du mode d’authentification et des feuilles à utiliser
  • Le démarrage suit un flux en 3 étapes — coller l’URL de la feuille, configurer l’API, puis envoyer des requêtes à l’endpoint — ce qui réduit la charge initiale de connexion
  • Le service met l’accent sur l’usage du tableur comme CMS côté client afin de tester des idées avec de vraies données
  • Les offres vont de 1 API gratuite et 200 requêtes/mois à Scout à 4,99 $/mois et Craft à 19,99 $/mois, et les offres publiques incluent lecture, écriture, modification et suppression

Transformer Google Sheets en API RESTful

  • Transforme des tableurs Google Sheets en API RESTful afin de permettre d’interroger et de manipuler des données avec de simples requêtes HTTP
  • Se présente comme un outil destiné aux développeurs qui veulent créer rapidement des prototypes, sites web et applications
  • Lors de la configuration de l’API, il est possible de définir le mode d’authentification, les feuilles à utiliser et d’autres paramètres
  • Le flux d’utilisation est résumé en 3 étapes
    • Copier-coller l’URL du Google Spreadsheet dans le tableau de bord
    • Configurer le mode d’authentification de la nouvelle API, les feuilles à utiliser, etc.
    • Une fois l’endpoint obtenu, envoyer des requêtes HTTP

Usages comme CMS et tarification

  • Le tableur peut être utilisé comme véritable stockage de données pour tester des idées et jouer le rôle de CMS utilisable par le client
  • Le service met en avant la possibilité de concrétiser des idées plus vite et à moindre coût que la création de son propre panneau d’administration backend
  • Les offres publiques sont les suivantes
    • Free : 0 $/mois, 1 API, onglets de feuille illimités, lecture, écriture, modification, suppression, 200 requêtes/mois
    • Scout : 4,99 $/mois, API illimitées, onglets de feuille illimités, lecture, écriture, modification, suppression, 400 requêtes/mois, support 24/7
    • Craft : 19,99 $/mois, API illimitées, onglets de feuille illimités, lecture, écriture, modification, suppression, 2000 requêtes/mois, support 24/7
  • Des offres personnalisées sont proposées sur demande séparée

À lire aussi

1 commentaires

 
GN⁺ 2024-04-13
Commentaires sur Hacker News

  • Il faut se méfier du piège du débutant avec Excel version moderne. Beaucoup de banques d’investissement y sont tombées dans les années 80-90 : comme les tableurs sont d’excellents frameworks de calcul générique, on finit par empiler dessus la gestion des risques, la tarification et même des fonctions opérationnelles, le tout sur d’énormes amas de fichiers Excel
    Avec des plugins et des extensions, on peut vraiment faire énormément de choses, mais au final le tableur devient un cauchemar impossible à maintenir et difficile à comprendre de l’intérieur, tandis que la logique métier essentielle se retrouve enfermée dans les feuilles personnelles de plusieurs personnes. Les changements à grande échelle deviennent difficiles ou impossibles, et même des modifications triviales dans un framework logiciel classique deviennent risquées et coûteuses à vérifier, car il faut corriger d’innombrables feuilles

    • On retrouve une situation très similaire avec le visual scripting dans le développement de jeux. À l’origine, ce sont des outils censés permettre aux designers ou aux artistes de faire de petites tâches — par exemple ouvrir une porte quand on appuie sur une plaque de pression — sans appeler un programmeur, mais le résultat grossit facilement jusqu’à devenir incontrôlable
      Il existe même un site qui ne rassemble que des exemples d’Unreal Engine : https://blueprintsfromhell.tumblr.com/. À mon avis, la solution passe par de bons outils de refactoring. Il faut pouvoir remettre de l’ordre avec des approches du type « extraire une méthode », sans qu’un programmeur ait à tout réécrire
    • Ce n’est pas toujours une question de choix. Au travail, il m’a fallu environ 4 heures de procédures diverses juste pour obtenir un environnement permettant d’exécuter un hello world Python conforme aux politiques internes
      Même pas un IDE complet ni des modules pip, juste un hello world, et malgré tout j’étais encore parmi les mieux lotis. Dans certaines entreprises financières, il n’y a tout simplement pas d’autre option. C’est un schéma fréquent : on donne seulement Excel aux employés de bureau, puis on s’étonne qu’ils construisent des monstres avec Excel
    • Je suis totalement d’accord. Mon entreprise actuelle n’a pas refactoré depuis plus de 10 ans son enchevêtrement de tableurs et de pipelines d’export de requêtes de base de données, et comme ça ne passe pas à l’échelle, l’argent s’échappe désormais de partout
      Ce genre de problème reste peu visible jusqu’au moment où tout s’effondre. Travailler simultanément dans des tableurs est presque l’une des choses les plus risquées qui soient, donc tous les processus critiques finissent avec des goulots d’étranglement. L’intégration des données est risquée et lente, et il est difficile de garantir la cohérence entre plusieurs tableurs. Si on avait migré plus tôt vers les bons outils, on n’aurait pas à continuer à bricoler du code qui n’aurait jamais dû exister
    • Au-delà du fait que « les changements à grande échelle deviennent difficiles ou impossibles », il n’y a pas de gestion de versions
      On peut sans doute stocker des tableurs dans un RCS, mais peut-on voir un diff pour vérifier que les changements qu’on s’apprête à pousser correspondent bien à l’intention ? Peut-on relire l’historique des diffs pour comprendre comment le système a évolué avec le temps ? Peut-on fusionner les modifications de plusieurs personnes ? Existe-t-il au moins une copie de travail pour les essais, ou bien modifie-t-on directement la copie de production sans filet de sécurité ?
    • Utiliser des feuilles uniquement comme stockage pourrait être acceptable. Je me demande simplement quelles sont les limites de taille

  • C’est une histoire intéressante. Avant de pivoter pour devenir Loom, la startup était une société de tests utilisateurs appelée Opentest, et au lieu de construire une base de données et un dashboard pour voir les demandeurs de tests utilisateurs précis, les cofondateurs ont simplement tout mis dans Google Sheets
    Ça marchait très bien. Pas de downtime, accès ouvert, et comme il n’y avait que trois personnes pour consulter et modifier, il n’y avait pas de conflits. Il n’y avait pas non plus à gérer des mises à niveau de base de données ou de la maintenance. Je repense souvent à cette décision, et j’ai l’impression qu’une bonne partie des « bonnes pratiques d’ingénierie » que j’ai apprises pâlit face au fait que bouger vite et de manière pragmatique peut, à certaines étapes, être une percée géniale

    • D’accord. Google Sheets est une bonne option pour tenir rapidement dans une startup ou une petite entreprise
      Je l’ai utilisé pour plusieurs systèmes de données qui ne devaient être modifiés que par un très petit nombre de personnes. Avec un peu de code soigneusement écrit et du cache, on peut facilement s’en servir comme frontend CRUD pour des données système importantes, par exemple en les synchronisant vers S3 après validation. C’est aussi bien pour des dashboards temporaires, et en le branchant à des API ou avec du code Google Scripts sur mesure, on peut même manipuler des API privées. J’ai déjà mis en place des rapports assez volumineux, avec plusieurs vues, tableaux croisés dynamiques, requêtes et consultations, qui se mettaient à jour automatiquement selon un planning. Oui, une solution développée sur mesure doit être bien meilleure que Google Sheets, mais elle ne pourra pas être développée plus vite. Et au moment où il faudra quelque chose de plus gros et de meilleur, les besoins seront aussi plus clairs et les ressources de développement plus accessibles
    • Je suis ingénieur logiciel dans un grand groupe, mais plusieurs des projets sur lesquels je travaille reposent sur Google Sheets. À certains endroits comme frontend, ailleurs comme backend
      C’est aussi parce qu’il y a beaucoup trop de procédures même pour utiliser des outils d’ingénierie aussi simples que React ou Postgres
    • On peut aussi voir Google Sheets comme une base de données NoSQL managée avec une interface d’administration intégrée
    • Si on ne permet qu’un export de données dans un seul sens, ça paraît être une bonne idée. Les problèmes commencent quand sept feuilles différentes doivent piloter de manière authoritative d’autres processus
      Comme les personnes qui écrivent dans un tableur peuvent en pratique y faire n’importe quelle transformation, ça casse très facilement
    • Ça a l’air correct, mais il faut d’abord obtenir l’autorisation avant de mettre les données de l’entreprise dans Google Sheets

  • Il n’y a même pas besoin d’un emballage sophistiqué. Il suffit d’ouvrir https://script.google.com/ : on a déjà accès à plusieurs API de Google, et on peut intégrer des feuilles avec l’envoi d’e-mails via Gmail, des changements de calendrier, la création de pages, le traitement d’entrées de formulaires, etc.
    Le problème, c’est qu’il n’y a pas d’opérations transactionnelles comme dans une vraie base de données. Par exemple, si l’on veut verrouiller une ressource donnée, cela peut échouer

    • Sur ce site, chaque fois que quelqu’un propose une solution simple à un problème, quelqu’un d’autre répond qu’il existe déjà une option bien plus complexe

  • Il est étonnant que personne n’ait encore mentionné Spread API : https://spreadapi.roombelt.com/
    C’est gratuit avec Google Sheets / Apps Script, et il suffit de le coller sur une feuille pour la transformer en CRUD complet. Il y a tout de même quelques limites de débit, mais c’est entièrement gratuit. J’avais déjà envisagé de créer une entreprise basée sur Sheets, mais dès qu’on atteint l’étape où les gens sont « prêts à payer », c’est aussi en général le moment où on dépasse Sheets. À cause des contraintes, on finit par vouloir passer de Sheets ou SpreadAPI à Turso, Cloudflare D1 ou Pocketbase

    • Je suis vraiment ravi que mon petit projet puisse être utile.
      Les idées d’amélioration ou les PR peuvent toujours être soumises ici : https://github.com/ziolko/spreadapi
    • Ça a l’air bien. En revanche, on dirait qu’on ne peut même pas insérer plusieurs lignes dans une seule requête, donc ça semble assez limité
    • Je me demande quelles sont les limites de débit de Spread API. Je n’ai pas trouvé l’information sur le site

  • Pour un usage similaire, je recommanderais PocketBase
    La semaine dernière, je cherchais un stockage de données arbitraires accessible via API et j’envisageais de faire un backend Google Sheets, mais PocketBase était simple et n’avait pas de limite de 60 requêtes par minute. Le déployer sur un VPS bon marché avec CapRover a aussi été très facile
    https://pocketbase.io/
    https://developers.google.com/sheets/api/limits

    • +1 pour PocketBase. J’utilise PocketBase pour la collecte de données classique, puis j’exporte en CSV via l’API pour transférer vers Google Sheet afin de consulter et modifier les données
      C’est très simple pour le prototypage comme pour le traitement réel, et utiliser Google Sheet comme backend est aussi une bonne idée, mais j’avais besoin de quelque chose comme l’authentification
    • J’ai regardé PocketBase, mais je n’ai pas bien compris comment l’utiliser. Je connais SQLite et je maîtrise SQL, mais je n’arrivais pas à voir concrètement comment m’en servir
    • Mon infrastructure est focalisée à 100 % sur la scalabilité, donc je pense qu’on pourrait travailler ensemble. Il suffirait de partager les coûts
      J’aimerais que vous m’envoyiez un message ici pour que je puisse obtenir vos coordonnées : https://www.zerosheets.com/contact

  • J’ai récemment créé une webapp complète en n’utilisant qu’AppsScript et Google Sheets comme base de données, j’en ai parlé ici https://thetechenabler.substack.com/i/142898781/making-a-sim... et je l’ai publiée ici https://github.com/eeue56/simple-link-aggregator
    C’était une expérience nouvelle, et l’idée de mettre devant une webapp sans configuration serveur tout en gardant derrière un stockage de données facile à manipuler pour des non-développeurs était particulièrement séduisante. Mais AppsScript est trop lent pour ce genre d’usage, donc l’expérience a du mal à être bonne. Zerosheets a l’air intéressant, et si je reviens sur cette idée, je l’examinerai de plus près

    • « Connecter une webapp à un stockage de données facile à manipuler pour des non-développeurs sans nécessiter de configuration serveur », n’est-ce pas justement l’un des cas d’usage d’Airtable ?

  • J’ai besoin de quelque chose comme ça pour ma prochaine idée de projet de script utilisateur. C’est pour un usage personnel, mais je dois remplir des relevés de notes via une interface web incroyablement pénible
    Il est bien plus simple de saisir les données dans un tableur. C’est d’ailleurs ce que je faisais avant, mais l’école a décidé de « simplifier » les choses en introduisant une horrible parodie de webapp CRUD ultra basique. J’aimerais donc créer un script utilisateur qui lise la feuille de calcul et remplisse ce formulaire web pénible à la place. Je n’ai pas encore commencé, parce que je n’ai même pas terminé mon billet de blog précédent sur les scripts utilisateur et que j’ai peur du cauchemar de l’authentification. Dans le contexte d’un script utilisateur, ce sera peut-être plus simple ou plus difficile ; comme on est dans la page web, il sera peut-être possible d’y faire un flux OAuth classique ou quelque chose du genre

    • Je me demande si vous avez regardé du côté d’Apps Script
    • Si vous utilisez Google Sheets, il faudra probablement passer par un flux OAuth classique. Une autre possibilité serait d’utiliser Excel et d’automatiser cela avec une macro simple
      Personnellement, je pense que le plus simple est d’éviter l’authentification, qui est la partie compliquée du script, puis de copier-coller les valeurs depuis le presse-papiers et de traiter les données

  • Il y a quelques jours, en regardant des templates et des alternatives à des CMS, je suis tombé sur l’outil interne de NPR pour publier des articles avec données, graphiques et visualisations : https://github.com/nprapps/dailygraphics-next
    J’ai trouvé intéressant qu’il inclue une utilisation de Google Sheets comme CMS

  • J’ai fait quelque chose de très similaire sur https://github.com/kellpossible/avalanche-report/ et j’ai commencé avec Google Sheets parce que cela permettait d’itérer rapidement sur le flux de saisie des données
    Avec un serveur, on pouvait aussi créer des graphiques et diagrammes personnalisés en mettant des requêtes URL construites dans la fonction IMAGE. Les lectures étaient mises en cache dans une base SQLite locale. On est en train de s’éloigner de Google Sheets maintenant, car la configuration est un peu fastidieuse et, dans notre cas d’usage, on ne peut pas empêcher totalement les utilisateurs de modifier les mauvais champs. Cela dit, ça a très bien tenu jusqu’ici, et comme point de départ, je le recommanderais vivement à tout le monde

  • J’avais déjà utilisé une Google Sheet pour alimenter la page de menu d’un site web de restaurant. C’était parfait
    À chaque changement, le restaurant mettait à jour le tableur et le site web le reflétait immédiatement, et si quelque chose était modifié par erreur, il suffisait de revenir en arrière

    • J’ai mis en place exactement la même chose pour un restaurant il y a quelques semaines. C’était simple et gratuit
      J’avais configuré Apps Script pour que le site soit reconstruit lors des mises à jour, donc toute modification déclenchait une nouvelle compilation puis un redéploiement du site statique