Nauka Django pod interview - materiały

Cześć. Pracuję już jakiś czas w Pythonie, ale będę prawdopodobnie aplikował w kierunku pracy z Django, w najbliższym czasie. Ostatnia praca to był Flask, którego wykorzystywaliśmy pobieżnie, a teraz bardziej pure Python. W Django kiedyś robiłem jedynie jakieś mniejsze projekty dla siebie. Stąd też pytanie, jakie materiały polecilibyście, żeby się przygotować pod potencjalny interview w przyszłości, dla osoby która już jakieś doświadczenie ma? Widzę, że wyszedł teraz Django 3.x, a większość materiałów na 2.x niestety z tego co patrzyłem.

Miedzy kolejnymi wersjami Django nie ma az takich duzych roznic, przynajmniej miedzy 2.x i 3.x. Na pewno przeczytaj cala dokumentacje Django, zrob cos w DRFie, przeczytaj Two Scoops of Django (znowu, nie przejmuj sie, ze nie jest o najnowszej wersji), no i 3 razy P - pisz, pisz, pisz :)

Ucz się tak, żeby umieć Django 3 i problem się rozwiąże.

Różnica między 2 a 3 leży głównie w asynchroniczności. TLDR: w większości januszsoftów żadna różnica, jak materiał będzie do d2 zamiast d3 to nic sie nie stanie.

Możesz też pouczyć się na podstawie pytań. Podrzuce ci kilka, które mi się trafiły na różnych rekrutacjach.

1. Distinct w Django model
2. Django middleware - czym jest, gdzie się używa
3. Django - jak wygląda droga requesta
4. Django select related - po co na co dlaczego?
5. Jak działają migracje w Django?
6. Czy makemigrations potrzebuje połączenia z bazą danych?\
7. Czy migrate potrzebuje połączenia z bazą danych?\
8. Czy możliwym jest zaimplementowanie logowania/autentykacji bez sesji?\
9. Różnica pomiędzy Flaskiem a Django
10. Czym jest ORM? Czy django takowy posiada?
11. Jak zrobić unique na kilku polach w django? Da sie?
12. Select for update - co to na co to, o co chodzi?
13. transaction.atomic?
14. Jakiego frameworka standardowo się używa do klepania restowych api w django?
15. path vs url
16. django.conf.settings vs import bezpośrednio settingsów
17. jak stworzyć customową komendę dla manage.py da sie?
18. context processor w django - czym jest?
19. django a document/not-relational dbs typu mongodb. dobry pomysł?

Zdecydowanie lepiej będzie jak napiszesz kilka projektów lub jeden duży niż nauczysz się odpowiedzi. Odpowiedzi wtedy same przyjdą. Może spróbuj jakiś projekt, który może też coś zarobić

Nie idę na rozmowę, ale jestem ciekaw ilu rzeczy zwyczajnie jeszcze nie wiem więc oto moja próba zmierzania się z tymi pytaniami. Gdyby ktoś zauważył w mojej odpowiedzi jakiś błąd lub brak ważnego faktu o jakim nie wspomniałem to niech da znać. Dzięki

**1. Distinct w Django model
**
Dodaje DISTINCT do zapytania, który eleminuje powtórzenia. Jeśli nie podasz konkretnej kolumn/y to odróżnianie potwórzeń polega na sprawdzaniu całego rekordu. W przypadku określenia kolumn sprawdzaniu podlegają wyznaczone kolumny.

**2. Django middleware - czym jest, gdzie się używa
**
To wrappery, które na początku obsługują dany request, a w drodze powrotnej response. Gdy jeden wrapper skończy pracę, wówczas dalej po nim wykonuje pracę kolejny wrapper. Kolejność wywołań jest zdefiniowania w MIDDLEWARE, oczywiście gdy następuje nawrót z response to kolejność wywołań jest odwrotna.

