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

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.

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

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.

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

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.

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.

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)