Typowy przepływ pracy i struktura projektu AngularJS (z Python Flask)


226

Jestem całkiem nowy w tym całym szaleństwie po stronie klienta MV *. Nie musi to być AngularJS, ale wybrałem to, ponieważ wydaje mi się bardziej naturalne niż Knockout, Ember lub Backbone. W każdym razie, jak wygląda przepływ pracy? Czy ludzie zaczynają od opracowania aplikacji po stronie klienta w AngularJS, a następnie od podłączenia do niej zaplecza?

Lub na odwrót, najpierw budując back-end w Django, Flask, Rails, a następnie dołączając do niego aplikację AngularJS? Czy jest na to „właściwy” sposób, czy może jest to w końcu osobiste preferencje?

Nie jestem również pewien, czy mam skonstruować mój projekt zgodnie z Flask czy AngularJS? praktyki społeczne.

Na przykład aplikacja minitwit Flask ma następującą strukturę:

minitwit
|-- minitwit.py
|-- static
   |-- css, js, images, etc...
`-- templates
   |-- html files and base layout

Aplikacja samouczka AngularJS ma następującą strukturę:

angular-phonecat
|-- app
    `-- css
    `-- img
    `-- js
    `-- lib
    `-- partials
    `-- index.html
|-- scripts
 `-- node.js server and test server files

Mogę sobie wyobrazić samą aplikację Flask i dość łatwo jest zobaczyć samą aplikację AngularJS, taką jak ToDo List, ale jeśli chodzi o korzystanie z obu tych technologii, nie rozumiem, jak one działają razem. Wygląda na to, że nie potrzebuję frameworka po stronie serwera, gdy już masz AngularJS, wystarczy prosty serwer WWW w języku Python. W przykładowej aplikacji AngularJS używają MongoLab do komunikowania się z bazą danych przy użyciu Restful API. Nie było potrzeby posiadania frameworka WWW na zapleczu.

Może jestem po prostu strasznie zdezorientowany, a AngularJS jest niczym więcej niż tylko fantazyjną biblioteką jQuery, więc powinienem używać tak, jak bym używał jQuery w moich projektach Flask (zakładając, że zmienię składnię szablonu AngularJS na coś, co nie koliduje z Jinja2). Mam nadzieję, że moje pytania mają jakiś sens. Pracuję głównie na zapleczu, a ten framework po stronie klienta jest dla mnie nieznanym terytorium.

Odpowiedzi:


171

Zacznę od uporządkowania aplikacji Flask w standardowej strukturze w następujący sposób:

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
|-- templates

Jak wspomniałem btford, jeśli robisz aplikację Angular, powinieneś skoncentrować się na korzystaniu z szablonów Angular po stronie klienta i trzymać się z dala od szablonów po stronie serwera. Użycie render_template ('index.html') spowoduje, że Flask zinterpretuje twoje szablony kątowe jako szablony jinja, więc nie będą renderowane poprawnie. Zamiast tego musisz wykonać następujące czynności:

@app.route("/")
def index():
    return send_file('templates/index.html')

Zauważ, że użycie send_file () oznacza, że ​​pliki będą buforowane, więc możesz zamiast tego użyć make_response (), przynajmniej do programowania:

    return make_response(open('templates/index.html').read())

Następnie zbuduj część AngularJS swojej aplikacji, modyfikując jej strukturę, aby wyglądała następująco:

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
        |-- app.js, controllers.js, etc.
    |-- lib
        |-- angular
            |-- angular.js, etc.
    |-- partials
|-- templates
    |-- index.html

Upewnij się, że twój index.html zawiera AngularJS, a także wszelkie inne pliki:

<script src="static/lib/angular/angular.js"></script>

W tym momencie nie zbudowałeś jeszcze RESTful API, więc możesz mieć swoje kontrolery js zwracające predefiniowane przykładowe dane (tylko tymczasowa konfiguracja). Gdy będziesz gotowy, zaimplementuj interfejs API RESTful i podłącz go do aplikacji kątowej za pomocą angular-resource.js.

