Como usar o Django como Frontend de APIs REST como se fossem modelos nativos do seu Projeto

Na época dos FrontEnds em JS, a minha palestra tem como objetivo demostrar como seria utilizar o próprio Django como Frontend de consumindo uma API Rest usando DRF com vários endpoint e trabalhar como se estivesse usando os modelos nativos no próprio Django.

Transcript

1. Como usar o Django como Frontend de APIs REST como se fossem modelos nativos do seu Projeto
2. MAS O QUE É FRONTEND E BACKEND? Hoje em dia as aplicações estão ficando cada vez mais complexas então se gerou a necessidade de dividir a aplicação na camada de apresentação da camada de negocio e banco de dados. Os termos Frontend e Backend são justamente para diferenciar onde ou em que uma pessoa que programa trabalha
3. ERA ATUAL Estamos passando por varios extremos, onde ainda vemos: • Grandes aplicações monoliticas onde o código do backend e frontend são quase a mesma coisa • Aplicações ainda monoliticas mas com frameworks que separam as camadas (MVC/MVT, etc) • Aplicações separando fisicamente o frontend do backend através de APIs
4. QUAL A MELHOR OPÇÃO? Não existe uma resposta correta para esta pergunta, pois cada uma das opções é a melhor para seus desenvolvedores. Eu recomendo em questão de escalabilidade, para algo grande a 3 opção usando uma API podendo-se ter varias interfaces, mas para algo simples a 2 opção é bem rapida.
5. API? • O acrônimo API que provém do inglês Application Programming Interface (Em português, significa Interface de Programação de Aplicações), trata-se de um conjunto de rotinas e padrões estabelecidos e documentados por uma aplicação A, para que outras aplicações consigam utilizar as funcionalidades desta aplicação A, sem precisar conhecer detalhes da implementação do software. • Desta forma, entendemos que as APIs permitem uma interoperabilidade entre aplicações. Em outras palavras, a comunicação entre aplicações e entre os usuários.
6. Exemplo de API: Twitter Developers
7. O QUE É ESTE TAL DE REST? REST significa Representational State Transfer. Em português, Transferência de Estado Representacional. Trata-se de uma abstração da arquitetura da Web. Resumidamente, o REST consiste em princípios/regras/constraints que, quando seguidas, permitem a criação de um projeto com interfaces bem definidas. Desta forma, permitindo, por exemplo, que aplicações se comuniquem.
8. ORIGEM DO REST • O HTTP é o principal protocolo de comunicação para sistemas Web, existente há mais de 20 anos, e em todo esse tempo sofreu algumas atualizações. Nos anos 2000, um dos principais autores do protocolo HTTP, Roy Fielding, sugeriu, dentre outras coisas, o uso de novos métodos HTTP. Estes métodos visavam resolver problemas relacionados a semântica quando requisições HTTP eram feitas. • Estas sugestões permitiram o uso do HTTP de uma forma muito mais próxima da nossa realidade, dando sentido às requisições HTTP. Para melhor compreensão, veja os exemplos abaixo (requisições em formatos fictícios): • GET - Listar ou Pegar os dados detalhados de um Registro • DELETE Remover um determinado Registro • POST Criar um registro novo
9. VOCE JA TEM UMA API, TEVE PROBLEMAS COM FRAMEWORKS JS E PREFERIRIA CONTINUAR USANDO PYTHON? SEUS PROBLEMAS ACABARAM! VOCÊ PODE FAZER USANDO
10. • Django é um framework para desenvolvimento rápido para web, escrito em Python, que utiliza o padrão model-template-view (MTV). Foi criado originalmente como sistema para gerenciar um site jornalístico na cidade de Lawrence, no Kansas. Tornou-se um projeto de código aberto e foi publicado sob a licença BSD em 2005. O nome Django foi inspirado no músico de jazz Django Reinhardt.[1] Ref: https://pt.wikipedia.org/wiki/Django_(framework_web)
11. LEMBRA QUE EU FALEI DAS OPÇÕES DE USAR API + FRONTEND OU USAR UM FRAMEWORK? Então pensei comigo mesmo. Por que não usar os 2 casos ao mesmo tempo ?
12. A IDEIA DA BILIOTECA Após passar 10 meses trabalhando com indianos e usando ReactJS como frontend vi o quão assustador pode ser um debug em uma aplicação em React por mais que tenha pedido para seguir as boas praticas. Então pensei, vou usar o Django como cliente, mas lembrei que quando trabalhei na Olist, mesmo o front sendo em Django consumindo APIs foi bastante dificil. Então pensei, e se a minha view tivesse o mesmo comportamento com o model que a ela tem com o Model?
13. O DESAFIO Tive de criar uma maneira de acessar multiplos endpoints de maneira simples sem precisar de muito esforço para que ficasse muito simples para um usuário final. Então primeiro eu criei um cliente que mediante a uma lista de endpoints ele gerava automaticamente e para cada endpoint ele gerava outro objeto com os mesmos metodos do REST (Listar, Criar, Atualizar, Detalhar e Remover) e o resultado deveria ser um dicionário ou um objeto
14. AGORA FALTAVA USAR OS CONHECIMENTO EM PYTHON PARA FAZER O PROXY DAS INFORMAÇÕES INTERNAS PARA AS CHAMADAS PARA A API Criei uma estrutura que fosse o mais parecido que o usuário final tem ao usar as Generic View do django, com o mesmo recursos ”bacanudos” de busca e filtro que você tem nas Views do DRF
15. MAS COMO IMPLEMENTAR ?
16. PERGUNTAS ?
17. MATERIAIS Biblioteca: https://github.com/rhenter/django-api-client https://github.com/rhenter/django-api-client (Documentação) Codigo dos exemplos: https://github.com/rhenter/api-client-test-api https://github.com/rhenter/api-client-test-webapp
18. MUITO OBRIGADO POR ME OUVIR ! J Rafael Henter Desenvolvedor e CTO da Supplai Email: rafael@henter.com.br Cell/WhatsApp/Telegram: +55 24 99275-5167