Algumas notas sobre como começar a usar Django

Olá! Uma das minhas coisas favoritas é começar a aprender uma tecnologia antiga e chata que nunca experimentei antes, mas que existe há mais de 20 anos. É muito bom quando todos os problemas que terei já foram resolvidos 1000 vezes e posso resolver as coisas facilmente.

Há muito tempo que pensei que seria legal aprender um framework web popular como Rails, Django ou Laravel, mas nunca consegui fazer isso acontecer. Mas comecei a aprender Django a fazer um site há alguns meses, tenho gostado até agora, e aqui vão algumas notas rápidas!

menos magia que Rails

Passei algum tempo tentando aprender Rails em 2020 e, embora fosse legal e eu realmente quisesse gostar de Rails (a comunidade Ruby é ótima!), descobri que se deixasse meu projeto Rails sozinho por meses, quando voltasse a ele seria difícil lembrar como fazer qualquer coisa porque (por exemplo) se diz resources :topics em seu routes.rbpor si só, isso não diz onde o topics rotas estão configuradas, você precisa se lembrar ou consultar a convenção.

Ser capaz de abandonar um projeto por meses ou anos e depois voltar a ele é muito importante para mim (é assim que todos os meus projetos funcionam!), e Django parece mais fácil para mim porque as coisas são mais explícitas.

No meu pequeno projeto Django parece que tenho apenas 5 arquivos principais (além dos arquivos de configurações): urls.py, models.py, views.py, admin.pye
tests.pye se eu quiser saber onde está outra coisa (como um modelo HTML), geralmente ela é explicitamente referenciada em um desses arquivos.

um administrador integrado

Para este projeto eu queria ter uma interface administrativa para editar ou visualizar manualmente alguns dados do banco de dados. Django tem uma interface de administração integrada muito boa e posso personalizá-la com apenas um pouco de código.

Por exemplo, aqui está parte de uma de minhas aulas de administração, que configura quais campos exibir na visualização de “lista”, em qual campo pesquisar e como ordená-los por padrão.

@admin.register(Zine)
class ZineAdmin(admin.ModelAdmin):
    list_display = ("name", "publication_date", "free", "slug", "image_preview")
    search_fields = ("name", "slug")
    readonly_fields = ("image_preview")
    ordering = ("-publication_date")

é divertido ter um ORM

No passado minha atitude era “ORMs? Quem precisa deles? Posso simplesmente escrever minhas próprias consultas SQL!”. Eu tenho gostado do ORM do Django até agora e acho legal como o Django usa __ para representar um JOINassim:

Zine.objects
    .exclude(product__order__email_hash=email_hash)

Esta consulta envolve 5 tabelas: zines, zine_products, products, order_productse orders. Para fazer isso funcionar eu só tive que dizer ao Django que existe um ManyToManyField
relacionando “pedidos” e “produtos”, e outro ManyToManyField relacionando “zines” e “produtos”, para que saiba se conectar zines, orders, products.

Eu definitivamente poderia escreva essa consulta, mas escrevendo product__order__email_hash é muito menos digitado, é muito mais fácil de ler e, honestamente, acho que demoraria um pouco para descobrir como construir a consulta (que precisa fazer algumas outras coisas além dessas junções).

Não tenho nenhuma preocupação com o desempenho de minhas consultas geradas por ORM, por isso estou muito animado com os ORMs por enquanto, embora tenha certeza de que eventualmente encontrarei coisas com as quais ficarei frustrado.

migrações automáticas!

A outra grande vantagem do ORM são as migrações!

Se eu adicionar, excluir ou alterar um campo em models.pyo Django irá gerar automaticamente um script de migração como migrations/0006_delete_imageblob.py.

Presumo que poderia editar esses scripts se quisesse, mas até agora estou executando os scripts gerados sem nenhuma alteração e está indo muito bem. Realmente parece mágica.

Estou percebendo que ser capaz de fazer migrações facilmente é importante para mim agora, porque estou mudando meu modelo de dados com bastante frequência enquanto descubro como quero que ele funcione.

Eu gosto dos documentos

Eu tinha o péssimo hábito de nunca ler a documentação, mas tenho gostado muito das partes da documentação do Django que li até agora. Isso não é por acaso: Jacob Kaplan-Moss dá uma palestra na PyCon 2011 sobre a cultura de documentação do Django.

Por exemplo, a introdução aos modelos lista os campos comuns mais importantes que você pode querer definir ao usar o ORM.

usando sqlite

Depois de ter uma experiência ruim tentando operar o Postgres e não conseguir entender o que estava acontecendo, decidi rodar todos os meus pequenos sites com SQLite. Está indo muito melhor e adoro poder fazer backup apenas fazendo um VACUUM INTO e depois copiar o arquivo único resultante.

Tenho seguido estas instruções para usar SQLite com Django em produção.

Acho que tudo bem, porque espero que o site tenha no máximo algumas centenas de gravações por dia, muito menos do que Mess with DNS, que tem muito mais gravações e tem funcionado bem (embora as gravações sejam divididas em 3 bancos de dados SQLite diferentes).

e-mail integrado (e mais)

Django parece ter muito “baterias incluídas”, o que eu adoro – se eu quiser proteção CSRF, ou um Content-Security-Policyou quero enviar e-mail, está tudo aí!

Por exemplo, eu queria salvar os e-mails que o Django envia para um arquivo no modo dev (para que ele não enviasse e-mails reais para pessoas reais), o que era apenas um pouco de configuração.

acabei de colocar isso settings/dev.py:

EMAIL_BACKEND = "django.core.mail.backends.filebased.EmailBackend"
EMAIL_FILE_PATH = BASE_DIR / "emails"

e, em seguida, configure o e-mail de produção como este em settings/production.py

EMAIL_BACKEND = "django.core.mail.backends.smtp.EmailBackend"
EMAIL_HOST = "smtp.whatever.com"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "xxxx"
EMAIL_HOST_PASSWORD = os.getenv('EMAIL_API_KEY')

Isso me fez sentir que, se eu quiser algum outro recurso básico do site, provavelmente já existe uma maneira fácil de fazer isso integrado ao Django.

o arquivo de configurações ainda parece muito

Ainda estou um pouco intimidado pelo settings.py arquivo: O sistema de configurações do Django funciona definindo um monte de variáveis ​​globais em um arquivo, e me sinto um pouco estressado com isso… e se eu cometer um erro de digitação no nome de uma dessas variáveis? Como vou saber? E se eu digitar WSGI_APPLICATOIN = "config.wsgi.application"
em vez de WSGI_APPLICATION?

Acho que me acostumei a ter um servidor de linguagem Python me avisando quando cometi um erro de digitação e agora parece um pouco desorientador quando não posso contar com o suporte do servidor de linguagem.

isso é tudo por agora!

Eu realmente não usei com sucesso uma estrutura da web real para um projeto antes (no momento, quase todos os meus sites são binários Go ou sites estáticos), então estou interessado em ver como funciona!

Ainda há muito o que aprender, ainda não entrei realmente nas ferramentas de validação de formulários ou nos sistemas de autenticação do Django.

Obrigado a Marco Rogers por me convencer a dar uma chance aos ORMs.

(ainda estamos experimentando o sistema de comentários no Mastodon! Aqui estão os comentários no Mastodon! diga-me seu recurso favorito do Django!)