Zero Sheets usa o Google Sheets como backend/API para apps

• O Zero Sheets é um serviço que transforma o Google Sheets em uma API JSON RESTful, permitindo lidar com dados em protótipos, sites e apps sem um backend separado
• É possível consultar e manipular dados enviando requisições HTTP aos endpoints gerados, além de configurar o método de autenticação e as planilhas a serem usadas
• O fluxo inicial tem 3 etapas — colar a URL da planilha, configurar a API e enviar requisições ao endpoint — reduzindo o esforço de conexão inicial
• O foco é usar planilhas como um CMS para clientes, testando ideias com dados reais
• Os planos vão de 1 API gratuita e 200 requisições por mês até o Scout por US$ 4,99/mês e o Craft por US$ 19,99/mês; os planos públicos incluem leitura, escrita, atualização e exclusão

---

Transformar o Google Sheets em uma API RESTful

• Transforma planilhas do Google Sheets em uma API RESTful, permitindo consultar e manipular dados com requisições HTTP simples
• Apresenta-se como uma ferramenta para desenvolvedores criarem protótipos, sites e apps rapidamente
• Na etapa de configuração da API, é possível definir o método de autenticação, as planilhas a serem usadas e outras configurações
• O fluxo de uso é organizado em 3 etapas
  • Copiar e colar a URL da Google Spreadsheet no dashboard
  • Configurar o método de autenticação da nova API, as planilhas a serem usadas etc.
  • Receber o endpoint e enviar requisições HTTP

Forma de uso como CMS e planos

• Permite usar planilhas como um armazenamento de dados real para testar ideias e atribuir a elas o papel de CMS que clientes podem usar
• Destaca a possibilidade de implementar ideias de forma mais barata e rápida do que criar um painel de backend próprio
• Os planos públicos são os seguintes
  • Free: US$ 0/mês, 1 API, abas de planilha ilimitadas, leitura·escrita·atualização·exclusão, 200 requisições por mês
  • Scout: US$ 4,99/mês, APIs ilimitadas, abas de planilha ilimitadas, leitura·escrita·atualização·exclusão, 400 requisições por mês, suporte 24/7
  • Craft: US$ 19,99/mês, APIs ilimitadas, abas de planilha ilimitadas, leitura·escrita·atualização·exclusão, 2000 requisições por mês, suporte 24/7
• Planos personalizados são oferecidos mediante consulta separada

[GN⁺]

Opiniões no Hacker News

• É preciso tomar cuidado com a versão moderna da armadilha do iniciante em Excel. Nos anos 80 e 90, muitos bancos de investimento caíram nisso: planilhas são excelentes como frameworks genéricos de cálculo, então acabaram colocando gestão de risco, precificação e até funções operacionais em cima de enormes pilhas de arquivos Excel.
  Com plugins e extensões, dá para fazer muita coisa de verdade, mas no fim a planilha vira um pesadelo impossível de manter e difícil de entender por dentro, e a lógica de negócio central fica presa em planilhas pessoais de várias pessoas. Mudanças abrangentes se tornam difíceis ou impossíveis, e até alterações que seriam fáceis em um framework de software comum passam a exigir corrigir inúmeras planilhas, aumentando o risco e o custo de validação.

  • Em visual scripting para desenvolvimento de jogos acontece algo muito parecido. A ideia original é ser uma ferramenta para designers ou artistas fazerem pequenas tarefas, como abrir uma porta ao pisar numa placa de pressão, sem chamar um programador, mas o resultado facilmente cresce até sair do controle.
    Existe até um site só com casos do Unreal Engine: https://blueprintsfromhell.tumblr.com/. Pessoalmente, acho que a solução é um bom suporte a refatoração. Um programador precisa conseguir entrar e organizar tudo com coisas como “extrair método”, sem ter que reescrever tudo do zero.
  • Nem sempre é uma questão de escolha. No trabalho, só para conseguir um ambiente onde eu pudesse rodar um hello world em Python em conformidade com as políticas, levei umas 4 horas passando por vários procedimentos.
    Não era uma IDE completa nem módulos pip, era só um hello world, e mesmo assim isso até foi melhor do que em outras ocasiões. Algumas empresas financeiras simplesmente não dão outra opção. É um padrão comum dar apenas Excel aos funcionários de escritório e depois se surpreender quando as pessoas criam monstros em Excel.
  • Concordo totalmente. A empresa em que trabalho não refatorou, por mais de 10 anos, uma estrutura emaranhada de planilhas e pipelines de exportação de consultas de banco de dados, e agora dinheiro está vazando por todos os lados porque isso não escala.
    Problemas assim não aparecem bem até tudo desmoronar. Trabalhar simultaneamente em planilhas é uma das coisas mais arriscadas, então todos os processos críticos acabam criando gargalos. A integração de dados é arriscada e demorada, e também é difícil garantir consistência entre planilhas. Continuamos remendando com código que não seria necessário se tivéssemos migrado antes para ferramentas adequadas.
  • Além de “mudanças abrangentes se tornam difíceis ou impossíveis”, não há controle de versão.
    Dá para armazenar planilhas em um RCS, mas você consegue ver um diff para confirmar que a alteração que está prestes a enviar é a pretendida? Consegue revisar o histórico de diffs para entender como o sistema mudou ao longo do tempo? Se várias pessoas fizerem alterações, dá para mesclar? Existe ao menos uma cópia de trabalho separada para experimentos, ou todo mundo edita diretamente a cópia de produção sem nenhuma proteção?
  • Usar a planilha apenas como repositório talvez seja aceitável. Só fico curioso sobre quais seriam os limites de tamanho.

