A tecnologia móvel que a Couchbase anuncia hoje marca o início de uma transição para os desenvolvedores de aplicativos móveis: longe da pilha LAMP centrada na Web e em direção a uma pilha móvel integrada. Com o JSON Anywhere, os desenvolvedores ficam livres para se concentrar na criação de valor para os usuários, em vez de escrever resmas de código dedicadas a enviar dados entre dispositivos e a nuvem. Nossos engenheiros têm se concentrado na experiência do desenvolvedor desde o início deste projeto, portanto, há muitos detalhes que devem deixá-lo satisfeito, desde Suporte a login social para vinculação de dados ao vivo para o UITableView do iOSMas os dois aspectos que terão o maior impacto na produtividade são a flexibilidade dos esquemas JSON e a sincronização perfeita do JSON com outros dispositivos e com o banco de dados de back-end.
Como muitos desenvolvedores, fui atraído pelo NoSQL pela flexibilidade do JSON como formato de banco de dados. Como você pode adicionar novos campos aos seus documentos a qualquer momento, os desenvolvedores de aplicativos nunca ficam esperando por uma migração de banco de dados. Já houve bastante disse sobre Uso de JSON com práticas de desenvolvimento ágilpor isso não vou repeti-lo aqui. O que é importante sobre o Couchbase Lite é que ele traz o poder e a flexibilidade do JSON para o celular.
O JSON é particularmente valioso para aplicativos móveis, porque muitas vezes é preciso lidar com uma mistura de usuários, alguns executando versões mais antigas do software e outros com a atualização mais recente. Com o uso do JSON, a maioria dos códigos ignora os campos "extras" que não usa. À medida que os usuários atualizam para uma versão mais recente do seu aplicativo, eles podem continuar a interagir com aqueles que ainda estão executando uma versão mais antiga. Os campos usados pela nova versão do aplicativo serão simplesmente ignorados pela versão antiga. Isso permite que os usuários façam a atualização em seu próprio ritmo, em vez de forçá-los a parar o que estão fazendo e fazer a atualização imediatamente. Embora seja possível oferecer suporte a atualizações contínuas com uma arquitetura tradicional, isso exigiria trabalho extra da sua equipe de desenvolvimento de servidores, em vez de ser uma consequência natural do uso de um banco de dados flexível.
Os desenvolvedores de aplicativos estão sempre em busca de ferramentas e técnicas que possam aumentar sua produtividade ou permitir que criem uma experiência melhor para o usuário com menos código. Já vimos essas transições na arquitetura da Web antes: de scripts CGI ad-hoc para servidores de aplicativos gerenciados e de Java para linguagens como Ruby ou JavaScript, que se concentram na felicidade do desenvolvedor. Uma transição como essa só será bem-sucedida se levar a grandes saltos na produtividade do desenvolvedor, que é exatamente o que essas novas plataformas prometem. Quando o Ruby on Rails foi anunciado pela primeira vez, um grande número de desenvolvedores se mudou para lá, na esperança de aproveitar as vantagens de uma nova plataforma de desenvolvimento. oportunidade de arbitragem de produtividade permitindo que eles cobrem menos dos clientes pelo mesmo trabalho e ganhem mais dinheiro com isso do que uma equipe Java comparável.
A sincronização perfeita oferece ainda mais ganhos de produtividade do que a mudança de relacional para JSON. Com uma sincronização tão simples que é mais fácil sincronizar do que criar um backend tradicional de serviços da Web para seu aplicativo móvel, veremos muito mais aplicativos oferecendo aos usuários acesso a seus dados entre dispositivos e sistemas operacionais. A sincronização tem a reputação de ser muito difícil de implementar. Não é preciso procurar muito para encontrar histórias de empresas que dedicaram recursos significativos para criar a sincronização e Mesmo depois de anos de desenvolvimento, eles ainda se deparam com bugs e casos extremos. Não seria justo comparar um aplicativo que usa o Couchbase Lite para sincronizar com o Couchbase Server com o Couchbase Sync Gateway com um aplicativo que criou seu próprio recurso de sincronização personalizado. Qualquer pessoa que crie uma sincronização do zero está embarcando em um processo de vários anos, e chegar ao "hello world" com o Couchbase deve levar apenas alguns minutos.
Embora a sincronização esteja se tornando rapidamente o novo normal, a maioria dos aplicativos móveis colaborativos atuais depende de estar conectada a um servidor em nuvem. Portanto, para sermos justos, compararemos o backend de um de nossos aplicativos de exemplo com o mesmo aplicativo usando um backend Ruby on Rails. Nosso objetivo é criar uma tecnologia que seja um salto de produtividade para os desenvolvedores, assim como o Rails foi em comparação com seus antecessores. Então, vamos pensar nas diferenças entre um aplicativo JSON Anywhere e um aplicativo móvel tradicional com abordagem de serviços da Web.
O código-fonte do backend do nosso aplicativo de exemplo Todo Lite está contido em uma única função JavaScript de 33 linhas. Sua principal responsabilidade é garantir que cada lista de tarefas só possa ser acessada pelas pessoas que o proprietário da lista designou como membros da lista. Ele também é responsável por garantir que cada tarefa seja roteada para os dispositivos que têm acesso à lista associada. Há também algumas linhas de código dedicadas à distribuição de perfis de usuário para alimentar a interface de usuário de compartilhamento. Para uma discussão mais aprofundada de um aplicativo semelhante, você pode acompanhar um tour pelo modelo de dados do nosso aplicativo de bate-papo de exemplo.
Em um aplicativo Rails tradicional de três camadas, você teria modelos correspondentes a usuários, listas e tarefas. Você também pode ter um modelo de "associação" que capture as restrições de acesso. Mas o que mais caracteriza o aplicativo no estilo Rails é que, toda vez que um usuário cria uma tarefa, ativa uma caixa de seleção ou adiciona um novo membro a uma lista de tarefas, o aplicativo móvel faz uma solicitação HTTP ao servidor. O servidor carregará os objetos de modelo apropriados do banco de dados, validará as alterações e salvará de volta no banco de dados. Em seguida, ele precisa notificar todos os outros dispositivos móveis de que a representação do objeto está desatualizada para que eles possam atualizá-la. (Observe que nem sequer começamos a considerar o caso em que os dispositivos móveis estão modificando os dados enquanto estão desconectados...)
Vamos calcular a quantidade de código que você precisaria escrever para criar um aplicativo Rails desse tipo. Estou deixando de fora o material de usuário/login, já que isso normalmente não é escrito como código personalizado para o aplicativo.
- Modelos: tarefa, lista, associação, 10 linhas cada
- Controlador: listas, tarefas, associações, cada uma com GET, PUT e DELETE, 40 linhas cada
- Não são necessários modelos porque estamos retornando JSON.
- Outras 50 linhas de código para lidar com o envio de eventos de atualização para qualquer cliente que esteja ouvindo.
Portanto, o total geral é de cerca de 200 linhas de código Ruby on Rails personalizado necessário para criar um aplicativo de lista de tarefas básico. Isso é quase uma ordem de magnitude a mais de código do que a função Couchbase Sync Gateway usada pelo Todo Lite. O que você prefere escrever e manter? Com a pilha do Couchbase, você não apenas obtém uma sincronização capaz de funcionar off-line, mas seu backend requer muito menos código, liberando-o para dedicar seu tempo à criação de valor onde é importante, nas mãos dos usuários.