Plusem takiego podejścia jest możliwość wpięcia dodatkowej logiki przed / po pracy widoku. Jest to o tyle lepsze od dekoratorów, że wprowadzona zmiana ma charakter globalny. Jednoczesnie ta zmiana jest wadą, ponieważ wszystkie kolejne requesty muszą się wcześniej przejść przez middleware. Niektóre middleware co prawda mogą przyspieszyć wykonanie kodu, ponieważ mogą przerwać przekazywanie requestu i zwrócić jakiś response z odmową dostępu.

Zastosowania to sterowanie przebiegiem wykonania kodu, rozbudowa response/request o dodatkowe pola, logowanie.

Rzecz jaka mi się nie podoba to fakt, że middlewares jest sterowane przez django. To django powołuje do życia obiekt, w skutek czego nie można po ludzku przekazać zalezności do wybranego middleware.

**3. Django - jak wygląda droga requesta
**
klient np. przeglądarka -> serwer (np. nginx) -> wsgi -> dispatcher -> middlewares -> view (i teraz nawrót z opcjonalnym szablonem + danymi z context procesora)

**4. Django select related - po co na co dlaczego?
**
select_related to sposób na realizację wielu inner joinów w jednym zapytaniu. Dzięki temu możemy uniknąć charakterystycznego dla pracy z ORM problemu N+1. Czyli jak odpytujemy wybrane pole na modelu to ORM nie wykona uderzenia w bazę. Parametry select_related są nieco elastyczne ponieważ pozwalają określić głębokość zapytań czy też wyznaczyć kolumny na jakich ma dojść do złączenia.

**5. Jak działają migracje w Django?
**
Django ma 2 komendy, które idą w parze ze sobą jeśli chodzi o migracje:

makemigrations, która rejestruje zmiany i zapisuje je w pakiecie migrations

jest też migration, która próbuje wykonać niewykonane migrację

Punktem odniesienia dla migracji jest osobna tabelka w bazie w której django rejestruje co zostało zrobione.

**6. Czy makemigrations potrzebuje połączenia z bazą danych?
**
Nie potrzebuje. W komendzie makemigrations django skanuje tylko kod bez udziału bazy.

**7. Czy migrate potrzebuje połączenia z bazą danych?
**
Tak, ponieważ zmiany odnotowane zmiany przez migrations próbuje nanieść na bazę.

**8. Czy możliwym jest zaimplementowanie logowania/autentykacji bez sesji?
**
Wydaje mi się, że nie. Nigdy nie widziałem i nie słyszałem o takim rozwiązaniu.

**9. Różnica pomiędzy Flaskiem a Django
**
Flask to mikroramy, które dają więcej swobody w doborze dodatkowych zależności. Możesz mieć inny orm, język szablonów, sposób na obsługę rest api itp Flask ze względu na swój rozmiar i sposób działania mniej waży i też jest szybszy dlatego też lepiej pasuje do przypadków, gdy backend głównie wystawia API. Flask częściej stosuje się w architekturze mikroserwisów. Natomiast to nie jest tak, że Flask na każdym polu jest lepszy, główna jego słabość to czas developera, który w przypadku małych/średnich projektów musi poświęcić więcej czasu na integracje zależności.

**10. Czym jest ORM? Czy django takowy posiada?
**
Główna korzyść pracy z ORM to dodatkowy poziom abstrakcji. Zamiast myśleć o tabelkach myślimy o klasach, zamiast myśleć o rekordach myślimy o obiektach. W połączeniu z typowaniem zyskuje się większy ład i porządek w kodzie.

Django posiada ORM, konkretnie active rekord, ale ten patent sprawdza się dobrze głównie prostych projektach. Im bardziej złożonych sytuacjach ten ORM bardziej przeszkadza, ponieważ obiekt jest jednocześnie encją i kolekcją. Taka rzecz trochę psuje OOP, a także fakt, że dostęp do pól jest swobodny więc ciężko tutaj o hermetyzacje.

