CloudPrep, prática de certificações cloud sem nada para manter a correr

O que estava em jogo

Aprendo a fazer, não a ler, e as certificações cloud são uma montanha de leitura. O que eu precisava era de prática: perguntas, repetição, feedback honesto. As ferramentas que a ofereciam conseguiam ser piores do que a documentação. As que experimentei eram atulhadas, confusas de navegar e carregadas de publicidade, ou cobravam uma subscrição por material que é, estranhamente, já gratuito: há comunidades que mantêm repositórios open-source destas perguntas, corrigidas e versionadas em público.

Fiz então o que qualquer pessoa sensata faria: propus-me fazer melhor. E melhor tinha uma forma precisa, porque eu estava a construir para um público de uma pessoa. Tinha de caber no meu tamanho, algo que uma só pessoa pudesse construir e manter a correr para sempre sem pedir atenção, e tinha de se ajustar à forma como estudo: prática que sobrevive a um voo ou a uma ligação morta, sem nenhum login entre mim e dez minutos de treino. Nada disso exige uma conta. Nada disso exige um servidor. O projeto tornou-se uma questão quase arquitetural: quanto produto se consegue entregar com zero infraestrutura para operar, e nada sobre o utilizador para proteger, porque nada é recolhido?

A infraestrutura mais barata de operar é a infraestrutura que não existe.

A decisão

Eliminar o back-end. Não “torná-lo serverless”, não “mantê-lo pequeno”: remover o runtime por completo. Uma aplicação construída ao tamanho de uma pessoa tem de custar zero a essa pessoa para se manter viva. Cada peça de trabalho que uma construção convencional faria a cada pedido acontece exatamente uma vez, no momento do build. Um scraper recolhe os bancos de perguntas dos seus repositórios open-source, um parser normaliza-os e valida-os num único dataset JSON, e a aplicação distribui esse dataset como um recurso estático ao lado do seu próprio código.

O que uma aplicação convencional guarda numa tabela de utilizadores, o CloudPrep guarda no dispositivo. Estatísticas, notas e progresso vivem no armazenamento do próprio browser, o que significa que a privacidade não é uma política em que o utilizador tem de confiar; é uma propriedade da arquitetura. Não há servidor para ser atacado nem conta para ser exposta, porque não há servidor e não há contas.

O que entregámos

Uma aplicação em Nuxt 4 que abrange certificações de Azure, AWS, Google Cloud e Databricks, atualmente construída sobre as coleções Ditectrev. O modo de estudo dá prática sem cronómetro e com feedback imediato; os flashcards de repetição espaçada percorrem os mesmos bancos; o IndexedDB e o localStorage guardam estatísticas, notas e progresso no dispositivo. Uma PWA instalável faz tudo funcionar offline, e o conjunto é publicado no Cloudflare Pages. Exames simulados cronometrados e análise de progresso são as peças que ainda estão a ganhar forma.

A stack, e porquê

Um dataset estático, em vez de uma base de dados e de uma API. A observação decisiva foi sobre a mudança: os bancos de perguntas mudam quando os repositórios de origem mudam, ou seja, ocasionalmente, não a cada pedido. Uma camada de base de dados e API passaria a vida inteira a servir bytes idênticos e à espera de atualizações de segurança. Compilar para um dataset estático validado move todo esse trabalho para o momento do build, onde as falhas são visíveis no CI em vez de em produção. Atualizar o catálogo é voltar a correr um build, não migrar uma base de dados.

Armazenamento no dispositivo, em vez de contas de utilizador. O design convencional de login mais tabela de utilizadores justifica a sua complexidade quando os dados têm de seguir o utilizador entre dispositivos ou alimentar um serviço. A preparação para exames é pessoal e de vida curta; o progresso importa durante semanas, num ou dois dispositivos que o utilizador já tem na mão. O IndexedDB e o localStorage aguentam isso sem esforço, e o que resta é privacidade estrutural: sem password para reutilizar, sem email para transformar em alvo de marketing, sem tabela de utilizadores para defender.

Nuxt, em vez de uma framework de aplicação mais pesada. A aplicação é um catálogo, um fluxo de quiz e um ciclo de flashcards: páginas com routing que partilham estado e componentes, exatamente a forma que uma meta-framework de Vue trata bem. A geração estática foi um resultado de primeira classe e não uma reflexão tardia, e é nisso que toda a arquitetura assenta.

O que mudou

• Milhares de perguntas, praticáveis offline, sem conta e sem nada a enviar dados para fora
• Custo de runtime zero e carga operacional zero, permanentemente, por construção
• O progresso e as notas pertencem ao dispositivo, por isso a privacidade é estrutural, não uma política
• Os novos bancos de perguntas chegam ao voltar a correr um build, não ao migrar uma base de dados