Disclaimer
Esse post é uma tradução de um post de nome parecido feito por mim no blog oficial do MeteorJS com alguns ajustes para se adequar ao público brasileiro. Conhecimento tem sempre que estar disponível. Sempre que possivel, em meu tempo livre, irei estar traduzindo os posts de forma que o público brasileiro tenha esse conhecimento de ponta de forma nativa sobre esse framework que eu me apaixonei e posso estar trabalhando 100% do meu tempo nele.
Venha comigo nessa viagem com MeteorJS.
O que é MeteorJS
Acho que é sempre uma boa dar pelo menos uma relembrada no que é o MeteorJS.
"MeteorJS é um framework fullstack para desenvolvimento de aplicações cross-platform"
Produtividade é algo que o MeteorJS tem em seu coração faz um bom tempo, a ideia de código isomórfico, que faz com que você escreva menos e foque realmente no que importa é simplismente sensacional.
O que é e qual a razão dessa stack?
Caso queira tem o repo onde você poderá acompanhar todas as explicações das decisões técnicas.
Existe uma demo rodando aqui.
O objetivo de qualquer stack é te deixar mais produtivo em alguma tarefa, no caso da CHARM é levar essa produtividade a outro nível. Detalhadamente a stack é composta por:
MeteorJS - Fullstack framework focado em produtividade que usa RPC e Sockets embaixo do capô;
ReactJS - Lib de UI para criação de interfaces web;
Chakra UI - Biblioteca focada em simplicidade e produtividade;
MongoDB - Banco de dados NoSQL para criação de aplicações de maneiras mais práticas e rápidas;
Meteor Cloud - Provedor cloud acoplado a CLI do meteor, fazendo lançamentos de apps de maneira fácil, com bancos de dados incluido.
Como o projeto está estruturado?
Como muitas coisas da vida, o template desse projeto é inspirado nos trabalhos de Alex Kondov: Tao of Node e Tao of React
Muitos apps Meteor são feitos de maneira similar a um monorepo com suas divisões para front e back end declarado respectivamente em ui e api. Você pode ter uma pasta compartilhada para dividir código em sua codebase, como exemplo o front e back utilizarem dos mesmos tipos.
Uma boa pratica que é boa de ser ressaltada é a de organizar suas pastas por funcionalidade do sistema, não por funcionalidade técnica. Pensando sempre nos dóminios de sua aplicação.
Colocaremos tudo que será reutilizado em uma pasta chamada common que indica que ela estará no front e back.
Decisões do backend
Neste template, o banco de dados de escolha é o MongoDB, que é incluso automaticamente quando se cria um projeto MeteorJS. Também foi adicionado pacotes externos para ajudar com algumas rotinas especificas que você poderá encontrar, são eles: simpl-schema andpercolate:migrations. O primeiro para validar objetos e schemas em runtime e o outro para criar migrações no banco de dados.
Migrações do banco de dados
Quer um exemplo de como estruturar suas migrações ?
Use api/db/migration.js como refêrencia
Esse tipo de funcionalidade pode vir a ser útil a depender do tamanho da tua aplicação. Toda vez que o servidor começar, ele rodará o código que está localizado em api/main.js
import { Meteor } from "meteor/meteor";
import { Migrations } from "meteor/percolate:migrations";
import "./db/migrations";
import "./tasks/tasks.methods";
import "./tasks/tasks.publications";
/**
* This is the server-side entry point
*/
Meteor.startup(() => {
Migrations.migrateTo("latest");
});
Ele pega todas as migrações que ainda não foram aplicadas e as roda.
Um bom exemplo de utilização de migrações é quando há mudançãs em como seu banco está estruturado e você gostaria de alterar dados ou ter dados padrão para trabalhar em cima.
Para mais detalhes você pode olhar as docs.
Schemas
Schemas são uma maneira de garantir que os dados que vem de fora de sua aplicação estão conforme você os definiu, limpos e sanitizados.
Optamos pelo uso do simpl-schema e você pode observar seu uso em api/tasks/tasks.collection.js, fazendo isso, todos os dados que passam pelo banco de dados estão validados e seguem nossa estrutura definida.
Não esqueça de olhar as docs em caso de dúvidas.
Conectando-se ao servidor
Mantendo a ideia de ter uma pasta para cada funcionalidade, faremos a mesma coisa para conectar-se ao front-end. Similarmente ao tRPC e Blitz.js usaremos as chamadas remotas que em Meteor tem o nome de Meteor Methods em nosso template algumas chamadas ficam em api/tasks/tasks.methods.js.
/**
* Remove a task.
* @param {{ taskId: String }}
* @throws Will throw an error if user is not logged in or is not the task owner.
*/
export const removeTask = ({ taskId }) => {
checkTaskOwner({ taskId });
TasksCollection.remove(taskId);
};
...
Meteor.methods({
insertTask,
removeTask,
toggleTaskDone,
});
Para chamar esse method teremos de chamar ele por seu nome dessa maneira:
onDelete={taskId => Meteor.call('removeTask', { taskId })}
This sample comes from ui/tasks/TaskItems.jsx.
Decisões do Frontend
React com Meteor é ❤
Para nosso framework de frontend escolhemos o React por sua simplicidade e ecossistema. Meteor tem um pacote para fazer queries usando hooks, deixando você pensar apenas nas soluções que você precisa dar vida. Para mais informações veja o repo do react-meteor-data
O coração da produtividade: Chakra-UI
Para nossos componentes de UI, Escolhemos Chakra-UI pela sua simplicidade e produtividade. Que é comparavél com o que temos em nosso backend com meteor. Criando um fluxo de produtividade inigualável. Está incluso, modo light e dark em nosso template. Para a lista completa de componentes, veja nas docs do Chakra-UI
Ficou interessado?
Depois dessa maravilhosa explicação de nossa stack, espero que tenha vontade de testar e brincar com nosso template. Você pode clicar aqui para ver ele. Se houver alguma dúvida, pode nós mandar mensagem em nossas redes. Não esqueça de dar star no nosso Github também.
Top comments (0)