Cell CMS — Primeiros Passos
Tags: csharp, docker, github, dotnet
Published: 2020-06-24 23:58:02

---
title: Cell CMS — Primeiros Passos
published: true
date: 2020-03-14 14:16:00 UTC
tags: csharp,docker,github,dotnet
series: CellCms
canonical_url: 
---

### 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

Os requisitos que precisamos em nossa máquina são:

- DotNet Core SDK 3.1.101, disponível para download [aqui](https://dotnet.microsoft.com/download)
- Qualquer edição do Visual Studio 2019, disponível para download [aqui](https://visualstudio.microsoft.com/pt-br/downloads/)
- Git, disponível para download [aqui](https://git-scm.com/download/win)

Tudo configurado e pronto? **Então partiu!**

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:

![](https://cdn-images-1.medium.com/max/658/1*-MTvTvdpQdp4rYEGdsuWIA.png)

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!**

![](https://cdn-images-1.medium.com/max/648/1*UJJGBSsk89n_p5Bg1FdsDQ.png)<figcaption>Como o projeto ficaria, eventualmente, se criassemos direto a solution no formato padrão</figcaption>

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**.

![](https://cdn-images-1.medium.com/max/810/1*_F74TexnXOr8jJQD-BHBVg.png)<figcaption>Criando a API</figcaption>

![](https://cdn-images-1.medium.com/max/967/1*xgqIAZ9VpWIRCkj2Jb3V7Q.png)<figcaption>E Escolhendo suas configurações</figcaption>

> “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](http://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](http://gitignore.io/api/dotenv,csharp,visualstudio,visualstudiocode)

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.

![](https://cdn-images-1.medium.com/max/870/1*Zgub-vkN8P3ONPrlvSXb9w.png)<figcaption>Seu terminal deve estar assim agora!</figcaption>

Hora de criarmos nosso “cantinho” no **GitHub**! Acesse o [GitHub](https://github.com), 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.

![](https://cdn-images-1.medium.com/max/806/1*1YYYhFrL5YogyXjz64g_1A.png)<figcaption>Criando o repositório, agora disponível em <a href="https://github.com/rodolphocastro/cell-cms">https://github.com/rodolphocastro/cell-cms</a></figcaption>

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](https://github.com/domaindrivendev/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:

{% gist https://gist.github.com/rodolphocastro/d7d5fd2e0f6118ef893dc80ea7135ba6 %}

Após configurar tudo rode a API, você será recepcionado pela seguinte tela ao acessar **https://localhost:5001/** :

![](https://cdn-images-1.medium.com/max/1024/1*L8pVcBhg1jDv5SCvqyFCKg.png)<figcaption>Swagger UI, pronto para uso!</figcaption>

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](https://github.com/IdentityServer/IdentityServer4) ou um [OpenIddict](https://github.com/openiddict/openiddict-core)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:

- [Auth0](https://auth0.com/)
- [Firebase Auth](https://firebase.google.com/docs/auth/)
- [Okta](https://www.okta.com/)
- [Azure Active Directory](https://azure.microsoft.com/pt-br/services/active-directory/)
- [Azure Active Directory B2C](https://azure.microsoft.com/pt-br/services/active-directory-b2c/)

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**!