Zero Sheets, que usa Google Sheets como backend/API para apps
(zerosheets.com)- Zero Sheets es un servicio que convierte Google Sheets en una API JSON RESTful para poder manejar datos en prototipos, sitios web y apps sin un backend separado
- Se pueden consultar y manipular datos enviando solicitudes HTTP al endpoint generado, y también es posible configurar el método de autenticación y las hojas que se usarán
- El flujo de inicio consta de 3 pasos: pegar la URL de la hoja, configurar la API y enviar solicitudes al endpoint, lo que reduce la carga inicial de integración
- Se enfoca en usar hojas de cálculo como un CMS para clientes y probar ideas con datos reales
- Los planes van desde gratis con 1 API y 200 solicitudes al mes hasta Scout por $4.99 al mes y Craft por $19.99 al mes; los planes públicos incluyen leer, escribir, actualizar y eliminar
Convertir Google Sheets en una API RESTful
- Convierte hojas de cálculo de Google Sheets en una API RESTful para consultar y manipular datos con solicitudes HTTP simples
- Se presenta como una herramienta para que los desarrolladores creen rápidamente prototipos, sitios web y apps
- En la etapa de configuración de la API se pueden definir el método de autenticación, las hojas a usar y otras opciones
- El flujo de uso se resume en 3 pasos
- Copiar y pegar la URL de Google Spreadsheet en el panel
- Configurar el método de autenticación de la nueva API, las hojas a usar, etc.
- Recibir el endpoint y luego enviar solicitudes HTTP
Forma de uso como CMS y planes
- Permite usar la hoja de cálculo como si fuera un almacenamiento de datos real para probar ideas y cumplir el rol de CMS para clientes
- Destaca que permite implementar ideas de forma más rápida y económica que crear un panel backend propio
- Los planes públicos son los siguientes
- Free: $0/mes, 1 API, pestañas de hojas ilimitadas, leer, escribir, actualizar y eliminar, 200 solicitudes al mes
- Scout: $4.99/mes, APIs ilimitadas, pestañas de hojas ilimitadas, leer, escribir, actualizar y eliminar, 400 solicitudes al mes, soporte 24/7
- Craft: $19.99/mes, APIs ilimitadas, pestañas de hojas ilimitadas, leer, escribir, actualizar y eliminar, 2000 solicitudes al mes, soporte 24/7
- Los planes personalizados se ofrecen por consulta aparte
1 comentarios
Opiniones en Hacker News
Hay que tener cuidado con la versión moderna de la trampa para principiantes de Excel. Muchos bancos de inversión cayeron en esto en los 80 y 90: como las hojas de cálculo son excelentes como framework de cálculo de propósito general, terminaron montando gestión de riesgos, valuación y hasta funciones operativas sobre pilas enormes de archivos de Excel.
Con plugins y extensiones se pueden hacer muchísimas cosas, pero al final la hoja de cálculo se vuelve una pesadilla imposible de mantener y difícil de entender por dentro, y la lógica de negocio clave queda atrapada en hojas personales de varias personas. Los cambios amplios se vuelven difíciles o imposibles, y modificaciones que serían sencillas en un framework de software común terminan siendo riesgosas y costosas de verificar porque hay que corregir innumerables hojas.
Incluso hay un sitio que recopila casos de Unreal Engine: https://blueprintsfromhell.tumblr.com/. Personalmente creo que la solución es un buen soporte para refactorización. Un programador debería poder entrar y ordenar todo con cosas como “extraer método”, sin tener que reescribirlo todo desde cero.
No hablo de un IDE completo ni de módulos de pip, sino simplemente de hello world, y aun así fue de lo mejor que me ha tocado hasta ahora. Algunas financieras ni siquiera dan otra opción. Es un patrón común darle solo Excel al personal de oficina y luego sorprenderse de que la gente haya creado monstruos en Excel.
Estos problemas no se notan bien hasta que todo se derrumba. Trabajar simultáneamente en hojas de cálculo es casi de lo más riesgoso, así que todos los procesos críticos terminan con cuellos de botella. La integración de datos es riesgosa y lenta, y también es difícil garantizar consistencia entre hojas. Se termina parchando con código que no habría hecho falta si antes se hubieran migrado a herramientas adecuadas.
Se puede guardar una hoja de cálculo en RCS, pero ¿puedes ver un diff para confirmar que el cambio que vas a subir es el que querías? ¿Puedes revisar el historial de diffs para ver cómo cambió el sistema con el tiempo? Si varias personas hacen cambios, ¿puedes hacer merge? ¿Existe siquiera una copia de trabajo para experimentos, o editan directamente la copia de producción sin ninguna protección?
Es una historia interesante. Antes de pivotear la startup hacia Loom, era una empresa de pruebas con usuarios llamada Opentest, y los cofundadores, en vez de crear una base de datos y un dashboard para ver a solicitantes específicos de pruebas con usuarios, simplemente pusieron todo en Google Sheets.
Funcionó muy bien. No había downtime, el acceso era abierto, y como solo había 3 personas viendo y editando, no había conflictos. Tampoco había que ocuparse de upgrades ni mantenimiento de la base de datos. Pienso mucho en esa decisión, y siento que muchas de las “buenas prácticas de ingeniería” que aprendí palidecen frente al hecho de que moverse de verdad rápido y de forma pragmática puede ser, en cualquier etapa, un golpe de genialidad.
Lo he usado para datos de varios sistemas que solo muy pocas personas necesitan modificar. Con un poco de código cuidadoso y caching, por ejemplo sincronizando a S3 después de validar, puede usarse fácilmente como frontend CRUD para datos importantes del sistema. También sirve muy bien como dashboard temporal, y si lo conectas a una API o le agregas código personalizado de Google Scripts, también puedes manejar APIs privadas. He llegado a renovar automáticamente, según un calendario, reportes bastante grandes con varias vistas, tablas dinámicas, consultas y búsquedas. Un desarrollo a medida debe ser mucho mejor que Google Sheets, eso sí, pero no se puede construir más rápido. Para cuando necesites algo más grande y mejor, los requisitos también estarán más claros y probablemente ya puedas costear recursos de desarrollo.
En parte es porque hay demasiados procesos incluso para usar herramientas de ingeniería simples como React o Postgres.
Como quien escribe en la hoja de cálculo puede hacer básicamente cualquier transformación, se rompe con muchísima facilidad.
No hace falta un envoltorio sofisticado. Con solo abrir https://script.google.com/ ya tienes acceso a varias APIs de Google, y puedes integrar hojas con Gmail para enviar correos, modificar calendarios, crear páginas, procesar entradas de formularios, etc.
El problema es que no hay operaciones transaccionales como en una base de datos real. Por ejemplo, puede fallar cuando quieres bloquear un recurso específico.
Me sorprende que todavía nadie haya mencionado Spread API: https://spreadapi.roombelt.com/
Es gratis, usa Google Sheets / Apps Script, y con solo pegarlo en una hoja la convierte en un CRUD completo. Eso sí, tiene algunos límites de velocidad, pero es totalmente gratis. Hace tiempo pensé en una empresa basada en Sheets, pero cuando llegas al punto en que alguien “está dispuesto a pagar”, por lo general también es el momento en que ya estás superando a Sheets. Por las limitaciones, dan ganas de moverse a Turso, Cloudflare D1 o Pocketbase en vez de quedarse en Sheets o SpreadAPI.
Cualquier idea de mejora o PR se puede enviar aquí: https://github.com/ziolko/spreadapi
Para un uso similar, recomendaría PocketBase.
La semana pasada estaba buscando un almacén de datos arbitrario con acceso por API y pensé en hacer un backend con Google Sheets, pero PocketBase fue fácil y no tenía el límite de 60 solicitudes por minuto. También fue muy sencillo desplegarlo con CapRover en un VPS barato.
https://pocketbase.io/
https://developers.google.com/sheets/api/limits
Es muy fácil para prototipar y para procesar trabajo real. Usar Google Sheet como backend también está bien, pero necesitaba cosas como autenticación.
Me gustaría que me mandaras un mensaje por aquí para poder tener tus datos de contacto: https://www.zerosheets.com/contact
Hace poco hice una webapp completa usando solo AppsScript y Google Sheets como base de datos; escribí sobre eso aquí https://thetechenabler.substack.com/i/142898781/making-a-sim... y la publiqué aquí https://github.com/eeue56/simple-link-aggregator.
Fue una experiencia nueva, y me pareció especialmente atractiva la idea de tener un almacén de datos fácil de manejar para personas no desarrolladoras, con una webapp al frente que no requiera configurar servidores. Pero AppsScript es demasiado lento para este tipo de uso, así que difícilmente termina siendo una buena experiencia. Zerosheets se ve bien, y si vuelvo a considerar esta idea, planeo revisarlo con más detalle.
Necesito algo así para mi próximo proyecto de userscript. Es para uso personal, pero tengo que llenar boletas de calificaciones mediante una interfaz web tremendamente dolorosa.
Es mucho más fácil ingresar los datos en una hoja de cálculo. Antes de hecho lo hacía así, pero la escuela introdujo una especie de parodia horrible de una webapp CRUD muy básica para hacerlo “más fácil”. Por eso quiero hacer un userscript que lea desde la hoja de cálculo y llene ese formulario web incómodo de usar. Todavía no he empezado porque no he terminado el post del blog sobre mi experiencia anterior con userscripts, y porque me asusta la pesadilla de la autenticación. En el contexto de un userscript podría ser más fácil o más difícil; como está dentro de una página web, tal vez sea posible hacer desde ahí algo como un flujo OAuth normal.
Personalmente, creo que lo más fácil sería saltarse la parte compleja del script, que es la autenticación, copiar y pegar los valores desde el portapapeles, y luego procesar los datos.
Hace unos días estaba revisando alternativas de plantillas y CMS, y encontré esta herramienta interna de NPR para publicar artículos con datos, gráficos y visualizaciones: https://github.com/nprapps/dailygraphics-next
Me pareció interesante que incluya una forma de usar Google Sheets como CMS.
Hice algo muy parecido en https://github.com/kellpossible/avalanche-report/. Empezamos con Google Sheets porque nos permitía iterar rápido sobre el flujo de entrada de datos.
Usándolo junto con un servidor, también podíamos generar gráficos y diagramas personalizados poniendo consultas URL configuradas en la función IMAGE. Las lecturas se cachean en una base de datos SQLite local. Ahora estamos migrando fuera de Google Sheets, porque la configuración es algo engorrosa y, en nuestro caso de uso, no podemos impedir por completo que los usuarios editen campos equivocados. Aun así, hasta ahora nos ha funcionado muy bien, y lo recomendaría mucho a cualquiera como punto de partida.
Antes hice que la página del menú de un sitio web de restaurante funcionara con una Google Sheet. Fue perfecto.
Cada vez que el restaurante cambiaba algo, actualizaban la hoja de cálculo y se reflejaba de inmediato en la web; si tocaban algo mal, podían revertirlo.
Hice que Apps Script compilara el sitio al actualizarse, de modo que cualquier edición disparaba una recompilación y se redeployaba como sitio estático.