Django, REST i linie kątowe

Question

Próbuję obrócić głowę, łącząc strukturę po stronie klienta, jak AngularJS z Django. Jedną z rzeczy, która naprawdę mnie myli, jest kwestia tras i REST.

Próbowałem dużo przeczytać o tym w Internecie, ale dokumentacja jest ograniczona, zwłaszcza jeśli chodzi o łączenie Django z Angular (małe fragmenty tutaj lub tam). Rozumiem, że muszę dodać strukturę REST taką jak TastyPie, aby stworzyć solidny interfejs REST w mojej aplikacji, aby Angular mógł podłączyć i pobrać zasoby.

Nie jestem jednak pewien, jak właściwie mapować moje trasy w taki sposób, aby (1) moja aplikacja po stronie serwera mogła renderować moją pojedynczą stronę aplikacji (SPA) z kanciastymi podłączonymi (2) trasami które mają ładować szablony informacji/renderowania (kątowe) i pobierać dane z serwera (django) nie powodują konfliktów. Tak jak w przypadku, gdy ktoś odwiedza moją witrynę i robi witrynę site.com/user/1234 - ta trasa jest związana zarówno z trasą Angular, jak i Django - z wyjątkiem jednego, który renderuje szablon, a drugi wypluwa JSON na podstawie danych pobranych z DB/serwer.

Ponadto, korzystając z interfejsu API REST, czy rezygnuję z wielu zalet, jakie mam z punktu widzenia synchronizowania ModelForms z moimi modelami, itp.? Czy jest jakiś sposób, aby to utrzymać z AngularJS lub czy muszę szukać zastępcy AngularJS?

Answer 1

Pytanie nie jest tak naprawdę specyficzne dla Django - tylko kwestia zrozumienia relacji między zapleczem a front-endem w SPA.

Trasy nie są duplikowane między zapleczem a frontendem. Twoje trasy Django powinien być ustawiony tak:

/api/foo 
/api/bar 
... 

i jeden pojedynczy trasa, która dostarcza pojedynczy stronę pełną podszablonów HTML, na przykład

/ 

Pozostałe trasy zostaną zdefiniowane w Angular, np.

/articles/234 
/blog/date/slug 
... 

kątowego kontrolery, które obsługują te drogi publiczne wychodzącym z kolei uczynić $ http nazywa przeciwko URL API i każdy przyniesie jednym kątowym częściową. Nie ma więc powielania, nakładania się.

Do drugiej części twojego pytania możesz nadal używać relacji modelu Django do budowy danych API, ale tak, stracisz całą dobroć Django podczas budowania front-endu.

Jeśli prawidłowo zbudujesz swoje API, wszystkie dane potrzebne w każdym widoku będą w pełni obecne w kanale JSON, który Angular zużywa w tym widoku. Tak więc używasz ORM do budowy danych zaplecza, ale nie możesz po prostu zdecydować się na przechodzenie przez relację modelu w szablonie bez wcześniejszego przygotowania danych zaplecza w celu dostarczenia dla niego danych.

Tak, to zupełnie inny sposób myślenia o rzeczach i tak, jest to trochę bardziej skomplikowane niż robienie prostych Django (lub Railsów). To jest koszt budowy aplikacji internetowej, a nie strony internetowej.