Como organizar o back-end de um aplicativo móvel?

O que estamos fazendo? Serviço de registro e autorização de usuário para um aplicativo móvel

Em projetos para animais de estimação de cada desenvolvedor móvel, mais cedo ou mais tarde, chega um momento em que você precisa, rapidamente e sem muita dor de cabeça, criar um servidor para seu aplicativo. Não importa qual função o servidor deve executar: se é armazenamento de dados ou registro / autorização do usuário.

Como regra, no começo todo mundo segue (bem ou quase tudo) pelo caminho de menor resistência. Estamos procurando uma solução pronta para uso e ver com que rapidez ela pode ser adaptada às nossas necessidades.

Nesta fase, a primeira coisa que você pode "google" são os serviços Firebase, cujos limites gratuitos são mais que suficientes para organizar o back-end de um pequeno aplicativo móvel. Mas, neste caso, considerando exatamente o desenvolvedor russo, corremos o risco de adotar nossa legislação - transferência de dados e armazenamento transfronteiriço de dados pessoais do usuário.

(Lei Federal 152 “Sobre dados pessoais”, artigo 12, capítulo 2) A

tentação de usar o Firebase é grande, mas se queremos nos proteger contra barulho desnecessário com várias agências de supervisão, começamos a procurar opções alternativas.

O próximo estágio é o uso de um servidor VDS com algum tipo de solução de código-fonte aberto ou freemium, em que o "serviço como serviço" ou uma solução pronta para implantar funcionalidade semelhante é tomada como base.

Há vários anos, no Habré, eu já escrevi um guia de configuração detalhado do BaasBox (o artigo foi removido do público devido a informações desatualizadas) em um servidor alugado e dei um exemplo do uso de várias chamadas no aplicativo iOS para a linguagem Objective C. Mas o BaasBox é realmente “pesado” e determina seu mínimo para um servidor alugado. Tendo brincado um pouco com ele, decidiu-se usar uma solução diferente. Naquela época, o servidor Parse foi recentemente colocado em desenvolvimento de código aberto pelo Facebook, não tinha tantos adaptadores quanto atualmente, mas seus recursos eram mais do que suficientes para projetos pessoais e aplicativos de clientes particulares (muitos projetos ainda estão existir e trabalhar de forma estável).

Para ser justo, vale a pena notar que o servidor de análise amadureceu muito e está se desenvolvendo ativamente. No momento, quase todas as funcionalidades disponíveis em um ancestral comercial foram recriadas. Você pode escrever seus próprios ganchos, notificações push localizadas, um gerenciador de processos e até existe uma assinatura para alterar objetos com base em soquetes (ParseLiveQuery - se for interessante, escreverei um artigo separado sobre a configuração do ParseLiveQuery).

Mas o servidor de análise deixou de ser interessante precisamente no momento em que era necessário implementar um tipo de dados não padrão, difícil de trabalhar com base nos tipos definidos no sistema. Isso também interfere no fato de que, por não ser um desenvolvedor de servidor especializado, eu anteriormente não atribuía importância à implantação mais eficiente do ambiente e muitos arquivos de configuração eram feitos à mão, enquanto as ações eram repetidas constantemente em cada novo servidor. É nesse momento que se entende que uma solução em caixa não é uma solução para todos os problemas e você deve prosseguir para o próximo estágio de organização do servidor para um aplicativo móvel.

Recentemente, minha principal linguagem de desenvolvimento é Swift.Portanto, é ele quem me interessa principalmente ao escrever o código do servidor. O Swift em si é fácil de instalar em um sistema unix, mas não oferece vantagens óbvias. Em sua essência, será semelhante ao desenvolvimento de um aplicativo de console com lógica complexa. Levará muito tempo para recriar os métodos básicos necessários no servidor.

Como em muitos outros idiomas, o server swift possui estruturas e comunidades próprias envolvidas no desenvolvimento dessas soluções.

No momento, existem três soluções mais importantes para o desenvolvimento rápido do lado do servidor:

• Perfeito
• Vapor
• Kitura

Existem outras opções, mas elas não valem a pena mencionar por causa de seu longo desenvolvimento e morte.

Em termos de documentação e suporte, gosto mais do Vapor, mas é uma questão de gosto. Outras soluções estarão perto de alguém. De um jeito ou de outro, em muitos momentos eles são semelhantes.

Naturalmente, ao longo do ciclo de artigos em meus exemplos, usarei o Vapor. Com base nisso, implementamos o serviço de registro / autorização do usuário, enviando e confirmando e-mails, a capacidade de redefinir e alterar a senha.



Vale a pena fazer uma implementação sem benefício prático?

Provavelmente não! Portanto, faremos o serviço mais adulto que você pode executar e usar para organizar a lógica para armazenar dados do usuário em seu servidor.

Se a decisão for adulta, isso implica o uso de decisões deliberadas. Devemos simplificar o dimensionamento, implementar a validação de dados e fornecer o armazenamento da sessão do usuário, para não forçá-lo a inserir seu nome de usuário e senha a cada vez.

Do que precisamos para isso?

• VAPOR 4 (sim, ainda em beta, mas o lançamento está chegando, como prometido pelos desenvolvedores)
• PostgreSQL (existe um excelente adaptador para trabalhar com este banco de dados)
• Nginx
• SSL (feche todos os nossos pedidos do cliente para o servidor usando um certificado)
• Localhost (considere o método de desenvolvimento localmente, para não se conectar à rede e trabalhar na estrada sem problemas)

Bem, vamos empacotar tudo isso no Docker para garantir o mesmo trabalho, independente do ambiente de tempo de execução atual.

Honestamente, eu era cético em relação à janela de encaixe de uma só vez, mas deveria ter examinado mais de perto essa tecnologia. O objetivo do artigo não é explicar seu trabalho e aprender a trabalhar com ele (suspeito que eu ainda precise aprender muitos recursos interessantes da janela de encaixe). Mas aqueles que não sabem o que é e como trabalhar com ele podem se familiarizar com o Docker de forma independente por meio do link oficial: www.docker.com

Olhando para o futuro, deixarei um link útil para o aplicativo Kitematic, projetado para simplificar o trabalho com contêineres do docker : kitematic.com (deve ter para quem não gosta de usar o terminal).

Portanto, vamos começar instalando o Docker em um computador Mac: Siga o

link hub.docker.com/editions/community/docker-ce-desktop-mac e faça o download do Get Docker Desktop For Mac (Estável).



Abra a imagem resultante e não instale nada difere da cópia padrão do aplicativo no diretório do programa.



Depois disso, basta iniciar o aplicativo e aguardar a inicialização completa do serviço.



Se ainda não houver um ID do Docker, ele deverá ser criado em hub.docker.com e, se houver, basta fazer login no aplicativo.



Isso é tudo, a preparação para o uso do Docker está concluída. Resta apenas verificar a versão atual e informações sobre o ambiente.

> versão do


docker> informações do docker

Isso conclui a preparação para o desenvolvimento do serviço de autorização. Na próxima parte, veremos como você pode usar contêineres de vários serviços, trataremos do docker-composite para automatizar a montagem do nosso ambiente e começar a escrever código.

PS: Um pequeno conselho da experiência pessoal. Quando desenvolvemos serviços em nossa máquina local, o Docker aloca recursos padrão para nosso uso. Se quisermos visualizar o comportamento esperado do serviço em um servidor remoto, devemos cuidar dos recursos na máquina local, o mais próximo possível das características do servidor. Você pode fazer isso nas configurações do aplicativo Docker Desktop, que baixamos



: Autor do artigo:
Vitaly Podolsky, professor HackerU