Guia do desenvolvedor para melhorar a estrutura do projeto em aplicativos Meteor

Nos últimos anos, houve um aumento dramático no número de estruturas JavaScript disponíveis. Variando do testado e comprovado AngularJS até a pontuação de frameworks que são lançados todos os meses, há uma diversidade impressionante para escolher. Um que me chamou a atenção há alguns anos é um framework chamado Meteor. Ao contrário da maioria dos frameworks, o Meteor pretende ser uma plataforma completa para o desenvolvimento de aplicativos JavaScript. Para aqueles que são novos no Meteor, encorajo-vos a verificar em seu site. Este artigo não será uma introdução ao Meteor. Em vez disso, exploraremos algumas maneiras simples de introduzir estrutura em projetos Meteor.

Um dos grandes benefícios do Meteor é que é muito fácil prototipar rapidamente aplicativos JavaScript complexos com ele. Como o Meteor é um híbrido de modelagem e renderização de front-end acoplado a um servidor baseado em Node interagindo com o MongoDB (uma solução unificada), a maior parte da configuração inicial necessária para a criação de um aplicativo web full-stack já foi feita para você. No entanto, a facilidade de desenvolvimento que isso proporciona pode ser uma armadilha. É fácil cair em más práticas e acabar com uma confusão de código não estruturado ao construir um aplicativo Meteor. Tenho algumas sugestões de como isso pode ser evitado.

Scaffolding: Hierarquia de diretório gerenciável no Meteor

Primeiro, é importante manter a estrutura de pastas recomendada ao criar seu aplicativo. O Meteor permite que você coloque arquivos em qualquer lugar dentro da pasta do projeto por padrão - você pode até ter todo o seu código em um único arquivo, se desejar. Embora isso possa funcionar para um projeto de hackathon, a complexidade incorrida pelos aplicativos escaláveis ​​de nível de produção usual é difícil de gerenciar sem uma estrutura sólida.

Para resolver esse problema, recomendo verificar o pacote npm de Chris Mather. O pacote tem uma variedade de opções de configuração, então será difícil descrevê-lo aqui, mas em geral ele constrói uma estrutura de projeto que será mais ou menos assim:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

No entanto, para alguns projetos, uma estrutura de pastas e arquivos como essa pode ser um exagero. Nem todo projeto precisará ter esse nível de organização refinado, com separações para coleções, métodos e código de publicação no servidor. Para quem não tem um projeto muito grande ou simplesmente não quer ter que instalar e aprender outro pacote npm, recomendo esta estrutura básica de pastas:

Os elementos-chave são uma pasta pública que contém arquivos como seu favicon e outros ativos estáticos e as pastas cliente, comum e servidor. As pastas do cliente e do servidor devem (é claro) conter o código que é executado no cliente e no servidor, respectivamente. A pasta comum contém código que deve ser acessível ao cliente e ao servidor. Um exemplo disso é o código Schema, que discutiremos em breve.

Existem duas maneiras de realizar o nível mais baixo de organização: uma é por tipo de arquivo e a segunda é por função. Organização por tipo de arquivo significa que em sua pasta cliente/modelos, por exemplo, você terá três pastas - uma para arquivos JavaScript, uma para CSS e outra para HTML. A pasta HTML conterá todos os seus arquivos HTML de modelo, por exemplo Login.html, Main.html e assim por diante. As pastas JavaScript e CSS conterão arquivos de modelo de seu tipo, respectivamente. Organização por função, por outro lado, significa organizar pelo conceito que os arquivos incorporam. Por exemplo, em client/templates, eu teria uma pasta “Login”, com todos os arquivos JavaScript, CSS e HTML associados ao processo de login do aplicativo. Prefiro a organização por função, pois permite que você fique mais claro sobre onde encontrar determinados arquivos ou partes de código. No entanto, não é puramente preto e branco, e a maioria dos indivíduos e equipes encontra uma mistura desses métodos para estruturar seus arquivos e pastas.

Esquema: seu aplicativo precisa mesmo que seu banco de dados não

O segundo tipo de estrutura que gostaria de discutir está associado ao banco de dados. Este artigo pressupõe que você esteja usando o MongoDB. Se você não for, os conceitos provavelmente ainda se aplicarão, mas os detalhes não. Aqueles que usam o MongoDB sabem que ele permite que a maneira como armazenamos nossos dados seja desestruturada. Como o MongoDB é um banco de dados de armazenamento de documentos NoSQL, não há esquema fixo para nenhum “tipo” de dados. Essa liberdade significa que você não precisa se preocupar em garantir que todos os objetos sejam padronizados em alguma forma rígida; na verdade, todos os dados do seu aplicativo podem ser lançados em uma única coleção, se desejar. No entanto, quando se trata de criar aplicativos com qualidade de produção, isso não é tão desejável. Para gerenciar isso e adicionar recursos úteis, como validação de solicitações de gravação, podemos recorrer a dois maravilhosos pacotes Meteor: SimpleSchema e Collection2 de Aldeed.

