Cell CMS — Primeiros Passos
Depois de dois posts só falando de planos, chegou a hora de fazer algo! Do ponto de vista de código poderiamos começar tanto pelo front quanto pelo backend, desde que pensemos bem no que queremos fazer! A tentação de partir direto para o frontend é forte, mas vou começar pelo backend.
O plano para este post é (e já fique o aviso, será um post longo!):
1. Brevemente ver os requisitos do nosso ambiente de desenvolvimento
2. Criar nosso projeto no Visual Studio
3. Criar nosso repositório no GitHub
4. Adicionar Swagger.json e o Swagger UI à API
5. Começar a pensar em qual serviço de Autenticação iremos utilizar
Vamos abrir o Visual Studio e escolher a opção Create a New Project. Nesta tela vamos escolher o item Blank Solution (Solução Vazia) e nomear a solution de cell-cms. Agora você pode me perguntar: “Mas pq diacho estamos fazendo assim!?” e eu te responderei com a seguinte imagem:
Notou onde que, pela imagem, ficam os diretórios da API? Pois é, direto na raiz da solution. Isso não necessariamente é ruim e muitas vezes é mais prático fazer assim. Porém conforme a gente for criando novos projetos na solution (por exemplo para testes unitários, integração, um client Xamarin, etc etc etc) isso vai virar uma zona. E nossa ideia é evitar essa zona ao máximo e assim faremos, criando uma solution vazia primeiro!
Criada nossa solution, vamos para o explorer criar duas novas pastas na raiz da solution: src e tests. A pasta src irá conter nossos projetos, como a API, e a pasta tests irá conter nossos testes! Ainda na raiz, vamos criar dois arquivos: CHANGELOG.md e README.md. Isso mesmo, vamos ter alguma documentação no projeto!
Voltando ao Visual Studio, clique na raiz da solution e escolha Add > New Project, no modal escolha ASP.NET Core Web Application > Next, coloque o nome como CellCms.Api e escolha o diretório \pasta-da-solution\src. Na próxima tela escolha a opção API e, por enquanto, desmarque a opção Enable Docker Support e manda bala no botão Create.
“Mas Rodolpho, a ideia não era usar Docker!? Pq estamos desabilitando a opção!?”
Estamos desabilitando a opção agora pois vamos, no futuro, conversar sobre o que é Docker, para o que serve e como otimiza-lo. Se a gente simplesmente habilitasse agora o visual studio faria boa parte do trabalho por nós e não aprenderiamos tudo que é possível!
Enfim, voltemos à API! Tudo criado bonitinho, hora de inicializarmos o Git! Abra o seu terminal favorito, navegue até a pasta do projeto e use o comando git init para inicializar o git! Isso irá criar um repositório do zero para você, utilizando como base tudo que você fez até aquele momento.
Mas, antes de sairmos fazendo commits, vamos criar um .gitignore decente! Em seu navegador acesse o gitignore.io e escolha “Visual Studio”, “Visual Studio Code”, “CSharp” e “dotenv” para montarmos nosso gitignore.
Caso a preguiça seja grande acesse este link pronto
Feito isso, salve este arquivo na raiz do repositório com o nome .gitignore
O gitignore é uma configuração que torna bem mais fácil ignorar arquivos que não precisam ser versionados como binários, temporários de compilação, arquivos de banco, configurações sensíveis e etc.
Não se esqueça de, agora, voltar ao seu repositório e fazer aquele git add -A e git commit marotos.
Hora de criarmos nosso “cantinho” no GitHub! Acesse o GitHub, faça seu login (ou crie sua conta, caso não tenha ainda!) e no canto direito superior escolha o “+” e a opção New repository. Na nova tela basta preencher o nome, uma descrição e mandar bala, sem segredos aqui.
Anote o comando que o GitHub irá te mostrar, abra seu terminal e utilize o comando git remote para apontar seu repositório local para o GitHub. O comando será algo similar a git remote set-url origin git@github.com:User/UserRepo.git. Configurado o remote, podemos utilizar git push e git pull para baixar e enviar nosso código para o GitHub.
Estamos quase chegando ao código! Mas antes vamos falar sobre o Swagger (atualmente chamado de OpenApi) que é uma maneira de criarmos especificações para as nossas APIs. De maneira que fiquem documentados os retornos, objetos e endpoints disponíveis. Esta especificação será salva em um swagger.json que então pode ser lido por outras ferramentas para criar STUBs ou prover documentação interativa para sua API. Para nosso projeto vamos utilizar o Swagger para gerar a especificação e também o SwaggerUI para disponibilizar uma documentação interativa da API.
Voltando ao Visual Studio, clique no projeto da API e selecione `Manage NuGet packages`. Pesquise por `Swashbuckle.AspNetCore` e clique em `Install`. O Swashbuckle.AspNetCore é um package que nos permite gerar a especificação swagger.json através de anotações em nossos Controllers e, também, visualizar esta documentação através do SwaggerUI. Tudo isso sem ter de desviar a atenção do código do nosso sistema!
Instalado o package, vamos ao código. Na classe Startup.cs faça as seguintes alterações:
Após configurar tudo rode a API, você será recepcionado pela seguinte tela ao acessar https://localhost:5001/:
Nos resta agora discutirmos as soluções de autenticação! Como nosso frontend administrativo será uma SPA (Single Page Application) executando separado da API teremos de utilizar JWT (Json Web Tokens), emitidos por algum servidor/serviço de autenticação.
Poderiamos fazer a nossa própria solução usando um IdentityServer ou um OpenIddict mas ambos criam a necessidade de termos um MVC, seja na API ou em outro projeto. Então, para o Cell CMS, estarei descartando estas alternativas.
Partimos então para as soluções que já existem no mercado e possuem algum tier de gratuidade:
De todas estas minha opção inicial será o Azure Active Directory, por questão de familiariedade com as soluções do Azure. No fim, qualquer provedor que implemente o OpenId Connect poderia ser utilizado!
Por hoje é isso ai pessoal, obrigado por lerem até aqui e abraços! No próximo post vamos configurar a autenticação da API utilizando Azure Active Directory e JWTBearer!