• É uma história interessante. Antes de pivotar a startup para o Loom, ela era uma empresa de testes com usuários chamada Opentest, e os cofundadores, em vez de criar um banco de dados e um dashboard para visualizar determinados solicitantes de testes com usuários, simplesmente colocaram tudo no Google Sheets.
  Funcionou muito bem. Não havia downtime, o acesso era aberto, só havia 3 pessoas vendo e editando, então não havia conflitos. Também não era preciso lidar com upgrades ou manutenção de banco de dados. Penso bastante nessa decisão, e sinto que muito do que aprendi como “boas práticas de engenharia” empalidece diante do fato de que agir de forma realmente rápida e pragmática pode ser um avanço genial em qualquer etapa.

  • Concordo. O Google Sheets é uma boa opção para startups ou empresas pequenas aguentarem o tranco rapidamente.
    Já usei para dados de vários sistemas que só precisavam ser editados por pouquíssimas pessoas. Com um pouco de código cuidadoso e cache, por exemplo sincronizando com o S3 após validação, dá para usá-lo facilmente como frontend de CRUD para dados importantes de sistema. Também é bom para dashboards temporários e, se conectado a APIs ou com código personalizado em Google Scripts, dá para lidar até com APIs privadas. Já automatizei a atualização agendada de relatórios relativamente grandes com várias visualizações, tabelas dinâmicas, consultas e buscas. É verdade que algo desenvolvido sob medida precisa ser muito melhor que o Google Sheets, mas não dá para construir mais rápido. Quando chegar a hora de precisar de algo maior e melhor, os requisitos também estarão mais claros e a empresa provavelmente já poderá bancar os recursos de desenvolvimento.
  • Sou engenheiro de software em uma grande empresa, mas a base de vários projetos em que trabalho é o Google Sheets. Em alguns lugares ele é usado como frontend; em outros, como backend.
    Em parte, porque até usar ferramentas simples de engenharia como React ou Postgres envolve procedimentos demais.
  • O Google Sheets também pode ser visto como um banco de dados NoSQL gerenciado com UI administrativa embutida.
  • Parece uma boa ideia se for possível fazer apenas despejo de dados em uma direção. O problema começa quando sete planilhas precisam controlar, de forma autoritativa, outros processos.
    Quem escreve na planilha pode, na prática, fazer qualquer tipo de transformação, então ela quebra com muita facilidade.
  • Parece ok, mas antes de colocar dados da empresa no Google Sheets, é preciso pedir permissão.

• Não há necessidade de um wrapper sofisticado. Basta abrir https://script.google.com/ e você já tem acesso a várias APIs do Google, podendo integrar uma planilha ao Gmail para enviar e-mails, alterar calendários, criar páginas, processar entradas de formulários etc.
  O problema é que não há operações transacionais como em um banco de dados de verdade. Por exemplo, isso pode falhar quando você quer bloquear um recurso específico.

  • Neste site, sempre que alguém cria uma solução simples para algum problema, outra pessoa aparece dizendo que já existe uma opção muito mais complexa.

• É surpreendente que ninguém ainda tenha mencionado a Spread API: https://spreadapi.roombelt.com/
  É Google Sheets / Apps Script gratuito e, bastando colar na planilha, transforma tudo em um CRUD completo. Há um certo limite de velocidade, mas é totalmente grátis. No passado, já pensei em uma empresa baseada em Sheets, mas quando se chega ao estágio em que as pessoas “estão dispostas a pagar”, em geral também é o momento de superar o Sheets. Por causa das limitações, em vez de ficar no Sheets ou no SpreadAPI, dá vontade de migrar para Turso, Cloudflare D1 ou Pocketbase

  • Fico muito feliz que meu pequeno projeto esteja sendo útil
    Ideias de melhoria ou PRs são sempre bem-vindos aqui: https://github.com/ziolko/spreadapi
  • Parece bom. Mas, pelo que vi, ele nem consegue inserir várias linhas em uma única requisição, então parece bastante limitado
  • Fiquei curioso sobre qual é o limite de velocidade da Spread API. Não encontrei essa informação no site