O pacote SimpleSchema, como o nome sugere, permite validar objetos de forma reativa em seu aplicativo. Confira os documentos no GitHub. O pacote Collection2 inicializa do SimpleSchema e permite que você traga esquemas apropriados para as coleções do Meteor. O que isso permite é a validação automática de solicitações de gravação do lado do cliente e do servidor para qualquer coleção com um esquema anexado a ela. Ambos os pacotes são muito profundos e personalizáveis, por isso é difícil dar uma compreensão completa deles em alguns parágrafos. Em vez disso, eu recomendo que você veja os readmes detalhados que Aldeed compilou para os detalhes. Vou simplesmente falar sobre como tirei valor desses pacotes. Uma das melhores coisas que eles habilitaram foi a validação da entrada do formulário do usuário. Isso é útil para validar documentos do usuário do Meteor (do pacote Accounts). Por padrão, os usuários do Meteor têm um esquema implícito surpreendentemente complexo. Aqui está uma foto de uma parte do código que Aldeed teve a gentileza de disponibilizar:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

Esse é simplesmente o esquema para o objeto de perfil do usuário. Tentar validar todo o objeto User seria uma bagunça sem um pacote específico como SimpleSchema . Embora todos esses campos pareçam opcionais na imagem, se você quisesse um esquema de usuário devidamente validado, eles provavelmente não seriam, e coisas como “Schema.UserCountry” na verdade redirecionam para outros esquemas para validação. Ao anexar esse esquema ao objeto User e integrá-lo de forma reativa aos nossos formulários, talvez com um pacote como o AutoForm de Aldeed, podemos obter um bom grau de controle sobre o que entra e o que não entra em nossos bancos de dados, economizando tempo e esforço com um modelo conceitual de como os dados são tratados em nosso aplicativo que pode ser apontado e discutido em termos concretos.

Funções: Para os 401 e 403s

A última sugestão que tenho para estruturar e melhorar um projeto Meteor é o pacote Roles do Alanning. Este é um sistema de autorização para o Meteor e permite que você verifique os níveis de acesso do usuário para qualquer parte do seu aplicativo da web. As permissões são anexadas ao perfil do usuário na forma de strings que são posteriormente validadas ou invalidadas quando o usuário tenta acessar quaisquer métodos ou dados do Meteor publicados no cliente. Por exemplo:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

Embora o núcleo do sistema seja relativamente simples, ele permite permissões complexas e refinadas para qualquer parte do seu aplicativo. Como todas as funções são armazenadas como strings, você pode configurar um sistema com a profundidade que desejar - “admin”, “admin.division1.manage”, “admin.division1.manage.group2” e assim por diante.

O problema com a liberdade que este pacote permite é que pode ser difícil acompanhar um sistema de funções altamente granular. O pacote fornece funções como “getAllRoles” que, como o nome sugere, recupera todas as funções que você criou, mas cabe a você acompanhar quais são todos os seus significados e quando uma determinada função deve ser usado. E para aqueles que estão curiosos sobre qual é a diferença entre “papéis” e “permissões”, para os propósitos deste pacote eles essencialmente não são diferentes.

Empacotando

Infelizmente, devido à amplitude do artigo (cada um dos pacotes mencionados aqui merece seu próprio tutorial) não foi possível entrar em detalhes sobre nenhum pacote em particular, mas espero ter esclarecido como você pode trabalhar em direção a um “padronizado ” O aplicativo Meteor que você pode ter certeza funcionará bem em produção e em escala. Se você está procurando mais informações, confira os links que postei e dê uma olhada em mais uma coisa que não chegou a este artigo, mas é útil ter em um aplicativo Meteor: o pacote Restivus, que permite para expor facilmente uma API REST para seu aplicativo.

Como isenção de responsabilidade, não sou o autor de nenhum desses pacotes e peço desculpas se deturpei algum dos recursos ou objetivos de qualquer pacote. Obrigado por ler, e espero que este artigo tenha sido útil para você. Sinta-se à vontade para entrar em contato comigo com qualquer dúvida que possa ter, ou deixe um comentário abaixo.