Jamstack e o Portal do Desenvolvedor do Azure API Management
Você sabia que o novo Portal do Desenvolvedor do Azure API Management é construído sobre a pilha Jamstack?
Mas antes de mais nada: você já tinha ouvido falar de Jamstack?
Jamstack
Jamstack é uma pilha de tecnologias usada para construir web sites. O nome vem de **JAM Stack** (ou “pilha JAM”), onde o JAM significa Javascript, APIs & Markup.
A ideia por trás do Jamstack é permitir a criação de sites 100% estáticos, onde o HTML é produzido em tempo de compilação a partir da combinação do Markup com dados providos por APIs; em tempo de execução, o conteúdo dinâmico do site vem da interação de código Javascript com um backend composto exclusivamente de APIs.
Ou seja, Jamstack é só um novo nome para SPA?
Não exatamente. Ainda que um site SPA (Single-Page Application) possa ser construído usando-se Jamstack, existem duas distinções importantes a ser fazer aqui:
1 - Jamstack presume um site 100% estático, que possa ser servido a partir de um CDN
Nada, em hipótese alguma, é gerado no servidor em tempo de navegação. Isso significa que a maior parte do conteúdo foi injetada na página em tempo de compilação, deixando a cargo das APIs e do Javascript apenas aquilo que for realmente dinâmico. Com isso, minimiza-se o impacto no desempenho e no SEO.
Já no caso de SPAs, como tipicamente todo o conteúdo vem a partir de frameworks Javascript MVC, MVVM e similares, normalmente a parte estática do HTML é uma casca vazia de conteúdo - o que impacta negativamente o SEO. Por isso, inventaram a ideia da renderização isomórfica - uma técnica que permite rodar no servidor (tipicamente um processo Node.js) o mesmo código Javascript que seria executado no cliente, de forma que ao menos parte do HTML possa ser produzido no server-side para fins de SEO. Dessa forma é preciso ter um servidor Web rodando Node, o que é um no-go para o Jamstack.
Ou seja, enquanto um site SPA normalmente faz renderização isomórfica on-the-fly, um site Jamstack faz algo muito parecido (inclusive consumindo conteúdo de APIs) só que em tempo de compilação. Se você já usou Jekyll, Hugo, Gatsby ou outro gerador de sites estaticos, consegue imaginar facilmente o que estou falando.
2 - SPAs podem ser híbridas
Além disso, há web sites híbridos SPA/MPA, que geram parte de suas páginas usando alguma tecnologia server-side (como ASP.NET Core) e depois complementam o restante do conteúdo e da interatividade usando algum framework JS client-side como Angular.js ou Vue.js. Este cenário, novamente, é um no-go para sites Jamstack.
Entender a filosofia por trás do Jamstack ajuda a entender a arquitetura do novo Portal do Desenvolvedor do Azure API Management, e os impactos nos seus processos de customização, publicação e hospedagem.
O Portal do Desenvolvedor do Azure API Management
Como falamos, o novo Portal do Desenvolvedor do Azure API Management é construído usando Jamstack - mais especificamente, um framework Jamstack chamado Paperbits.
Ao usar o Paperbits, a Microsoft criou uma solução que pode ser facilmente construída e personalizada mesmo por pessoas não-técnicas, usando uma interface gráfica web WYSIWYG bastante simples. Em muitos aspectos, a experiência é muito similar à de várias soluções de CMS disponíveis no mercado. Mas a semelhança acaba aí.
Num CMS tradicional, podemos dividir o processo de criação de páginas em duas fases bem distintas:
- Quando um usuário (um “autor”) cria e personaliza uma página, todas as informações referentes a essa página (dados e metadados) são salvas num banco de dados para uso posterior.
- Depois, quando outro usuário (um “consumidor”) navega pelo site e acessa aquela página, os dados são recuperados do banco de dados, passam por algum tipo de script/template e então o HTML resultante é servido ao usuário (para este exemplo, ignore caches e outras estratégias de otimização).
Já no portal do desenvolvedor do Azure, apenas a primeira parte - a da criação/edição - funciona como num CMS tradicional:
- Quando um usuário (um “autor”) cria e personaliza uma página, todas as informações referentes a essa página (dados e metadados) são salvas num banco de dados para uso posterior. No caso do APIM, esse banco de dados é mantido pelo próprio serviço e é acessível via API (lembra do Jamstack?). Assim, as edições/personalizações são persistidas num banco de dados interno à instância do Azure APIM à qual o portal pertence, exposto por APIs internas do serviço.
- Aqui é que as coisas ficam diferentes: para essa página estar disponível para o usuário, o site precisa ser compilado. Não basta “salvar” as alterações; é preciso publicá-las. Durante a publicação ocorre a compilação, quando os scripts/templates do Azure APIM são combinados com os dados/metadados das páginas persistidos no passo anterior e o HTML resultante é disponibilizado num site estático - o portal do desenvolvedor.
A partir desse momento, o Azure API Management cuida da hospedagem do site para você. Não é preciso fazer mais nada.
Self-hosting
Entretanto, se você quiser, é possível fazer o self-hosting do portal do desenvolvedor. Ele pode ser hospedado em qualquer lugar - numa Azure Storage Account em modo Web Site, num servidor Apache/IIS, num container Docker com NGINX, ou até mesmo num CDN como o Azure CDN.
Normalmente não é necessário fazer o self-hosting - afinal, nada melhor do que poder contar com um serviço 100% ao invés de se preocupar em cuidar de um novo ambiente, mesmo que seja apenas um site estático.
A única razão para fazer self-hosting do portal do desenvolvedor é se você quiser customizar os widgets do Paperbits que vêm por padrão no Azure API Management, ou usar widgets de terceiros.
É parecido com o que acontece com sites Jekyll no GitHub Pages ou sites WordPress no Wordpress.com: Se você quiser usar plugins, vai ter de hospedar seu site por conta própria. Isso porque o processo de build fica dentro do Azure APIM (por trás do botão “Publish website”), e para podermos usar widgets/plugins do Paperbits precisamos assumir a responsabilidade sobre o build - e por extensão o self-hosting.
“Com grandes poderes vêm grandes responsabilidades”
O Portal do Desenvolvedor do Azure API Management é extremamente versátil, flexível e - graças à arquitetura Jamstack - tremendamente escalável. E com a possibilidade do self-hosting, você pode estender a solução até o limite da sua imaginação.
Entretanto, quando trazemos o código para fora precisamos começar a nos preocupar com aspectos de versionamento de código de processo estruturado de build. Por isso, num próximo post iremos falar sobre como gerenciar o portal do desenvolvedor do Azure API Management com o Azure DevOps. Stay tuned!
Um abraço, Igor
14/07/2020 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 6 mins.
