Simplificando, o Firebase é um serviço de banco de dados externo. Eles se definem como:
“Um conjunto de serviços de computação em nuvem de back-end e plataformas de desenvolvimento de aplicativos fornecidos pelo Google” para mais informações, verifique aqui: https://firebase.google.com/
Além dos serviços de banco de dados, eles também oferecem serviços de autenticação e integração para vários aplicativos. As aplicações e linguagens de programação suportadas são: Flutter, Dart, C++, Android, IOS, JavaScript , Unity engines e Java.
Por que isso tudo importa? Porque usamos o Firebase no desenvolvimento do nosso aplicativo. Além disso, usamos seu serviço mais popular: o serviço de banco de dados.
Podemos perguntar, por que usar o Firebase? O Firebase é fácil . Ao fazer qualquer tipo de projeto de desenvolvimento que exija que você salve os dados do usuário em alguns formulários, você precisará de um banco de dados. Isso pode ser para armazenar os dados do usuário para análise posterior, modificação de dados, proteção de dados, restauração de dados, etc. Isso se aplica a empresas, indivíduos e organizações, até mesmo a mais grupos também.
Agora que sabemos por que usamos bancos de dados, devemos fazer a próxima pergunta. Quais tipos de banco de dados são melhores para nós?
Vamos explorar essas diferenças. Enquanto fazemos isso, tente adivinhar em qual tipo de banco de dados o Firebase se encaixa ;) .
Bancos de dados centralizados : é quando o banco de dados que está sendo usado para o aplicativo é armazenado em um local onde as pessoas que o usam têm acesso físico direto. Eles também podem editar, melhorar, atualizar e reconstruir o banco de dados da maneira que desejarem. Essencialmente, você tem total propriedade e capacidade de edição do banco de dados em todas as formas físicas, internas e em termos de infraestrutura digital.
Bancos de dados descentralizados : é o completo oposto dos bancos de dados centralizados. Eles são bancos de dados baseados em web3. São bancos de dados onde os dispositivos de armazenamento estão espalhados por diferentes dispositivos computacionais. Somente organizações específicas podem personalizar e melhorar a funcionalidade interna do banco de dados. Seus casos de uso são limitados. Eles são feitos principalmente para aplicativos web3, tokens e para hospedar outros produtos web3.
Para mais informações sobre bancos de dados web3 que os exploram mais detalhadamente, verifique aqui: https://www.makeuseof.com/what-is-web3-storage-how-does-it-work/
DBaaS : esse tipo de banco de dados é geralmente chamado de “sem servidor”. Isso ocorre porque com esse tipo de banco de dados, que é semelhante aos bancos de dados centralizados, você não mantém o banco de dados localmente perto de você. O banco de dados é hospedado por uma empresa terceirizada e eles permitem que você personalize determinada infraestrutura digital de seu banco de dados, mas nada mais. O principal ponto de venda desse banco de dados é a relação custo-benefício. Em vez de perder fundos para criar seu próprio banco de dados centralizado, você opta por terceirizar os esforços. Alguém faz o trabalho sujo de construção e você pode alugá-lo para usar seus serviços de banco de dados. Você obtém funcionalidades diferentes para diferentes níveis de pagamento.
Optei por usar DBaaS. Firebase é um DBaaS. Optei por ele devido à natureza econômica desse modelo de banco de dados.
Estou fazendo um aplicativo. Uma das funções que o aplicativo possui é a capacidade de registrar, entrar e sair dos usuários. Como você pode ver na foto acima, criei um nome de usuário de teste para se inscrever e uma senha de teste. Assim que pressionei o botão “inscrever-se”, o aplicativo enviou as informações para meu banco de dados relevante. O banco de dados sendo hospedado no Firebase. Ao tentar a inscrição, permaneci na mesma página do aplicativo e nada mudou. Depois de verificar os usuários no meu Firebase, nenhum novo usuário foi registrado naquele momento. Isso significa que meu usuário não foi registrado.
Precisamos que nosso aplicativo reconheça novos usuários. Nesta fase, um desenvolvedor examinará seu código e poderá observar a Interface de processamento de aplicativos (API) do Firebase e como a chamou em seu código. Eles também examinarão as variáveis que definem os usuários para garantir que estejam definidas corretamente e que a funcionalidade esteja correta. Eles também podem verificar se algo que interfira ou interaja com a conexão com o banco de dados precisa ser atualizado, como as bibliotecas usadas ou o próprio link da API do Firebase. Pode-se fazer todas essas etapas ou mais para encontrar a solução para o banco de dados ignorando nossas chamadas. Há um problema.
Nada disso se aplica a mim . Porque isto é assim?
A razão pela qual não precisei fazer nenhuma dessas práticas de depuração padrão é porque um pouco antes dessa nova tentativa, consegui registrar novos usuários no banco de dados. Em uma semana, isso parou de repente. Sem alterar nenhum dos meus códigos, o processo que funcionava antes não estava mais funcionando. Isso me confundiu muito e eu repetidamente substituí meu link de chamada de API e o coloquei em diferentes áreas. Organizei minhas chamadas de referência para minhas bibliotecas sendo usadas e minhas diferentes chamadas de arquivo. Até entrei na Internet para saber se o serviço de banco de dados do Firebase estava inoperante. Este não era o caso. Eu estava prestes a iniciar as práticas de depuração padrão... Então finalmente encontrei a solução ! estava em meus e-mails o tempo todo.
Sim, meu e-mail teve a solução todo esse tempo! Ao verificar meu e-mail após dias de estagnação sobre esse problema, encontrei um e-mail de notificação do Firebase. O Firebase me notificou que meu acesso ao banco de dados foi cortado. Isso ocorreu porque, durante a configuração do banco de dados do Firebase, configurei meu acesso ao banco de dados para ser cortado em uma determinada data por motivos de segurança. Eu tinha esquecido essa regra que adicionei para mim. Eu tinha esquecido a data que especifiquei. Como resultado, quando fui cortado, não percebi até verificar meu e-mail. Abaixo podemos ver que configurei o banco de dados para me cortar no dia 12 de março de 2023.
Para corrigir esse problema, eu só precisava atualizar as regras para estender o prazo da minha data limite. Como visto aqui:
Para resolver o problema coloquei o próximo prazo para 29 de junho. Desta forma não terei mais interrupções até esse prazo.
Alguém pode perguntar: “ Por que não definir para daqui a alguns anos ou mais meses, para que você não se preocupe com isso?” boa pergunta. Não farei isso porque quero alguns lembretes trimestrais ao longo do ano para me lembrar dessa dependência. Não quero definir um prazo de longo prazo e depois esquecê-lo novamente e ficar preso na mesma situação um ano depois. Ter isso repetidamente consciente em meu cérebro significa que estou constantemente pensando em todos os fatores que podem afetar o desenvolvimento do aplicativo, o que será útil à medida que continuo o processo de desenvolvimento. Pode-se chamar isso de preferência de aprendizagem.
Podemos ver que o procedimento Firebase Authentication até mesmo retorna um token de id de usuário como o identificador especial do usuário, é assim que sabemos definitivamente que ele está registrado.
O desenvolvimento é divertido, mas sempre temos que estar conscientes das pequenas coisas. Na maioria das vezes, quando há problemas com o aplicativo, é mais provável que seja devido ao nosso próprio erro de código. No entanto, às vezes os problemas podem nem vir do nosso código. Na verdade, pode ser algo tão simples quanto uma atualização necessária ou, como neste caso, uma revisão simples das regras do banco de dados.