EDYCJA: Złożyłem szablon aplikacji, który, choć nieco bardziej złożony niż to, co opisałem powyżej, ilustruje, jak można zbudować aplikację za pomocą AngularJS + Flask, wraz z komunikacją między AngularJS i prostym interfejsem API Flask. Oto, jeśli chcesz to sprawdzić: https://github.com/rxl/angular-flask


1
Natknąłem się na ten problem: kontekst pliku nie został zachowany, gdy próbowałem obsłużyć plik index.html statycznie. Obejrzałem to, przygotowując mój plik statyczny za pomocą app.root_path. W przeciwnym razie jest to całkiem spore miejsce.
Makoto

Czy możesz wyjaśnić więcej o „Zauważ, że użycie send_file () oznacza, że ​​pliki będą buforowane, więc możesz zamiast tego użyć make_response (), przynajmniej do programowania”? Dzięki
nam

Jak zarządzasz kompilacjami, takimi jak używanie chrząstki przy takim podejściu?
Saad Farooq

1
@nam, myślę, że chodzi mu o to, że jeśli podczas debugowania wprowadzasz małe zmiany w js itp., nie zobaczysz efektu w przeglądarce, ponieważ plik send_file buforuje pliki podawane z limitem czasu = SEND_FILE_MAX_AGE_DEFAULT. istnieją sposoby na obejście tego, ale o wiele prostsze jest użycie make_response, dopóki nie będziesz gotowy do wdrożenia.
ars-longa-vita-brevis

@ SaadFarooq Nie omawiam tu chrząkania, ponieważ komplikuje to trochę. Jeśli jesteś gotowy, aby użyć czegoś takiego jak Grunt, sensowne jest posiadanie osobnego repozytorium dla kodu front-end, a następnie spakowanie wszystkiego razem, skopiowanie i wklejenie go do repozytorium Flask lub przekazanie go do CDN i odwołanie do niego z index.html.
Ryan

38

Możesz zacząć na dowolnym końcu.

Masz rację, że prawdopodobnie nie potrzebujesz pełnego frameworku po stronie serwera z AngularJS. Zazwyczaj lepiej jest obsługiwać statyczne pliki HTML / CSS / JavaScript i zapewnić interfejs API RESTful dla zaplecza, aby klient mógł z niego korzystać. Jedną z rzeczy, których prawdopodobnie powinieneś unikać, jest mieszanie szablonów po stronie serwera z szablonami po stronie klienta AngularJS.

Jeśli chcesz używać Flask do obsługi plików (może to być przesada, ale możesz go jednak użyć), skopiujesz zawartość „aplikacji” z „angular-phonecat” do „statycznego” folderu „minitwit”.

AngularJS jest bardziej ukierunkowany na aplikacje podobne do AJAX, natomiast flask daje możliwość robienia zarówno starszych aplikacji internetowych, jak i tworzenia interfejsów API RESTful. Każde podejście ma zalety i wady, więc naprawdę zależy od tego, co chcesz zrobić. Jeśli podasz mi jakieś spostrzeżenia, być może uda mi się sformułować dalsze zalecenia.


26
+1 - ale nie powiedziałbym, że Flask jest ukierunkowany na starsze aplikacje internetowe - zapewnia wszystkich pomocników, których potrzebujesz, aby używać go jako zaplecza internetowego interfejsu API ;-) Istnieje również Flask-Niespokojny, jeśli chcesz być w stanie wygenerować interfejs API obsługujący JSON dla Twojej aplikacji internetowej bardzo łatwo za pomocą Flask-SQLAlchemy - po prostu FYI :-)
Sean Vieira

Słuszna uwaga! Nie znam się szczególnie na Flask; dzięki za dostarczenie specjalistycznej wiedzy na ten temat.
btford,

3
zapoznaj się również z naszym samouczkiem, który pokazuje, jak budować surowe aplikacje z użyciem kątownika i całego zapewnianego przez nas oprzyrządowania: docs.quarejs.org/tutorial
Igor Minar

2
Moim zdaniem wydaje się słuszne umieszczenie folderu „app” z „angular-phonecat” w folderze statycznym. Myślę jednak, że plik index.html powinien zostać umieszczony w folderze szablonów minitwit. Foldery css i img należy przenieść do „statycznego”.
Nezo

