Olá! Para quem não sabe, além de escritor deste blog cristão, também sou programador. E graças à ajuda das IAs, meu trabalho ficou muito mais fácil — tanto que consegui lançar dois webapps que acredito serem de extrema importância para a comunidade cristã.
Este primeiro artigo fará parte de uma série de artigos explorando a jornada (um pouco mais técnica) sobre a implementação (deploy) desses dois webapps, que futuramente podem — e devem — se tornar também apps mobile para serem baixados nas stores de smartphones.
Espero escrever estes artigos pelo menos uma vez por mês, ou até antes (quem sabe uma vez por semana, dependendo das novidades que forem surgindo e da minha capacidade de escrever com determinada frequência). Quero relatar a jornada desde o começo até, espero eu, uma “viralização”, ou pelo menos que muitas pessoas acessem. Então vamos lá!
📖 Primeiro Webapp: biblia.creio.eu
Trata‑se de uma Bíblia interlinear verso a verso, com tradução literal e referências de léxicos nos manuscritos e idiomas bíblicos mais antigos e importantes:
Hebraico
Aramaico
Grego
Latim
Siríaco
Ge’ez
Armênio
É um projeto open‑source, ou seja, aberto e gratuito — qualquer pessoa pode acessar e ver como ele foi feito. Utiliza apenas fontes e referências de domínio público e, graças a Deus, muitas delas são realmente as melhores e principais para estudos bíblicos avançados!
🛠️ Falando um pouco da programação
🧰 Stack Tecnológica
| Camada | Tecnologia |
|---|---|
| Framework | Next.js App Router |
| UI/UX | Vanilla CSS + Design System Premium |
| Runtime | React 19 |
| Hospedagem | GitHub Pages (Exportação Estática) |
| Dados | Datasets JSON estruturados (JSON‑LD ready) |
🏗️ Arquitetura
🚀 Exportação Estática: páginas geradas no build para velocidade máxima e SEO.
📦 Estrutura de Dados: servidos como arquivos estáticos a partir de
public/data/, sem necessidade de banco de dados ativo.🗺️ Roteamento Dinâmico: navegação instantânea via roteamento client‑side do Next.js.
🔗 Repositório: https://github.com/cristianismohumilde/biblia.eu.creio (github.com in Bing)
🧩 Dificuldade deste projeto
O site em si foi relativamente tranquilo de construir. O mais difícil está sendo o preenchimento das informações, ou seja, o conteúdo mesmo:
muitos idiomas
cada um com suas particularidades
diversos manuscritos antigos
trabalho verso por verso
idioma por idioma
manuscrito por manuscrito
Apesar de não ser muito difícil tecnicamente, é extremamente trabalhoso. Mas o resultado, para quem ama as Escrituras como eu, é muito recompensador.
Em breve espero criar um tutorial de como alguém, mesmo sem saber nada de programação, pode colaborar com o projeto enviando pull‑requests e utilizando IAs para realizar o preenchimento e verificação — assim como eu estou fazendo.
🎮 Segundo Webapp: creio.eu
Este é aquele que eu acredito que pode mudar todo o rumo da história cristã — não só em nosso país, mas no mundo todo!
Trata‑se de uma plataforma gamificada que une conhecimentos bíblicos e gerais através de jogos interativos, para todas as idades. Esse projeto não foi fácil de tirar do papel, mas graças à ajuda da IA pude escolher o melhor framework disponível no momento.
🧭 Antes de revelar a stack…
Quero abordar um pouco do contexto no qual consegui criar a primeira versão da plataforma.
Após comparar algumas hospedagens de sites, a Hostinger parecia a melhor — e de fato, pelo que usei, era muito boa. Mas, pesquisando, descobri que hospedagens compartilhadas podem travar se tiverem muitos usuários. Como eu já tinha um projeto lá que funcionava muito bem e não queria que caísse, resolvi procurar outra solução…
Mas antes disso, eu já tinha construído o meu projeto e estava funcionando bem — e é aqui que você, leitor, descobre a stack e o framework para projetos pequenos e performáticos, que eu descobri meio que “na marra”.
No começo fiz tudo do zero com JavaScript puro, depois adicionei PHP, e por último percebi que um framework como Laravel seria a melhor solução para a plataforma que estava desenvolvendo.
Deu tudo certo. Ainda estou realizando muitas melhorias, mas o projeto ficou tão bom que já comecei a compartilhar. Até agora, o máximo de usuários cadastrados foi 29.
Também desenvolvi um app para celular, que pretendo lançar no futuro, e também transformar o webapp em mobile app através de ferramentas como Capacitor e Ionic.
📱 Capacitor e Ionic — Explicação clara e direta
Transformar um site em um app usando Capacitor ou Ionic é uma das formas mais práticas de criar aplicativos Android e iOS a partir de um projeto web já existente.
A ideia central é simples: Seu site roda dentro de um WebView, mas com acesso a recursos nativos do celular (câmera, GPS, arquivos, notificações etc.).
🚀 O que é o Capacitor?
Ferramenta criada pela equipe do Ionic que permite:
transformar um site em app nativo
acessar APIs nativas
gerar projetos Android e iOS reais
publicar nas stores
Ele funciona como uma ponte entre web e nativo.
Como funciona na prática:
Você cria ou usa seu site (HTML, CSS, JS, React, Vue, Angular etc.)
Instala o Capacitor no projeto
Roda um comando para gerar o app
Abre o projeto no Android Studio ou Xcode
Compila e publica
Seu site continua sendo um site — mas agora empacotado como app.
📱 O que é o Ionic?
O Ionic é um framework de UI para criar apps híbridos.
Você usa Ionic quando quer:
criar um app com cara de app, não de site
usar componentes prontos (tabs, menus, listas, botões)
ter animações e navegação estilo mobile
Resumo:
Capacitor = transforma seu site em app
Ionic = framework para criar apps híbridos completos
Você pode usar Capacitor sozinho ou Ionic + Capacitor
☁️ A saga das hospedagens
Depois de decidir sair da hospedagem compartilhada da Hostinger, tentei ativar a cloud da Oracle, que tem os melhores benefícios grátis. Mas não consegui porque só tinha cartões virtuais ou físicos de bancos virtuais, e a Oracle é muito rígida com cartões — não aceita qualquer um.
Então descobri que a Azure oferece:
plano F1 grátis para sempre (com muitas limitações)
mais US$ 100 de crédito para escalar
Coloquei meu webapp na Azure no plano F1 e configurei os 4 alertas essenciais recomendados pela IA:
🚨 Os 4 alertas essenciais no Azure F1
(mantive tudo exatamente como você escreveu, apenas corrigi e formatei)
🔥 1) CPU Percentage (Uso acima de 80%)
O plano F1 tem CPU extremamente limitada. Se passar de 80%:
o app fica lento
começa a recusar requisições
pode ser reciclado automaticamente
Configuração recomendada: Métrica: CPU Percentage Condição: > 80% Período: 5 minutos
🧠 2) Memory Working Set (Memória acima de 70–80%)
Pouquíssima memória. Quando estoura:
o processo é reciclado
o app reinicia
usuários veem erros intermitentes
Configuração recomendada: Métrica: Memory Working Set Condição: > 70% Período: 5 minutos
🌐 3) HTTP 5xx Errors
Comum no F1 quando:
app sobrecarrega
limite de conexões é atingido
site reinicia
Configuração recomendada: Métrica: Http 5xx Condição: > 5 erros em 5 minutos
🚫 4) Requests Queued
Quando o app não atende rápido o suficiente:
lentidão
gargalo de CPU
gargalo de memória
risco de travamento
Configuração recomendada: Métrica: Requests Queued Condição: > 10 requisições na fila
Cada alerta custa US$ 0,50/mês, totalizando US$ 2/mês. Como tenho US$ 100, no próximo mês terei US$ 98.
O problema é que está apitando bastante, mesmo com o site otimizado e praticamente sem usuários. Então em breve vou ter que ir para o plano B1 e torrar os créditos, que devem durar de 3 a 4 meses.
Vou tentar cadastrar outros cartões na Oracle. Se não der certo, vou migrar para a Google Cloud, que tem melhor custo‑benefício.
🧭 O que considerar para uma plataforma Laravel que vai escalar
Antes da comparação, estes são os fatores que mais impactam custo‑benefício:
Preço por VM / CPU / RAM
Rede e CDN
Banco de dados gerenciado
Escalabilidade automática
Complexidade operacional
Custo de saída (egress)
Latência no Brasil
🥇 Comparação Geral (Laravel + Escalabilidade)
| Provedor | Pontos Fortes | Pontos Fracos | Melhor Uso |
|---|---|---|---|
| Azure | Excelente integração corporativa, serviços gerenciados maduros, forte em segurança e compliance | Preço mais alto, curva de aprendizado maior | Apps corporativos, integrações Microsoft |
| Google Cloud | Rede global rápida, ótimo custo em banco de dados e Kubernetes, forte em dados e ML | Preços variáveis, menos opções de datacenter no Brasil | Apps que exigem performance e escalabilidade |
| Cloudflare | CDN global, Workers extremamente baratos, egress quase zero, escalabilidade automática | Não é uma “cloud completa”, limitações para apps stateful | APIs, sites estáticos, edge computing |
| Oracle Cloud (OCI) | Preço agressivo, VMs potentes, rede rápida, bom custo‑benefício geral | Ecossistema menor, menos serviços que Azure/GCP | Laravel com alta performance e baixo custo |
| Laravel Cloud | Deploy simplificado, ambiente otimizado para Laravel, zero DevOps | Não é uma cloud completa, escalabilidade limitada, custo maior por recurso | Projetos pequenos/médios, equipes sem DevOps |
🔍 Análise detalhada por provedor
1) Azure
Prós
Forte integração com ferramentas Microsoft (AD, DevOps, Monitor)
Serviços gerenciados robustos (MySQL, Redis, Kubernetes)
Excelente para arquiteturas corporativas complexas
Contras
Geralmente mais caro
Plano gratuito muito limitado
Para Laravel: ótimo para empresas, mas caro para escalar.
2) Google Cloud Platform (GCP)
Prós
Rede global de baixa latência
Compute Engine com bom custo por performance
Cloud SQL e GKE muito maduros
Contras
Preços variam bastante
Menos regiões na América Latina
Para Laravel: excelente para escalabilidade real, especialmente com Kubernetes.
3) Cloudflare
Prós
CDN global com latência mínima
Workers e KV extremamente baratos
Egress quase zero (grande vantagem)
Contras
Não hospeda apps Laravel tradicionais (PHP stateful)
Ideal para edge, não para backend completo
Para Laravel: ótimo como CDN, cache, firewall e edge, mas não como servidor principal.
4) Oracle Cloud (OCI)
Prós
Melhor custo por CPU/RAM entre as grandes clouds
Rede rápida e estável
Preços agressivos e previsíveis
Bons serviços de banco de dados
Contras
Ecossistema menor
Menos tutoriais e comunidade
Para Laravel: provavelmente o melhor custo‑benefício para escalar com VMs e banco gerenciado.
5) Laravel Cloud
Prós
Deploy extremamente simples
Ambiente otimizado para Laravel
Sem necessidade de DevOps
Contras
Custo por recurso mais alto
Escalabilidade limitada comparada às clouds reais
Não é ideal para tráfego massivo
Para Laravel: ótimo para começar, não ideal para escalar barato.
🏆 Conclusão: qual tem o melhor custo‑benefício para escalar Laravel?
🥇 Melhor custo‑benefício geral: Oracle Cloud
VMs baratas
Rede rápida
Banco gerenciado acessível
Escala bem sem explodir custos
🥈 Melhor performance global: Google Cloud
Rede superior
Ótimo para autoscaling
Bom custo por performance
🥉 Melhor complemento: Cloudflare
Use como CDN, cache e segurança
Reduz custos de egress e carga no backend
Para empresas Microsoft: Azure
Para simplicidade: Laravel Cloud
🔌 API‑First — Por que vamos transformar o webapp
API First é uma abordagem em que a API é projetada antes do código, servindo como contrato central do sistema. Ela melhora consistência, escalabilidade e colaboração entre equipes, e hoje é considerada uma prática madura e estratégica no desenvolvimento moderno.
A seguir, explico o conceito com profundidade, comparo com outras abordagens e trago evidências recentes sobre sua adoção.
🌐 O que é API First
Segundo fontes especializadas, API First significa tratar a API como “cidadã de primeira classe”, definindo seu contrato antes da implementação do sistema. Isso inclui endpoints, métodos, tipos de dados, erros e autenticação.
A API se torna a fonte única de verdade, permitindo que front‑end, back‑end, QA e DevOps trabalhem em paralelo com base em um contrato estável.
🚀 Por que o mercado está adotando API First
Relatórios recentes mostram que 82% das organizações já adotam alguma forma de API First, e 25% operam totalmente nesse modelo, com crescimento anual significativo.
Isso acontece porque a abordagem:
reduz retrabalho
acelera entregas
melhora governança
facilita integração entre sistemas
prepara produtos para escalar
🧩 Benefícios principais (com base em fontes especializadas)
1) Consistência e padronização
APIs definidas no início garantem design uniforme, reduzindo erros e divergências entre serviços.
2) Desenvolvimento paralelo
Com o contrato pronto, equipes podem trabalhar simultaneamente, acelerando o ciclo de entrega.
3) Integração facilitada
Mock servers e validações antecipadas permitem detectar falhas antes da implementação real.
4) Reutilização e escalabilidade
APIs bem projetadas podem ser reaproveitadas em múltiplos produtos e microserviços.
⚠️ Riscos e desafios da abordagem
Embora poderosa, API First exige disciplina:
necessidade de governança forte
maturidade em design de APIs
dependência de ferramentas como OpenAPI, Postman, Stoplight
risco de “superplanejamento” se o time não for ágil
Esses pontos são citados como desafios comuns em adoções corporativas.
🔍 Comparação rápida: API First vs outras abordagens
| Abordagem | Como funciona | Quando usar |
|---|---|---|
| API First | API é definida antes do código | Plataformas, ecossistemas, microserviços, produtos que precisam escalar |
| API Design First | Foco extremo no design da API, documentação e governança | Times grandes, compliance, integrações complexas |
| Code First | Código é escrito primeiro e a API emerge depois | Projetos pequenos, MVPs, protótipos rápidos |
🎯 Minha visão (baseada nas evidências)
API First não é apenas uma técnica, mas uma filosofia que transforma APIs em produtos. Para plataformas que precisam escalar, integrar parceiros, expor serviços ou evoluir rapidamente, API First é quase obrigatório.
Para projetos pequenos ou experimentais, pode ser exagero — mas para qualquer produto que pretende crescer, é uma vantagem competitiva clara.
🎯 Quando API vale MUITO a pena
API começa a fazer sentido quando você precisa de pelo menos um destes cenários:
1) Você terá mais de um front-end
Se você pretende ter:
site web
app mobile (Capacitor, Ionic, React Native, Flutter)
painel administrativo separado
integrações com parceiros
➡️ API é essencial. Sem ela, você vai duplicar lógica, dados e regras.
2) Você precisa de dados dinâmicos
Se o conteúdo vai deixar de ser 100% estático e passar a depender de:
usuários logados
permissões
pagamentos
dashboards
dados que mudam o tempo todo
➡️ API é o caminho natural.
3) Você quer escalar com segurança
APIs permitem:
rate limiting
logs centralizados
versionamento
auditoria
cache inteligente
monitoramento real
➡️ Isso evita que seu produto quebre quando crescer.
4) Você quer abrir seu ecossistema
Se no futuro você imagina:
parceiros consumindo seus dados
integrações externas
automações
webhooks
➡️ API é obrigatória.
🧩 Quando API NÃO vale a pena
Se sua plataforma é:
100% estática
sem login
sem dados dinâmicos
sem app mobile
sem integrações externas
sem necessidade de escalabilidade complexa
➡️ API só adiciona complexidade desnecessária.
No seu caso atual (Next.js exportado + JSON local), você está no limite entre:
um site estático muito bem feito, e
uma plataforma que pode virar produto.
A decisão depende do seu plano de crescimento.
🔥 Checklist rápido: API vale a pena para você?
Marque mentalmente:
( ) Vou ter app mobile
( ) Vou ter login
( ) Vou ter painel administrativo
( ) Vou ter dados dinâmicos
( ) Vou ter integrações externas
( ) Vou ter múltiplos front-ends
( ) Quero escalar com segurança
( ) Quero vender minha plataforma como produto
Se você marcou 3 ou mais, API vale a pena. Se marcou 0 ou 1, API não vale agora.
🎯 Resumo rápido (a resposta curta)
Para o seu projeto:
API‑First agora = menos retrabalho, mais escalabilidade, app mobile mais fácil, ranking global mais consistente e um backend mais limpo.
Se você deixar para depois, você vai duplicar lógica, quebrar features e ter que reescrever partes do backend.
🚀 Por que API‑First faz sentido AGORA para o seu projeto
A sua plataforma tem características que tornam API‑First praticamente obrigatória:
🧩 1) Você tem um ecossistema multi‑front (web + futuro app mobile)
Seu webapp atual usa Blade, Alpine e Tailwind. O app mobile (que você já planeja) vai precisar:
login
ranking
missões
XP
streak
relíquias
perfil público
IA do Oráculo
Se você não tiver API:
você vai duplicar lógica
vai duplicar validações
vai duplicar regras de XP
vai duplicar ranking
vai duplicar autenticação
➡️ API‑First evita tudo isso.
🧠 2) Seu produto é um “jogo” — e jogos precisam de backend centralizado
Você tem:
XP
streak
ranking global
ranking semanal
relíquias
missões multi‑etapas
sistema de referral
Aura PRO (premium)
Isso tudo precisa ser consistente entre web e mobile.
Se você deixar o backend “acoplado ao Blade”, você vai sofrer quando o app chegar.
➡️ API‑First garante que tudo isso exista em um único lugar.
🏆 3) Ranking Global e Ranking Semanal exigem API
Rankings precisam de:
atualizações em tempo real
consistência
regras centralizadas
endpoints para leitura e escrita
Se você não tiver API:
o app mobile vai ter que “raspar HTML” (horrível)
o ranking vai ficar inconsistente
você vai ter que reescrever tudo depois
➡️ API‑First deixa o ranking pronto para qualquer front‑end.
🔐 4) Login com Google (Socialite) precisa ser centralizado
Hoje o login funciona no Blade. Mas no app mobile, o fluxo OAuth é diferente.
Se você não tiver API:
você vai duplicar o fluxo OAuth
vai duplicar tokens
vai duplicar refresh
vai duplicar segurança
➡️ API‑First resolve isso com um único fluxo de autenticação.
🧬 5) Você tem IA integrada (Gemini Flash Lite)
O Oráculo precisa ser acessado por:
web
app
talvez até parceiros no futuro
Se você não tiver API:
você vai expor sua chave da IA no front
vai perder segurança
vai ter que reescrever tudo depois
➡️ API‑First protege sua IA e centraliza o uso.
📱 6) O app mobile vai depender 100% de API
Capacitor, Ionic, Flutter, React Native — qualquer um deles precisa de API.
Se você deixar para depois:
você vai ter que reescrever o backend
vai quebrar funcionalidades
vai atrasar o lançamento do app
vai criar inconsistências entre web e mobile
➡️ API‑First agora = app mobile muito mais rápido de desenvolver.
🧨 O que acontece se você NÃO fizer API‑First agora
Você vai cair nesses problemas:
duplicação de lógica
inconsistência de dados
ranking quebrado
XP calculado diferente no app e no web
bugs difíceis de rastrear
retrabalho enorme quando o app chegar
dificuldade de escalar para milhares de usuários
E o pior:
Você vai ter que reescrever o backend inteiro quando decidir lançar o app.
🎯 Resumo rápido (a resposta curta)
Para o seu projeto:
API‑First agora = menos retrabalho, mais escalabilidade, app mobile mais fácil, ranking global mais consistente e um backend mais limpo.
Se você deixar para depois, você vai duplicar lógica, quebrar features e ter que reescrever partes do backend.
🚀 Por que API‑First faz sentido AGORA para o seu projeto
A sua plataforma tem características que tornam API‑First praticamente obrigatória:
🧩 1) Você tem um ecossistema multi‑front (web + futuro app mobile)
Seu webapp atual usa Blade, Alpine e Tailwind. O app mobile (que você já planeja) vai precisar:
login
ranking
missões
XP
streak
relíquias
perfil público
IA do Oráculo
Se você não tiver API:
você vai duplicar lógica
vai duplicar validações
vai duplicar regras de XP
vai duplicar ranking
vai duplicar autenticação
➡️ API‑First evita tudo isso.
🧠 2) Seu produto é um “jogo” — e jogos precisam de backend centralizado
Você tem:
XP
streak
ranking global
ranking semanal
relíquias
missões multi‑etapas
sistema de referral
Aura PRO (premium)
Isso tudo precisa ser consistente entre web e mobile.
Se você deixar o backend “acoplado ao Blade”, você vai sofrer quando o app chegar.
➡️ API‑First garante que tudo isso exista em um único lugar.
🏆 3) Ranking Global e Ranking Semanal exigem API
Rankings precisam de:
atualizações em tempo real
consistência
regras centralizadas
endpoints para leitura e escrita
Se você não tiver API:
o app mobile vai ter que “raspar HTML” (horrível)
o ranking vai ficar inconsistente
você vai ter que reescrever tudo depois
➡️ API‑First deixa o ranking pronto para qualquer front‑end.
🔐 4) Login com Google (Socialite) precisa ser centralizado
Hoje o login funciona no Blade. Mas no app mobile, o fluxo OAuth é diferente.
Se você não tiver API:
você vai duplicar o fluxo OAuth
vai duplicar tokens
vai duplicar refresh
vai duplicar segurança
➡️ API‑First resolve isso com um único fluxo de autenticação.
🧬 5) Você tem IA integrada (Gemini Flash Lite)
O Oráculo precisa ser acessado por:
web
app
talvez até parceiros no futuro
Se você não tiver API:
você vai expor sua chave da IA no front
vai perder segurança
vai ter que reescrever tudo depois
➡️ API‑First protege sua IA e centraliza o uso.
📱 6) O app mobile vai depender 100% de API
Capacitor, Ionic, Flutter, React Native — qualquer um deles precisa de API.
Se você deixar para depois:
você vai ter que reescrever o backend
vai quebrar funcionalidades
vai atrasar o lançamento do app
vai criar inconsistências entre web e mobile
➡️ API‑First agora = app mobile muito mais rápido de desenvolver.
🧨 O que acontece se você NÃO fizer API‑First agora
Você vai cair nesses problemas:
duplicação de lógica
inconsistência de dados
ranking quebrado
XP calculado diferente no app e no web
bugs difíceis de rastrear
retrabalho enorme quando o app chegar
dificuldade de escalar para milhares de usuários
E o pior:
Você vai ter que reescrever o backend inteiro quando decidir lançar o app.
🧠 Minha recomendação clara e objetiva
Para o seu projeto — com gamificação, ranking, IA, login social, premium, multi‑idioma e futuro app mobile — API‑First deve começar AGORA.
Não precisa ser uma API gigante. Comece com:
/auth/login/missions/missions/{id}/complete/ranking/global/ranking/weekly/profile/{username}/oracle/ask/referral/claim
E vá expandindo.
🙏 Encerramento
Então é isso o que eu tinha para escrever por enquanto. Assim que tiver mais novidades, escrevo mais (com a ajuda de IA) Se não tiver nada para escrever, no próximo mês não vai ter nada.
Espero que quem leu tenha gostado.
Comentários
Postar um comentário