Ostatecznie mam klasy, jest abstrakcja, ale dziurawa i nieszczelna na dodatkowe zmiany.

**11. Jak zrobić unique na kilku polach w django? Da sie?
**
Da się. Każdy modelu może mieć definicję klasy wewnętrznej Meta w której można zadeklarować unique_together. Django samo rozpoznaje czy mamy zamiar nałożyć jeden indeks czy parę. Jednakże czasem warto ocenic czy nie lepiej byłoby unique wymusić poprzez primary key.

**12. Select for update - co to na co to, o co chodzi?
**
Docelowo chcemy przejść z jednego spójnego stanu w bazie w drugi/koleny stan spójny w bazie.

Select for update nakłada exclusive lock na wybrane rekord/y, który uniemożliwia pozostałym wątkom/procesom nakładać blokady, a i też modyfikować/usuwać wybrany rekord, ale też uniemożliwia na kaskadowe usuwanie czy kaskowowe aktualizowanie klucza obcego (jeśli ta zmiana objmuje zablokowany rekord).

W praktyce te locki stosuje się do sytuacji read-modify-write, aby uniknąć race condition.

Na ten temat można wiele pisać, ale najczęstszy błąd z mojego punktu widzenia jaki widzę to fakt, że w transakcjach rzadko kiedy ktoś używa select for share, który po nałożeniu pilnuje aby rekord nie został zmieniony na czas transakcji przez inną transakcję.

Swoją drogą na etapie, gdy w końcu zrozumiałem ile pracy wymaga poprawne zrealizowanie współbieżnych transakcji w postgresql w końcu zrozumiałem gdzie tkwi ukryta moc w bazie datomic.

**13. transaction.atomic?
**
Otwiera nową transakcję z wybranym poziomem izolacji. Transaction.atomic można zagnieżdżać, ale one skutkują utworzeniem savepointa, tzn dla tych zagnieżdżonych transaction.atomic nie można już zmienić poziomu izolacji.

**14. Jakiego frameworka standardowo się używa do klepania restowych api w django?
**
DRF - nie używam, i nie umiem zrozumieć dlaczego ludzie chcą/potrzebują to używać.

**15. path vs url
**
Ja nie widzę jakiejś większej różnicy poza tym, że path ma własną prostszą dla oka notację. Stosujemy predefiniowane nazwy słownie, podczas gdy w url wszystko odbywa się z użyciem wyrażeń regularnych.

**16. django.contrib.settings vs import bezpośrednio settingsów
**
Nie wiem. Nigdy tego nie używałem.

**17. jak stworzyć customową komendę dla manage.py da sie?
**
Da się. Do aplikacji umieszczasz komednę w następującej strukturze: management > commands > nazwa_komendy.py

I w pliku nazwa_komendy.py musisz stworzyć klasę Command, która dziedziczy po BaseCommand.

Praca z klasa jest tutaj odrobine żmudna i u mnie lepiej do obsługi komend sprawdza się biblioteka: https://github.com/GaretJax/django-click

**18. context processor w django - czym jest?
**
Fragment logiki, który na podstawie request dokleja dodatkowy kontekst dla szablonu. Dzięki temu nie trzeba co widok wklejać podobnego kodu.

**19. django a document/not-relational dbs typu mongodb. dobry pomysł?
**
Zależy.

Z nierelacyjnych baz tak w ciemno to często dobrym duetem dla postgresql jest redis (jako cache) lub elasticsearch do optymalnego wyszukiwania.

Natomiast bazy nierelacyjne to tak w dużym stopniu zależy od przypadku. Ze względu, że pytanie dotyczy django dodam, że dla mnie gdy django łaczy się z innymi bazami niż tabelkowymi to traci połowę swojej wartości, ponieważ w django modele, formularze, panel admina są mocno ze sobą powiązane i wciskanie tam innego modelu może się rozmijać z django-way.