Django para infográficos
1 gostou735 visualizações
O documento discute a implementação de um back-end usando Django para gerar arquivos XML ou JSON que possam ser editados em tempo real, destacando a importância de uma interface amigável para jornalistas. A proposta inclui uma estrutura de CRUD eficiente, utilizando o ORM do Django e o módulo simplejson, para otimizar o gerenciamento de dados e URLs acessíveis. Além disso, aborda a infraestrutura necessária para suportar a aplicação, como servidores, caches e considerações sobre escalabilidade.
Django para infográficos
- 2. Do que precisávamos Precisávamos de um back-end
- 3. Que pudesee gerar arquivos XML ou JSON
- 4. Que pudessem ser editados em tempo-real (ou quase isso)
- 5. Com uma interface jornalista-friendly
- 6. E que pudesse gerar diferentes formatos a partir dos dados que foram colocados lá
- 7. Em resumo... Um CRUD bem feito
- 8. E um BD que cospe uns JSONS e, se não tiver outro jeito, um XML
- 11. Gerando JSON [ { "campeao": 227, "vice": 12, "vice_nome": "Argentina", "ano": 1930, "campeao_nome": "Uruguai", "terceiro_nome": "Estados Unidos", "quarto_nome": "Iugosl\u00e1via", "anfitriao": 227, "anfitriao_nome": "Uruguai", "quarto": 240, "campanhas": [ { "partidas_disputadas": 5, "saldo_de_gols": 8, "disputa_de_penaltis": 0, "gols_feitos": 16, "numero_de_pontos_ganhos": 8, "campanha": 196, "selecao_nome": "Argentina", "cartoes_vermelhos": 0, "selecao": 12, "quartas_de_final": 0, "semifinal": 1, "cartoes_amarelos": 0, "gols_sofridos": 8, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 4, "final": 1, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 1 }, { "partidas_disputadas": 2, "saldo_de_gols": -4, "disputa_de_penaltis": 0, "gols_feitos": 0, "numero_de_pontos_ganhos": 0, "campanha": 205, "selecao_nome": "B\u00e9lgica", "cartoes_vermelhos": 0, "selecao": 21, "quartas_de_final": 0, "semifinal": 0, "cartoes_amarelos": 0, "gols_sofridos": 4, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 0, "final": 0, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 2 }, { "partidas_disputadas": 2, "saldo_de_gols": -8, "disputa_de_penaltis": 0, "gols_feitos": 0, "numero_de_pontos_ganhos": 0, "campanha": 206, "selecao_nome": "Bol\u00edvia", "cartoes_vermelhos": 0, "selecao": 29, "quartas_de_final": 0, "semifinal": 0, "cartoes_amarelos": 0, "gols_sofridos": 8, "derrotas_nos_penaltis": 0, "numero_de_empates": 0, "numero_de_vitorias": 0, "final": 0, "vitorias_nos_penaltis": 0, "numero_de_derrotas": 2 },
- 12. Do que não precisávamos? Gerar os gráficos propriamente ditos Componentes Flash ou JavaScript fariam essa parte
- 13. Ainda que a arquitetura permita fazermos isso, se quisermos muito Servir páginas inteiras em torno dos componentes com dados
- 14. Designers fazem UI melhor do que eu
- 15. Por que Django? O admin
- 16. O ORM
- 18. O mapeamento de URLs
- 19. O framework de testes
- 21. O Admin Jeito declarativo de definir interfaces de manutenção
- 22. Autenticação/autorização embutidas (já fiz um e já chega)
- 23. É o nosso CRUD
- 24. O ORM Fácil de montar queries
- 25. Deixo que ele otimize tudo
- 26. Não escrevo SQL
- 27. Eventualmente, posso mudar de banco para um NoSQL se a performance melhorar alguma coisa (o pessoal do django-nonrel tem feito bom progresso)
- 28. Se precisar muito, posso escrever SQL tunado à mão Mas nunca precisei
- 29. O módulo simplejson simplejson.JSONEncoder(indent = 4).encode({'rotulo': 'meu dado', 'valor': 123})
- 30. Simples assim
- 31. Não é XML (e isso é bom)
- 32. O mapeamento de URLs Permite criar a ilusão de arquivos estáticos
- 33. O cliente não precisa saber o que está acontecendo
- 34. As URLs são bonitas (memorizáveis) A linha (r'^(?P<indicador_slug>[\w\-]*)_datas.json$', views.indicador_datas), Cria URLs como http://servidor/aplicacao/pib_datas.json E ficam amigáveis para caches
- 35. Como ficou 2 servidores Apache com Django
- 36. 1 servidor MySQL
- 37. Quantos caches precisarmos (temos 2)
- 38. … atrás de um balanceador
- 39. Back-end atende até 400 requests por segundo (em cada servidor), mas nunca chega nem perto disso
- 40. BD se sente solitário, sem ter o que fazer
- 41. Caches atendem quase todos os requests
- 42. Tipos de dados Cada tipo de dado pede uma aplicação diferente (no nosso modelo)
- 43. Há aplicações compartilhadas Isso viola um pouco as recomendações oficiais from backend.common.models import Pais, UF Mas resolve nosso problema de dados partilhados
- 44. e compartimenta o acesso aos dados
- 45. Como podemos crescer? Mais caches por backend
- 46. Mais backends
- 47. Replicação no BD
- 48. BDs não relacionais (?)
- 49. Não estamos nem perto dos limites da infra-estrutura
- 50. Alternativas Elastic Search tem sido pesquisado Simples de usar
- 52. … mas não pode cruzar dados e fazer queries complicadas no servidor
- 53. Dúvidas?