• Para um uso parecido, eu recomendaria o PocketBase
  Na semana passada, eu estava procurando um armazenamento de dados arbitrário com acesso via API e pensei em criar um backend com Google Sheets, mas o PocketBase foi fácil e não tinha o limite de 60 chamadas por minuto. Também foi muito fácil fazer o deploy com CapRover em uma VPS barata
  https://pocketbase.io/
  https://developers.google.com/sheets/api/limits

  • Mais um voto para o PocketBase. Uso PocketBase para coleta de dados em geral e exporto CSV via API para levar ao Google Sheet para visualização e edição
    É muito fácil para prototipagem e para tocar trabalho real, e usar o Google Sheet como backend também é bom, mas eu precisava de coisas como autenticação
  • Dei uma olhada no PocketBase, mas não entendi bem como deveria usá-lo. Conheço SQLite e sei bem SQL, mas não tive uma noção clara de como usá-lo na prática
  • Minha infraestrutura é 100% focada em escalabilidade, então acho que poderíamos trabalhar juntos. Só precisaríamos dividir os custos
    Seria ótimo se você me mandasse uma mensagem por aqui para eu poder pegar seu contato: https://www.zerosheets.com/contact

• Recentemente criei uma webapp completa usando apenas AppsScript e Google Sheets como banco de dados, escrevi sobre isso aqui https://thetechenabler.substack.com/i/142898781/making-a-sim... e publiquei aqui https://github.com/eeue56/simple-link-aggregator
  Foi uma experiência nova, e achei especialmente atraente a ideia de ter um armazenamento de dados fácil de ser manipulado por não desenvolvedores, com uma webapp na frente que não exige configuração de servidor. Mas o AppsScript é lento demais para esse tipo de uso, então dificilmente vira uma boa experiência. O Zerosheets parece bom e, se eu voltar a essa ideia, pretendo investigar melhor

  • “Colocar uma webapp sobre um armazenamento de dados fácil de ser manipulado por não desenvolvedores, sem exigir configuração de servidor” não é um dos casos de uso do Airtable?

• Preciso de algo assim para a ideia do meu próximo projeto de user script. É para uso pessoal, mas preciso preencher boletins em uma UI web extremamente dolorosa
  É muito mais fácil inserir os dados em uma planilha. Antes eu fazia exatamente isso, mas a escola introduziu algo que parece uma paródia horrível de uma webapp CRUD extremamente básica, dizendo que seria “mais fácil”. Então quero criar um user script que leia da planilha e preencha o formulário web incômodo de escrever. Ainda não comecei porque nem terminei o post do blog sobre minha experiência anterior com user scripts, e porque tenho medo do pesadelo da autenticação. No contexto de um user script, isso pode ser mais fácil ou mais difícil; como ele fica dentro da página web, talvez dê para fazer ali algum fluxo normal de OAuth

  • Você chegou a verificar o Apps Script?
  • Se usar Google Sheets, provavelmente terá de seguir um fluxo OAuth normal. Como alternativa, você poderia usar Excel e automatizar com uma macro simples
    Pessoalmente, acho que o jeito mais fácil é pular a parte complexa do script, que é a autenticação, copiar e colar os valores da área de transferência e então processar os dados

• Alguns dias atrás, enquanto eu pesquisava alternativas de templates e CMS, encontrei a ferramenta interna da NPR para publicar matérias com dados, gráficos e visualizações: https://github.com/nprapps/dailygraphics-next
  Achei interessante que ela inclui uma forma de usar o Google Sheets como CMS

• Fiz algo muito parecido em https://github.com/kellpossible/avalanche-report/. Começamos com Google Sheets porque permitia iterar rapidamente no fluxo de entrada de dados
  Usando junto com um servidor, também era possível criar gráficos e diagramas personalizados colocando queries de URL configuradas na função IMAGE. As leituras são armazenadas em cache em um banco SQLite local. Agora estamos saindo do Google Sheets, porque a configuração é um pouco trabalhosa e, no nosso caso de uso, não dá para impedir completamente que usuários editem campos errados. Ainda assim, ele aguentou muito bem até agora, e eu o recomendaria fortemente a qualquer pessoa como ponto de partida

• Antigamente, eu alimentava a página de menu de um site de restaurante com um Google Sheet. Era perfeito
  Sempre que algo mudava, o restaurante atualizava a planilha e isso aparecia imediatamente na web; se alguém mexesse em algo errado, bastava reverter

  • Algumas semanas atrás configurei exatamente a mesma coisa para um restaurante. Era simples e gratuito
    Fiz o Apps Script compilar o site quando havia atualização, então qualquer edição disparava uma nova build e fazia o redeploy como site estático