Explorando os limite de um projeto no Google App Script

Este artigo é apenas um registro da minha experiência sobre um projeto usando o google app script que estou fazendo e esando muito da IA como ajuda para acelarar o desenvolvimento do projeto.

Mas desde já, te adianto que vou trazer umas dicas valiosas sobre a minha experiência com este projeto. Meu foco aqui é passar as dicas que acredito serem úteis e ao mesmo tempo catalogar toda a estrutura do sistema para que eu o entenda melhor. Pois aoutilizar as ferramentas de IA na contrução deste projeto, eu perdi a linha e acabei me tornando um fantoche da própria IA onde eu apenas digito comandos e deixo a IA fazer tudo. Então por conta desta minha má pratica, venho através deste artigo resgatar a minha essência de programador que é ter o total controle sobre o que estou fazendo. Pois é vergonhoso da minha parte, desenvolver um sistema de forma 100% dependente de uma IA.

Sobre o projeto

Um sistema financeiro para o gerenciamento de dados de sobre uma associação ferroviária. O projeto usa como banco de dados uma planilha do google.

Pastas do projeto:

As pastas do projetos estão em dois tipos de camadas que são a camada de frontend e a camada de backend. Na camada de backend, temos apenas funções internas do app scripts que são os códigos com extessão .gs.

📍 Pastas internas [Backend]

📂API -> Onde estão todas as funções de cada módulo refernte a manipulação dos dados na planilha.

📂CORE -> São onde estão classes e funções mais elementares do sistema. Aqui temos a classe que gerencia o banco de dados (que manipula a planilha), funções utilitárias e definição de constantes.

📃 -> _Codigo.gs -> Arquivo principal do sistema

📃 -> _Config.gs -> Definição das constantes que mapeiam os dados da planilha como objetos de configuração.

📃 -> _Constants.gs -> Definição de constantes globais para uso interno do sistema.

📃 -> _Datasheet.gs -> Definição da classe responsável por gerenciar a manipulação e acesso aos dados da planilha.

📃 -> _Functions.gs -> Todas as funções utilitárias de uso geral no sistema.

📃 -> _Tests.gs -> Funções de teste para criação de cadastro de dados de teste na planilha.

A arquitetura MVC

O projeto é organizado seguindo a estrutura MVC, onde nela temos os controllers, as models e as views.

📂O controller

No controller, os arquivos são organizados em classes, cada classe tem seus métodos que vão se comunicar com o backend via google.script.run.  para chamada de funções internas do backend. É aqui que parte do sistema faz requisições internas para capturar os dados e renderiza-los no frontend. Porém o correto, é que todo controller execute somente chamadas a classe da Model, pois é a model que é a única responsável por se comunicar com o backend (script de código .gs). No geral, dentro desta arquitetura, o controller só deve ter a responsabilidade de processar ações elementares como CRIAR, EDITAR e EXCLUIR e sempre delegando estas ações para a model. E com base na resposta da model, ele executa a ação adequada na tela como mostrar mensagem de aviso, sucesso, erro e etc.

📂A model

A model é uma classe é uma classe genérica que fornece funções utilitárias para as classes model mais especializadas. Por exemplo, se temos o Fornecedor_Controller, vamos ter uma Fornecedor_Model que por sua vez vai herdar de Model. O propósito das classes model, é fornecer uma abstração de comunicação com o backend, ou seja: funções para cadastro, exclusão, listagem, filtro e demais ações que necessitam requisitar dados da planilha são semrpe responsabilidade de uma classe Model. Elas que processam estas coisas e normalmente são chamadas dentro de um controller para apenas retornar os dados. O controller com os dados em mãos deve apenas exibir avisos na tela.

📂A view

Tendo uma forte semelhança com o controller (pois neste contexto do app script, é difícil deixar a view ser realmente uma view de verdade) pois não é opssível processar código gs dentro da view. Então as classes views são responsáveis por receber dados da model exatamente como o controller faz. Mas ao invés de apenas exibir respostas na tela com base nos dados retornados, a view vai processar os dados para exibir na tela, seja uma lista de itens, tabelas e etc. Este é o foco da view, apenas renderizar os dados na tela.

Outras pastas

📂CSS

Contém o arquivo de estilo css do sistema inteiro.

📂UI

Aqui temos apenas o HTML puro de cada tela, ou seja, temos apenas a estrutura de cada página. As views que vão popular os dados adequados em cada uma destas respectivas páginas.

📂Modais

Da mesma forma que a UI, mas aqui separamos apenas os trechos de código HTML referente a telas modais do sistema.

📂App

Aqui temos funções e classes globais que serão de uso para as demais entidades do sistema como: controllers, views e models.

📃 -> App_Functions -> Apenas funções gerais para uso no script frontend.

📃 -> App_MVC_Model -> Classe geral para extender funcionalidades a todas as models específicas.

📃 -> App_MVC_View -> Classe geral para extender funcionalidades para todas as views.

📃 -> App_Router -> Classe pára gerenciar a navegação SPA do sistema

📃 -> App -> Listagem geral de todos os eventos dos elementos do sistema.

Arquivos principais do sistema

Entre os arquivos principais do sistema temos as páginas HTML que são as mais importantes, que são componentes cruciais para o arranjo do sistema.

Temos:

📃 -> UI_Index-> Página inicial do projeto que é chamada pela função doGet do backend. Tudo se inicializa aqui.

📃 -> UI_Login -> Página de login do sistema. Tela de entrada para o usuário acessar o painel adminitrativo.

📃 -> UI_Modais -> Trecho HTML dos principais modais do sistema.

📃 -> UI_Mydata -> Página dos dados do usuário logado no sistema.

📃 -> UI_Sidebar -> Código HTML responsável pela sidebar do painel admin.

Modelo da arquitetura

O projeto está bem grande (para um contexto de um projeto do google app script). Para um projeto fora deste ambiente, ele é pequeno ainda. Mas mesmo assim, todo o desafio é conseguir desenvolver isso tentando manter a agilidade do carregamento dos dados.