[b.....u]

https://dev.to/misiekofski/create-proper-rest-api-with-django-drf-jwt-and-openapi-chp

Pierwszy z cyklu artykuł o #django i #drf, czyli jak napisać porządne API od podstaw w #python.

Chętnie wysłucham uwag ludzi spod #programowanie. Chętnie też opiszę rzeczy, których chcielibyście się dowiedzieć.

[filozof900]

@buntuubuntu: robisz tabele Day ktory ma jedno pole i to jeszcze datetime zamiast date. w profilu dales pole m2m do day przez drinkingday, troche bez sensu. tabela day nie powinna istniec, drinkingday powinien miec klucz obcy do User a Profil nie powinien miec pola days.

zalogowany uzytkownik powinien miec mozliwosc edycji tylko wlasnego profilu, jestes pewny, ze nie mozna edytowac czyjegos profilu? ;-)

zapytanie o profil ( w api) tez powinno uzywac

[b.....u]

@filozof900: modelami zajme się przy okazji drugiego artykułu, a całe repo też będzie dostępne na githubie

[filozof900]

@buntuubuntu: idea jest taka, ze na kazdym etapie program ma dzialac poprawnie i z czasem dodajac nowe funkcjonalnosci masz go tylko rozszerzac, a nie naprawiac. tworzenie nowych tabel to jest ogolnie duza sprawa, bo pozniej migracja to jest na prawde duza sprawa.

niestety widzialem wiele takich projektow (z wyciekiem danych wlasnie bo ktos dodal email do serializera do odczytu, z miksem kluczy do profilu i do usera bo wlasnie ktos

[L.....k]

1. Przy tworzeniu requirementsów możnaby napisać że to rozwiązanie tymczasowe, lecz dość ryzykowne ( ͡° ͜ʖ ͡°)
2. Serio nie rozumiem tendencji rozbijania uzytkownika na "uzytkownika" i "profil". Przecież Djagno oferuje mozliwosc używania wlasnego modelu to uwierzytelniania, dlaczego by nie skorzystać? Czemu ma służyć na struktura?
3. Sygnały to surprise driven development ( ͡° ͜ʖ ͡°)
4. Jeżeli piszesz po angielsku to użyj czegoś pokroju Grammarly do sprawdzenia pisowni, bo kilka rzeczy jest do