TL;DR: Sim, mas, por segurança, faça um back-end puxar os dados para o seu projeto de front-end, pelo menos.

Olá, leitores do CodeAspiras! Tudo tranquilo por aí?

Conforme prometido, segue um artigo que não seja de Golang! Sinceramente, eu quase publiquei um, mas lembrei da nossa promessa e resolvi mantê-lo em rascunho, rs. Então refleti sobre possíveis assuntos que poderia trazer a tona aqui no blog e lembrei de uma discussão que tive recentemente com um amigo, Wendel, sobre um projeto que ele estava desenvolvendo baseado em uma planilha do Google. No geral, esse artigo não é uma resposta a ele, pois nós encerramos a conversa no mesmo dia. Ainda assim, é um conhecimento que acredito ser interessante para outros iniciantes, pois pode trazer boa noção sobre responsabilidades de projetos front-end versus back-end. Vamos começar?

Premissa

Suponha que você tem uma planilha de gestão de custos de uma organização pública e quer prover mais transparência sobre essas informações para os interessados nesse assunto.

Você pode:

• compartilhar a planilha com a permissão restrita de leitura;

• fazer um site para expor esses dados:

  • migrando tudo para um banco de dados, ou;

  • fazendo o site ler o contéudo da própria planilha.

Prover acesso à planilha é, sem dúvida, a decisão mais rápida. Porém, pode ser que você coloque informações com nomenclaturas que os usuários comuns não compreendam. Por exemplo, dados com termos em inglês podem gerar barreiras de linguagem no entendimento da leitura da planilha.

Fazer um site e migrar todas as informações para um banco de dados seria a decisão mais demorada. E, aliás, pode ser até desnecessária caso não tenham a intenção de incluir mais "planilhas" ou "páginas de planilha" nesse site (banco de uma tabela só). Então, fica a pergunta: é possível usar a planilha do Google como banco de dados e importar os dados de lá?

SIM, É POSSÍVEL. Mas não é recomendado que você faça isso diretamente do seu front-end. Tudo o que você coloca no código do projeto front-end acabará sendo exposto na rede, de alguma forma. Então, se você colocar suas credenciais (leia-se token) de Google APIs para acessar a planilha diretamente lá, não estranhe se coisas estranhas começarem a aparecer em sua conta. Isso é, basicamente, um prato cheio para hackers tentarem todo tipo de malícia com suas credenciais, rs. O ideal é que, sempre que quiser acessar algum conteúdo com credenciais, crie uma rota em um servidor back-end para fazer essa requisição por você.

Jamais exponha credenciais no front-end

Salvo algumas raríssimas exceções, como, por exemplo, credenciais que servem para identificar a build do seu front-end para usar como autenticação na comunicação com o back-end. Disso, não tem como fugir, não é mesmo? E, mesmo assim, você não usará um token fixo. Vai ser a combinação de alguns fatores e recursos, como Cookies, Local Storage, SQLite, dados do navegador, etc.

E sobre esse projeto do exemplo, como são dados públicos, sinceramente, não acho que faz sentido criar uma barreira de credenciais entre o front-end e o back-end. O máximo que vai acontecer é que outros desenvolvedores vão poder enviar requisições diretamente ao seu back-end para acessar os dados da planilha. Se os dados são para dar transparência, então, qual o problema? Se não fosse esse cenário, aí sim seria um elemento obrigatório a se desenvolver também.

Resultado

title Planilha do Google como Banco de Dados



actor Usuário



Usuário->Front: GET /planilha-de-custo

note over Front: renderiza o HTML estático

Front->Usuário: mostra página padrão com\n efeito de "carregando..."

note over Front: prepara uma requisição para\n obter os dados da planilha

Front->Back: GET /api/v1/spreadsheet

note over Back: prepara as credenciais de Google APIs

Back->GoogleAPIs: GET sheets.googleapis.com/v4/spreadsheets{SPREADSHEET_ID}/values/{page}!{range}

note over GoogleAPIs: processa a requisição

GoogleAPIs->Back: retorna os dados

Back->Front: retorna os dados obtidos do GoogleAPIs

note over Front: renderiza os dados de acordo com o público-alvo

Front->Usuário: mostra a página final

A depender da linguagem que você vai utilizar no back-end, você pode ter uma biblioteca do Google APIs para facilitar a construção da requisição. Dá uma olhada na documentação:

• usando Google Client: https://developers.google.com/sheets/api/guides/values?hl=pt-br#read

• implementando a requisição manualmente: https://developers.google.com/sheets/api/samples/reading?hl=pt-br#single-range

E é isso. Você pode até melhorar essa arquitetura implementando algum esquema de cache para evitar excesso de requisições para os servidores da Google (eles não gostam nada disso). E o melhor de tudo: se o projeto evoluir e precisar armazenar mais recursos, você já teria meio caminho andado para migrar para banco de dados.

EDIT:

Recebi de um amigo de longa data, Nahum Sá, uma informação que complementa essa postagem com um caso de uso real que fizeram no projeto levels.fyi usando uma planilha do Google como banco de dados, provendo dados para milhões de usuários usando essa logística. No artigo do blog deles, mencionam que não desenvolveram back-end pois utilizaram um recurso serverless da Amazon, o AWS Lambda. Na arquitetura deles, o Lambda faz o mesmíssimo papel que descrevi no diagrama sequencial desse artigo, com o objetivo de não expor credenciais do Google APIs. Além disso, por ser um recurso da AWS, provavelmente trouxe já outros critérios de segurança, como a identificação de build de front-end que mencionei anteriormente também. Vale muito a pena a leitura para expandir seus horizontes e ver o que é possível de ser feito com muita performance como Menor Produto Viável (MVP), onde vocês podem fazer experimentos a baixo custo.

É claro que "baixo custo" é algo relativo. Para eles, sustentar invocações de Lambdas é baixo custo. Para desenvolvedores solitários que querem só rodar alguns experimentos com uma quantidade menor de usuários, pode ser caro. Tudo é relativo na hora de analisar quantos recursos você tem a sua disposição na construção da arquitetura, mas sempre haverá uma forma de montar alguma coisa. Enfim, é isso, um conteúdo extremamente relevante para o tópico deste artigo, espero que dê tempo de alguém ler, rs. E mais uma vez, obrigado, Nahum!!

Fonte do artigo: https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html (em inglês)

Curtiu?! Comenta e compartilha!! Você já tinha parado pra pensar na arquitetura dos projetos on-line como agora? Acha que devo enviar mais artigos como esse, discutindo e refinando ideias e abordando assuntos como cybersec? Deixa seus pensamentos aí nos comentários e até a próxima!

Inté!!