Um exercício prático do Atlas Device SDK para web com sincronização (visualização)
Avalie esse Tutorial
Sumário
- Atlas Device SDK para web com Device Sync e seu uso no mundo real
- Arquitetura
- Componentes básicos
- Construindo seu próprio aplicativo web React
- Etapa 1: configurando o backend
- Etapa 2: Criando um App Services App
- Etapa 3: Preparando-se para o Device Sync
- Etapa 4: Atlas Device SDK
- Etapa 5: Deixe o fluxo de dados (começar a usar a sincronização)!
- Implementação do aplicativo de café
- Uma comparação entre o Atlas Device Sync e o Web SDK sem sincronização
- Como será nosso aplicativo da web sem o Device Sync?
- Qual deles devemos escolher?
- Conclusões
- Apêndice
O recurso Device Sync do Web SDK é uma ferramenta poderosa projetada para levar sincronização de dados em tempo real e recursos automáticos de resolução de conflitos para aplicativos de plataforma cruzada, preenchendo perfeitamente The Gap entre os backends dos usuários e os dados do lado do cliente. Ele facilita a criação de experiências dinâmicas do usuário, garantindo a consistência eventual dos dados entre os aplicativos clientes com sincronização e resolução de conflitos.
No ambiente do mundo real, certos aplicativos cliente se beneficiam de um alto nível de automação, trazendo aos usuários uma interação intuitiva com o aplicativo cliente. Por exemplo, um aplicativo web de contador de consumo de café que permite ao usuário acompanhar as xícaras de café que consome em diferentes dispositivos e calcula dinamicamente a ingestão diária de café criará uma experiência de usuário onipresente.
Neste tutorial, demonstrarei como um desenvolvedor pode habilitar facilmente a sincronização de dispositivos com o aplicativo web de consumo de café mencionado acima. Até o final deste artigo, você será capaz de criar um aplicativo web React que primeiro sincroniza as chávenas de café consumidas durante o dia com o MongoDB Atlas e, em seguida, sincroniza os mesmos dados com diferentes dispositivos que executam o aplicativo. No entanto, nossa jornada não para por aqui. Também mostrarei a diferença entre o Web SDK com sincronização (versão prévia) mencionado acima e o Web SDK sem sincronização automática quando nosso aplicativo precisar sincronizar dados com o back-end do MongoDB. Espero que este artigo também o ajude a fazer uma escolha entre essas duas opções.
Neste tutorial, criaremos duas aplicações web com o mesmo tema: uma calculador de consumo de café. O aplicativo da web que se beneficia do Device Sync será denominado
Coffee app Device Sync, enquanto o que segue o cliente MongoDB tradicional será denominado Coffee app.O aplicativo de café com Device Sync utiliza o Atlas Device Sync para sincronizar dados entre o aplicativo do cliente e o servidor de backend em tempo real, enquanto nosso aplicativo de café sem Device Sync depende do driver MongoDB.
A sincronização de dados depende dos componentes abaixo.
- MongoDB Atlas Application Services: o MongoDB Atlas Application Services e seus MongoDB Atlas Device SDKs são um conjunto de ferramentas de desenvolvimento otimizado para dispositivos de plataforma cruzada, como mobile, IoT e edge, para gerenciar dados por meio do banco de dados de borda do MongoDB chamado Realm, que, por sua vez, aproveita o Atlas Device Sync. Com vários SDKs projetados para diferentes plataformas, o Realm oferece a possibilidade de criar aplicativos baseados em dados para vários dispositivos móveis. O Web SDK que vamos explorar neste artigo é uma das ferramentas úteis que ajudam os desenvolvedores a criar experiências intuitivas de aplicativos da web.
- Autenticação do usuário: Antes de configurar o Atlas Device Sync, precisaremos autenticar um usuário. Em nosso caso específico, por uma questão de simplicidade, o método
anonymousestá sendo usado. Esse procedimento permite que a sincronização do aplicativo cliente seja associada a uma conta de usuário específica em seu App Services App. - Esquema: você pode ver o esquema como a descrição da aparência dos seus dados ou um modelo de dados. O esquema existe tanto no código do seu aplicativo cliente quanto na interface do App Services. Você precisará fornecer o nome dele na configuração.
- Configuração de sincronização: É obrigatório fornecer o usuário autenticado, o modo de sincronização (flexível: true) e
initialSubscriptions, que define uma função que configura as assinaturas iniciais quando o Realm é aberto. - Abrindo um reino sincronizado: Como você verá, usamos
Realm.open(config);para abrir um reino que está sincronizado com o Atlas. Todo o processo entre o aplicativo cliente e o back-end, como você deve ter adivinhado, é interligado pelo Device Sync.
Depois que o Realm for aberto com a configuração que mencionamos acima, quaisquer alterações nos objetos de café no domínio local serão automaticamente sincronizadas com o Atlas. Da mesma forma, as alterações feitas no Atlas são sincronizadas com o domínio local, mantendo os dados atualizados nos dispositivos e no servidor. O que é ainda melhor é que o processo de sincronização de dados ocorre perfeitamente em segundo plano, sem nenhuma ação do usuário envolvida.
Em comparação com o recurso Device Sync, o MongoDB também fornece aos aplicativos da web uma opção alternativa para se comunicar com o back-end. Uma conexão direta com os serviços do MongoDB ( a.k.a.
mongoClient), como opção que discutiremos mais adiante neste artigo, nos fornece uma abordagem semiautomática para realizar operações CRUD.Em resumo, usar
mongoClient para consultar dados dá aos desenvolvedores a liberdade de iniciar operações CRUD em situações projetadas. Por exemplo, você só vai querer que a criação e a exclusão de dados no seu domínio local sejam sincronizadas com o back-end quando o usuário clicar em um determinado botão no seu aplicativo, em vez de sincronizar automaticamente as alterações com o servidor.Para criar um aplicativo da web com o Device Sync, precisaremos de alguns componentes para começar. Classifiquei-os em dois grupos: o front-end e o back-end.
Front-end:
- Um aplicativo web React, como uma interface que conecta o usuário e o backend
Back end:
- MongoDB Atlas, como o armazenamento em nuvem
- Dados (neste artigo, usaremos dados fictícios)
- MongoDB App Services App, como lógica de negócios do aplicativo da web
Esses componentes descrevem brevemente os blocos de construção de um aplicativo web desenvolvido pelo MongoDB App Services. O aplicativo coffee é apenas um exemplo para mostrar como o Device Sync funciona e as possibilidades de os desenvolvedores criarem aplicativos mais complicados.
Nesta seção, fornecerei instruções passo a passo sobre como construir sua própria cópia do aplicativo coffee. No final, você poderá interagir com o Realm e o Device Sync por conta própria.
O MongoDB Atlas é usado como o servidor de backend do aplicativo da web. Essecialmente, o Atlas tem níveis diferentes, de M0 a M700, que representam a diferença no tamanho do armazenamento, no desempenho do servidor de nuvem e nas limitações de baixa a alta. Para obter mais detalhes sobre este tópico,consulte nossa documentação.
Neste tutorial, usaremos o nível gratuito (M0), pois é poderoso o suficiente para fins de aprendizado.
Quando a conta estiver pronta, podemos prosseguir para "Create a Project. "
Você pode ver “Project” como um contêiner, que pode conter vários clusters e também a fonte de dados de qualquer serviço adicional (por exemplo, o App Services usa o Atlas como fonte de dados). O próximo passo é selecionar a camada, o provedor de serviços em nuvem e a região.
Nota: Em ambientes de produção, o M10 e superior são recomendados, embora você possa configurar níveis ainda mais altos definindo opções avançadas de configuração. O site autoexplicativo guiará você em outras etapas, como definir um nome de usuário e senha para seu cluster. Essa será a parte principal para você acessar seu cluster. Depois que o processo de implantação automática for concluído, você verá seu cluster/banco de dados aparecendo como abaixo.
Observação:
Cluster0 é o nome padrão para um cluster recém-criado. Você pode dar qualquer nome ao seu cluster durante o processo de criação.Agora temos um cluster totalmente funcional em funcionamento. Consulte nosso tutorial para obter mais detalhes sobre a criação e configuração de clusters, pois isso não estará no escopo deste artigo.
O App Services (anteriormente chamado de Realm) é um conjunto de ferramentas baseadas na nuvem (ou seja, funções sem servidor, Device Sync, gerenciamento de usuários, regras) projetado para simplificar o desenvolvimento de aplicativos com o Atlas. Em outras palavras, o Atlas funciona como fonte de dados para o App Services.
Nosso aplicativo para café utilizará o Atlas App Services de tal forma que o back-end fornecerá sincronização de dados entre os aplicativos clientes.
Para este tutorial, só precisamos criar um aplicativo vazio. Você pode fazer isso facilmente ignorando todas as recomendações de modelo.
Depois que seu App Services App tiver sido criado, preste atenção aos seguintes itens:
- ID do aplicativo: Esse é um parâmetro exclusivo gerado automaticamente e é necessário para fazer referência ao seu aplicativo em diferentes cenários. Por exemplo, no código do aplicativo Web, você precisará especificar com qual aplicativo o seu código está trabalhando. Na captura de tela abaixo, defini
REALM_APP_IDcomo sendo o App Services App que criei.
- Esquema: O esquema define a aparência dos nossos dados. Em outras palavras, definimos uma estrutura dos dados que armazenaremos no cluster, dispositivos clientes com tipos de dados específicos (string, long, etc.) e se determinadas propriedades são
requiredou opcionais.
Observação: também há duas maneiras de definir o esquema:
- Método 1: Preenchendo documentos no Atlas e definindo esquema a partir da interface do usuário do App Services
- Método 2: Definindo
Object Schemaem seu aplicativo cliente e usando o Modo de desenvolvimento para permitir a configuração de modelos de dados e campos de query do aplicativo cliente
(Usaremos o método 2 para o aplicativo de exemplo. Selecione "Device Sync " no painel do lado esquerdo e ative o Modo de desenvolvimento. Isso permitirá que você defina o esquema no código do aplicativo cliente e, em seguida, aplique-o automaticamente ao backend.)
Por exemplo, vamos definir o esquema do aplicativo café conforme mostrado abaixo.
Como alternativa, a interface do usuário do App Services também fornece uma maneira mais fácil e direta de definir esquema. Selecione a aba "Table View " para alternar entre as visualizações do editor gráfico e JSON. Na exibição de tabela, o App Services preencherá automaticamente o nome do campo dos seus dados e permitirá que você os configure em uma interface gráfica.
Nossa documentação fornece uma explicação muito boa de por que o esquema é um componente obrigatório e importante do Device Sync:
Para utilizar o Atlas Device Sync, você deve definir seu modelo de dados em dois formatos:
- Esquema do App Services: Esse é um esquema do lado do servidor que define seus dados em BSON. O Device Sync usa o esquema do App Services para converter seus dados em documentos do MongoDB, impor a validação e sincronizar dados entre os dispositivos do cliente eo Atlas.
- Esquema de objeto Realm: é um esquema de dados do lado do cliente definido usando os SDKs do Realm. Cada SDK do Realm define o esquema de objetos do Realm em sua própria maneira específica do idioma. Os SDKs do Realm usam esse esquema para armazenar dados no banco de dados do Realm e sincronizar dados com oDevice Sync.
Observação: como você pode ver, o Modo de Desenvolvimento permite que seu aplicativo cliente defina um esquema e o reflita automaticamente no lado do servidor. (De forma simples, o esquema em seu servidor será modificado pelo aplicativo cliente.)
Como você provavelmente já adivinhou, isso tem o potencial de mexer com o esquema do seu aplicativo e causar sérios problemas (ou seja, interromper a sincronização de dispositivos) no ambiente de produção.
Usamos o modo de desenvolvimento apenas para fins de aprendizado e um ambiente de desenvolvimento, portanto, o nome.
Até agora, criamos um App Services App e o configuramos para estar pronto para nosso projeto de aplicativo de café.
Agora estamos prontos para implementar o Device Sync no aplicativo coffee. A sincronização acontece quando os seguintes requisitos são atendidos.
- Os dispositivos cliente estão conectados à rede e têm uma conexão estabelecida com o servidor.
- O cliente tem dados para sincronizar com o servidor e inicia uma sessão de sincronização.
- O cliente envia mensagens IDENT para o servidor. *Você pode ver as mensagens de IDENT como um identificador que o cliente usa para informar ao servidor exatamente qual arquivo de domínio ele precisa sincronizar e o status do domínio do cliente (ou seja, se a versão atual for a versão do servidor sincronizada mais recentemente do domínio do cliente).
O roteiro abaixo mostra o fluxo de trabalho de um aplicativo web com o recurso Device Sync.
Em seguida, vejamos os componentes básicos do Device Sync.
- SDK: um SDK de realm é o que você usará como um conjunto de ferramentas para trabalhar com domínios sincronizados.
- Modelo de dados: Consulte o modelo de dados como uma descrição do objeto de dados que você deseja sincronizar entre um reino sincronizado e seu back-end (Atlas). Os modelos incluem o tipo de objeto para cada objeto e a estrutura do objeto.
Nos bastidores, a sincronização é possível por meio da tradução e da aplicação de alterações entre o domínio local e o back-end. Ao usar o Flexible Sync, somente os dados que você assinar serão sincronizados. 3. Regras e funções: regras e funções permitem que você defina quais dados (regras) sincronizar e a capacidade de cada usuário de ler e gravar dados (funções).
Para ser mais específico, as regras como uma expressão JSON avaliam dinamicamente o documento de entrada e decidem se a entrada pode ser gravada/lida nos dados do objeto armazenados no back-end. As funções avaliam quem tem o direito de executar determinadas ações nos dados (ou seja, leitura/gravação). Ambos podem ser definidos na seção "Rules " da interface do usuário do App Services.
Como exemplo de aplicativo, você pode configurar uma collection para ser
read-only, conforme mostrado abaixo.
Algo que vale a pena mencionar especificamente aqui é o modelo de dados.
Vejamos o exemplo do modelo de dados do aplicativo de café que criaremos. O modelo de dados pode ser dividido em duas partes do ponto de vista de um desenvolvedor: o modelo de dados da aplicação cliente e o esquema do lado do servidor.
A captura de tela acima mostra o esquema de documento do objeto que gostaria de sincronizar, que reside no back-end. O esquema geralmente é gerado automaticamente pelo Atlas App Services. Ele reflete exatamente como o objeto está estruturado e os tipos de dados de cada campo. Dessa forma, precisaremos do modelo de dados correspondente definido no código do aplicativo cliente.
Há duas maneiras de definir os modelos de objetos correspondentes: o modo de desenvolvimento e a interface do usuário do App Services.
- Modo de desenvolvimento: esse modo pode ser ativado na seção "Device Sync " da interface do usuário do Atlas App Services. O que ele faz é permitir que você defina o modelo de dados primeiro no código do aplicativo cliente. Em seguida, o Atlas App Services adotará o mesmo modelo de dados no lado do servidor. Este é um recurso útil para os desenvolvedores criarem o aplicativo e sincronizarem a experiência de uma forma mais intuitiva. Observe que este modo deve ser desativado quando o aplicativo passar para o ambiente de produção.
- Interface do usuário do App Services: como alternativa, a interface do usuário do App Services fornece uma ferramenta muito útil para gerar automaticamente o modelo de dados de acordo com o esquema do documento. Melhor ainda, você pode selecionar a linguagem de programação específica que está usando para o aplicativo cliente, conforme mostrado abaixo.
Com o código do modelo de dados gerado automaticamente, o App Services possibilita a integração fácil desse componente básico ao aplicativo do cliente.
Acima está a situação em que o Device Sync será acionado, juntamente com os componentes mínimos de que precisaremos para fazê-la funcionar.
Apesar das diferenças nas linguagens de programação e funcionalidades, os SDKs compartilham os seguintes pontos em comum:
Apesar das diferenças nas linguagens de programação e funcionalidades, os SDKs compartilham os seguintes pontos em comum:
- Fornecendo uma API de banco de dados principal para criar e trabalhar com bancos de dados locais
- Fornecendo uma API que você precisa conectar a um servidor do Atlas App Services e, portanto, os recursos do lado do servidor, como Atlas Device Sync, funções, Atlas Triggers e autenticação, estarão disponíveis à sua disponibilidade
Implementação:
Sem mais delongas, guiarei você pelo processo de criação do aplicativo do café.
Nosso trabalho aqui está focado nas seguintes partes:
- App.css — ajusta tudo sobre o estilo e a cor da UI
- App.js — autenticação, modelo de dados, lógica de negócios e sincronização
- Footer.js. — adicione informações opcionais sobre o desenvolvedor
- index.css. — adicione fontes e estilos de páginas da web
Como mencionado anteriormente, o React será usado como a biblioteca do nosso aplicativo da web. Abaixo estão algumas opções que você pode seguir para criar o projeto.
Como mencionado anteriormente, o React será usado como a biblioteca do nosso aplicativo da web. Abaixo estão algumas opções que você pode seguir para criar o projeto.
Opção 1 (à moda antiga): Criar um React App (CRA) sempre foi uma maneira de "official " iniciar um projeto React. No entanto, não é mais recomendado nos documentos do React. O aplicativo do café foi originalmente desenvolvido usando o CRA. No entanto, se você vier de uma configuração mais antiga ou apenas quiser ver como o Device Sync é implementado em um aplicativo React, ainda será possível seguir isso.
Opção 2: Vite aborda um problema importante com CRA, o tamanho incômodo da dependência, introduzindo o pré-agrupamento de dependência. Ele fornece desempenho de partida a frio extremamente rápido.
Se você já tem seu projeto criado usando o CRA, também há uma maneira rápida de torná-lo compatível com o Vite usando o código abaixo.
npx nx@latest initA linha acima irá detectar automaticamente a dependência e estrutura do seu projeto e torná-lo compatível com a Vite. Portanto, seu aplicativo também desfrutará do alto desempenho proporcionado pelo Vite.
Nosso aplicativo de exemplo simples tem a maior parte de suas funcionalidades no arquivo
App.js. Portanto, vamos nos concentrar neste e mergulhar nos detalhes.(1) Em termos de dependência, abaixo estão os
importsnecessários.Observe que
realm está sendo importado acima, pois precisamos fazer isso com os arquivos de origem onde precisamos interagir com o banco de dados.(Considere usar o
@realm/react pacote para aproveitar ganchos e provedores para abrir domínios e gerenciar os dados. Consulte o outro aplicativo de exemplo do MongoDB Web Sync Preview para saber como integrar @realm/react.)(2)
Para vincular seu aplicativo de cliente a um aplicativo do App Services, você precisará fornecer a ID do aplicativo dentro do código. O ID do aplicativo é um identificador exclusivo para cada aplicativo do App Services e será necessário como referência ao trabalhar com muitos produtos MongoDB .
Observação: o aplicativo do cliente refere-se ao seu aplicativo web real, enquanto o App Services App refere-se ao aplicativo que criamos na cloud, que reside no servidor do Atlas App Services.
Você pode copiar facilmente sua ID do aplicativo na IU do App Services.
(3) Agora, vamos definir o modelo de dados dentro da nossa aplicação cliente.
Como você pode ver no snippet acima, o modelo de dados
CoffeeSchema é escrito em JavaScript e não parece diferente de qualquer outra variável. No entanto, ele segue o que temos em nosso back-end, conforme mostrado abaixo.
Se isso lhe chama a atenção, você está totalmente correto! Discutimos duas maneiras de definir modelos de dados na seção anterior. Nesse caso, usamos o modelo de dados gerado automaticamente a partir da seção de esquema da interface do usuário do App Services. Como alternativa, sinta-se à vontade para ativar “Development Mode” no painel Device Sync e definir o modelo de dados primeiro em seu aplicativo cliente. O lado do servidor adotará automaticamente o modelo enquanto este modo estiver ativado.
A ressalva aqui é que o modo de desenvolvimento quase nunca deve ser usado em um ambiente de produção por motivos de segurança.
(4) A funcionalidade principal deste aplicativo da web é realizada pelo Realm e seu recurso,
Device Sync. Portanto, vamos primeiro iniciar o Realm.No código acima, também implementamos os seguintes componentes.
credentials: o App Services fornece vários métodos de autenticação (anônimo, e-mail/senha, chaves de API etc.). Por motivos de simplicidade, estamos usandoanonymouscomo o método de autenticação desse aplicativo. Em um ambiente de produção real, o método de autenticação pode ser rapidamente alterado para.apple,.emailPasswordetc., conforme listado na documentação.- Sincronizar
config: No blocosync, fornecemos as informações mostradas abaixo.
user: Transmitindo as credenciais de login do usuário flexible: Definindo qual modo de sincronização o aplicativo usará initialSubscriptions: Definindo as consultas para os dados que precisam ser sincronizados; os dois parâmetros subs erealmse referem às assinaturas da sincronização e à instância do banco dedados local.Agora criamos uma parte crucial que gerencia o modelo de dados usado para sincronização, autenticação, modo de sincronização e assinatura. Esta parte personaliza o processo inicial de sincronização de dados e o adapta para se adequar à lógica de negócios.
(5) Nosso aplicativo de café calcula as xícaras de café que consumimos durante o dia. O aplicativo simples depende de entradas do usuário. Nesse caso, os dados que entram e saem do aplicativo são o número de cafés diferentes que o usuário consome.
A interface do usuário aqui permite que o usuário aumente/diminua as bebidas de café pressionando as teclas
- e +. Podemos construir o componente assim:A matriz de
drinksData exibe name e icon de cada item de café.(6) Agora temos a parte funcional da interface do usuário construída. No entanto, os ícones e botões não farão nada agora. Vamos implementar a lógica por trás de todos esses componentes da interface do usuário.
Criaremos um componente de função chamado
Apps() para inicializar o aplicativo, ouvir as alterações na quantidade de bebidas de café e fazer a limpeza fechando o reino quando não for mais necessário. Aqui está uma visão geral do componente de funçãoApps().Vamos detalhá-lo.
Na primeira inicialização do aplicativo,
useState(null) inicializará a variável realmcom um valornull. Posteriormente, a variável será usada para salvar a instância do banco de dados Realm aberto.A última linha cria um pedaço de estado (
drinksCount) dentro de um componente funcional. Você pode entender drinksCount como uma variável que contém o número atual de bebidas de café, enquanto setDrinksCount é uma função chamada para atualizar o número de drinksCount (também conhecido como estado).No React, descrevemos a estrutura acima como
Hook. O estadodrinksCount é "hooked by" da função setDrinksCount e é atualizado por ela. Quando nosso usuário aumenta/diminui determinadas bebidas de café no menu, essas duas linhas são os heróis em segundo plano.Em seguida, usamos "hook "
useEffect para gerenciar a conexão com nosso domínio local e ouvir as mudanças nas quantidades das bebidas de café.Aviso (1), usamos
mounted para rastrear se o domínio local ainda está ativo e, portanto, o risco de atualizar um domínio fechado pode ser evitado.Observe (2), o "listener" que adicionamos responde às mudanças na quantidade de café local, mas isso não é tudo o que ele faz! Graças à opção de Flexible sync que já definimos no…
... o ouvinte também reage a alterações no servidor. Portanto, podemos garantir que o Device Sync funcione perfeitamente em segundo plano.
Em seguida, vamos criar uma função para atualizar dinamicamente o número das bebidas de café e criar novas, caso essas bebidas ainda não tenham sido criadas no back-end.
Primeiro, verifique se o realm está inicializado.
Em seguida,
write para Realm se a bebida de café específica já tiver sido criada pesquisando o objeto de café que corresponde a drinkName.No entanto, se a bebida de café não tiver sido consumida (criada), vamos criá-la usando
realm.create.Vamos revisar o processo e os componentes implementados em nosso aplicativo de exemplo para utilizar o Realm SDK e seu recurso de sincronização de dispositivos.
Inicialize o reino com o ID do aplicativo
⇣
Abrir um Realm sincronizado
Conforme descrito nas seções anteriores, esta etapa contém todas as configurações, inclusive a configuração de autenticação e sincronização.
⇣
Ouça as mudanças
⇣
Mantenha os dados atualizados
Esta é a viagem de nossos dados, desde a entrada do usuário para o domínio local, enquanto as atualizações de dados são eventualmente sincronizadas com o backend (Atlas) com a ajuda do servidor do Atlas App Services, onde o Atlas App Services fornece serviços como autenticação, Atlas Triggers e funções.
1: Como será nosso aplicativo da web sem o Device Sync?
Para responder a essa pergunta, primeiro, vamos dar uma olhada na implementação alternativa do nosso aplicativo de café.
O aplicativo ainda atualizará as alterações no consumo de café para o back-end. No entanto, agora isso é feito usando a função updateOne(), como mostrado pelo trecho de código abaixo.
Aqui, usamos
upsert para atualizar e inserir os valores alterados de bebidas de café específicas. Como você pode ver, este trecho de código funciona diretamente com documentos armazenados no backend. Em vez de abrir um Realm Mobile Sync com o recurso Device Sync, o aplicativo de café sem o Device Sync ainda usa o Web SDK.No entanto, o método descrito acima também é conhecido como “MongoDB Atlas Client.”. O nome em si é bastante autoexplicativo, pois permite que o aplicativo cliente aproveite os recursos do Atlas e acesse dados diretamente do seu aplicativo.
2: Qual devemos escolher?
Essecialmente, se você deve usar o recurso Atlas Device Sync do Web SDK ou seguir o Atlas mais tradicional depende de seus casos de uso, ambientes de trabalho e base de código existente. Falamos sobre duas maneiras diferentes de manter os dados atualizados entre os aplicativos cliente e o back-end. Embora ambos os aplicativos de exemplo não pareçam muito diferentes devido à sua funcionalidade simples, isso será bem diferente em aplicativos mais complicados.
Observe a UI de ambas as implementações dos aplicativos da web:
Não é difícil descobrir que a forma como o usuário interage com o aplicativo é diferente. A sincronização de dispositivos não exige mais componentes de interface de usuário, como “button”, para interagir com o usuário, enquanto a forma como o usuário interage com o aplicativo usando o Atlas Client parece mais tradicional. Isso requer a interação do usuário com diferentes componentes da interface do usuário, como botões, caixas de seleção etc.
Imagine um aplicativo com funcionalidades e UI muito mais complexas. Se usado adequadamente, o Device Sync tem a capacidade de oferecer uma experiência de usuário completamente diferente em comparação com os dados de atualizações do aplicativo usando o Atlas Client. Por exemplo, um aplicativo de receitas culinárias poderá mostrar ao usuário diferentes produtos acabados com base na quantidade/tipo de ingredientes que o usuário seleciona em tempo real. Sem o Device Sync, o aplicativo ainda terá o mesmo propósito. No entanto, o usuário precisa confirmar suas escolhas manualmente. Isso não será um grande problema, mas o aplicativo perde uma parte da experiência intuitiva do usuário.
Ao fazer uma escolha entre o Atlas Client e o Device Sync do Web SDK, precisamos considerar um aspecto importante, que é as limitações de cada método.
No momento, o Atlas Device Sync do Web SDK está em seu estágio de pré-visualização. Vamos primeiro discutir as limitações do Device Sync na Web.
- Sem persistência: o Web SDK não armazena dados de sincronização no disco local do dispositivo, o que significa que todos os dados locais são armazenados na memória. Lembre-se de que tudo será perdido quando o usuário fechar a guia do navegador ou simplesmente atualizar a página da web.
- Sem suporte a vários threads: por enquanto, todas as operações do Realm precisam ser realizadas no thread principal do aplicativo. Não é possível abrir ou trabalhar com um realm em um thread de trabalhador da web. Essa limitação pode causar uma resposta lenta da interface do usuário, o que leva ainda mais a uma experiência negativa do usuário se não for implementada com cuidado.
Isso não significa necessariamente que o recurso Device Sync do Web SDK seja inferior. Pelo contrário, ao aproveitar a funcionalidade do lado do servidor (ou seja, triggers, funções), podemos manter uma carga de trabalho pesada no servidor do App Services e, ao mesmo tempo, garantir que nosso aplicativo web permaneça responsivo.
- Sem encryption at rest: você pode entender essa limitação, pois o Realm JavaScript Web SDK criptografa apenas os dados em trânsito entre o navegador e o servidor por HTTPS. Tudo o que for salvo na memória do dispositivo será armazenado em formato não criptografado.
No entanto, não há necessidade de entrar em pânico. Como mencionado anteriormente, o Device Sync usa funções e regras para controlar estritamente as permissões de acesso dos usuários a dados diferentes.
Uma limitação do Atlas Client é a forma como os dados são atualizados/baixados entre o cliente e o servidor. Comparado com o Device Sync, o Atlas Client não tem a capacidade de manter os dados sincronizados automaticamente. Isso também pode ser visto como um recurso, em alguns casos de uso, em que os dados só devem ser sincronizados manualmente.
Neste artigo, nós:
- Falou sobre o uso do Web SDK do Atlas App Services em um aplicativo da Web do React.
- Recurso de sincronização de dispositivos do Web SDK comparado com o Atlas Client.
- Discussão sobre qual método devemos escolher.
Os exemplos de código completos estão disponíveis no apêndice abaixo. Você pode usá-los como exemplos ativos do Atlas App Services Web SDK do MongoDB. Como mencionado anteriormente, os aplicativos de café são projetados para serem simples e diretos quando se trata de demonstrar a funcionalidade básica do Web SDK e seu recurso de sincronização. Também é fácil adicionar recursos extras e adaptar o código-fonte do aplicativo de acordo com suas necessidades específicas. Por exemplo:
- Em vez de autenticação anônima, configure ainda mais
credentialspara usar outros métodos de autenticação mais seguros, como e-mail/senha. - Modifique o modelo de dados para se adequar ao tema do seu aplicativo. Por enquanto, nosso aplicativo de café monitora o consumo de café. No entanto, o aplicativo pode ser rapidamente reconstruído em um aplicativo de receitas ou algo semelhante sem modificações e refatoração complicadas.
Como alternativa, os aplicativos de exemplo também podem servir como pontos de partida para seu próprio projeto de aplicativo web.
O Web SDK do MongoDB Atlas Application Services é a resposta do MongoDB para o desenvolvimento de aplicativos web modernos que aproveitam o Realm (um banco de dados local) e o Atlas (uma solução de cloud). O Web SDK agora suporta Atlas Device Sync (em pré-visualização), enquanto antes da versão de pré-visualização o Atlas permitia que aplicativos da web modificassem e manipulassem dados no servidor. Ambas as soluções têm os casos de uso em que são as mais adequadas e não há "right answer" que você precise seguir.
Como desenvolvedor, a melhor escolha pode ser feita primeiro descobrindo a finalidade do aplicativo e como você gostaria que ele interagisse com os usuários. Se você já estiver trabalhando em um projeto existente, é bom verificar se realmente precisa do recurso de sincronização automática em segundo plano (Device Sync), em comparação com o uso de consultas para executar operações CRUD (Atlas Client). Dê uma olhada no nosso aplicativo de exemplo e observe que o arquivo
App.jscontém os componentes básicos necessários para que o Device Sync funcione. Portanto, você poderá decidir se é uma boa ideia integrar o Device Sync ao seu projeto.