22

Ten oficjalny film wideo Jetbrains PyCharm autorstwa Johna Lindquista (angular.js i jetbrains guru) jest dobrym punktem wyjścia, ponieważ pokazuje wzajemne oddziaływanie webservice, bazy danych i angular.js w kolbie.

Buduje klarowny klon z kolbą, sqlalchemy, flask-niespokojną i angular.js w mniej niż 25 minut.

Ciesz się: http://www.youtube.com/watch?v=2geC50roans


17

edycja : Nowy przewodnik po stylu Angular2 sugeruje podobną, jeśli nie tę samą strukturę, o wiele bardziej szczegółowo.

Poniższa odpowiedź dotyczy projektów na dużą skalę. Spędziłem sporo czasu na myśleniu i eksperymentowaniu z kilkoma podejściami, więc mogę połączyć trochę frameworku po stronie serwera (w moim przypadku Flask z App Engine) w celu uzyskania funkcjonalności back-end wraz ze frameworkiem po stronie klienta, takim jak Angular. Obie odpowiedzi są bardzo dobre, ale chciałbym zasugerować nieco inne podejście, które (przynajmniej moim zdaniem) skaluje się w sposób bardziej ludzki.

Kiedy wdrażasz przykład TODO, sprawy są całkiem proste. Kiedy jednak zaczniesz dodawać funkcjonalność i małe ładne szczegóły w celu poprawy komfortu użytkowania, nietrudno zgubić się w chaosie stylów, javascript itp.

Moja aplikacja zaczęła się rozrastać, więc musiałem się cofnąć i przemyśleć. Początkowo podejście takie jak sugerowane powyżej działałoby, łącząc wszystkie style razem i wszystkie JavaScript razem, ale nie jest modułowe i nie jest łatwe do utrzymania.

Co jeśli zorganizujemy kod klienta według funkcji, a nie według typu pliku:

app
|-- server
    |-- controllers
        |-- app.py
    |-- models
        |-- model.py
    |-- templates
        |-- index.html
|-- static
    |-- img
    |-- client
        |-- app.js
        |-- main_style.css
        |-- foo_feature
            |-- controller.js
            |-- directive.js
            |-- service.js
            |-- style.css
            |-- html_file.tpl.html
        |-- bar_feature
            |-- controller.js
            |-- directive.js
            |-- service.js
            |-- style.css
            |-- html_file.tpl.html
    |-- lib
        |-- jquery.js
        |-- angular.js
        |-- ...

i tak dalej.

Jeśli zbudujemy go w ten sposób, możemy owinąć każdy nasz katalog w moduł kątowy. I podzieliliśmy nasze pliki w przyjemny sposób, abyśmy nie musieli przechodzić przez nieistotny kod, gdy pracujemy z określoną funkcją.

Odpowiednio skonfigurowany program uruchamiający zadania, taki jak Grunt , będzie w stanie bez problemu znaleźć, połączyć i skompilować pliki.


1

Inną opcją jest całkowite rozdzielenie tych dwóch.

projekt
| - serwer
| - klient

Pliki związane z kolbą przechodzą do folderu serwera, a pliki związane z angularjs przechodzą do folderu klienta. W ten sposób łatwiej będzie zmienić backend lub front-end. Na przykład możesz chcieć w przyszłości przełączyć się z Flask na Django lub AngularJS na ReactJS.


Kevin: Możesz przejrzeć link, ponieważ prowadzi do strony logowania na Facebooku.
RussellB

0

Uważam, że ważne jest, aby ustalić, na jakim końcu chcesz przetwarzać większość swoich danych - front lub back end.
Jeśli jest to front-end, przejdź do kątowego przepływu pracy, co oznacza, że ​​aplikacja kolby będzie działać bardziej jak interfejs API, w którym kończy się rozszerzenie takie jak rest-rest-restful.

Ale jeśli tak jak ja, wykonujesz większość prac na backendie, to idź ze strukturą kolby i podłącz tylko kątowe (lub w moim przypadku vue.js), aby zbudować przód (jeśli to konieczne)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.