django vs flask vs node
Flask i Django to oparte na Pythonie frameworki do tworzenia aplikacji internetowych. Ten samouczek szczegółowo porównuje Django i Flask. Flask vs Node jest również pokrótce omówiony:
Zawsze był to przenikliwy dylemat, jeśli chodzi o wybór ram dla twojego następnego projektu. Co kilka miesięcy widzisz nową technologię i framework, który pokonuje słabość poprzedniej, z której korzystałeś.
Struktura przypomina raczej cichą kulturę i zestaw konwencji, których należy przestrzegać, aby być bardziej stosownymi i produktywnymi w tym ciągle zmieniającym się świecie technologii. Dla porównania, tworzenie stron internetowych przebiega znacznie szybciej niż programowanie na komputery stacjonarne.
=> Przeczytaj całą serię treningów kolb
Czego się nauczysz:
Django Vs Flask
W tym samouczku szczegółowo porównamy Django i Flask. Flask i Django to oparte na Pythonie frameworki do tworzenia aplikacji internetowych. Wiele z nich zmierza w kierunku lekkich mikrowłókien. Te struktury są elastyczne, elastyczne, małe i pomagają w tworzeniu mikrousług i aplikacji bezserwerowych.
Biorąc pod uwagę popularność NodeJS, zapewniliśmy również cudowne porównanie między Flask i Node w sekcji Flask vs. Node. Ocena Django i Flask pod kątem następujących funkcji pomoże ci wybrać jedną z nich.
Administrator domyślny
Obie struktury zapewniają rozruchową aplikację administracyjną. W Django jest to wbudowane i dostarczane z domyślną instalacją. Jednak w przypadku Flaska musisz zainstalować Flask-Appbuilder, aby mieć interfejs administratora.
W międzyczasie pamiętaj o utworzeniu superużytkownika w Django i administratora w przypadku Flaska, abyś mógł zalogować się do zaplecza administracyjnego za pomocą przeglądarki.
Bazy danych i ORMS
Django jest dostarczane z domyślnym wbudowanym ORM, który wprost obsługuje interakcję z RDBMS, takimi jak Oracle, MySQL, PostgreSQL, SQLite itp. Ten ORM obsługuje również generowanie i zarządzanie migracjami. Tworzenie modeli baz danych z wbudowanymi walidacjami jest stosunkowo wygodniejsze.
Flask również nie narzuca żadnej konkretnej metody i jest dostępny do użycia z różnymi rozszerzeniami, które obsługują podobne funkcje, jak opisano w przypadku Django. Podaliśmy przykłady Flask-SQLAlchemy, Flask-Migrate, Flask-MongoEngine w jednym z samouczków z tej serii.
Widoki i trasy
Obie struktury mają mechanizmy deklarowania widoków opartych na metodach i klasach. W przypadku Django trasy i widoki są wymienione w osobnych plikach. Ponadto zawsze musimy jawnie przekazać obiekt żądania.
Z drugiej strony w Flasku możemy użyć dekoratora, aby wspomnieć o trasach odpowiednich handlerów. Obiekt żądania w Flask jest globalny i jest po prostu dostępny bez żadnego jawnego przekazywania. W jednym z naszych samouczków szczegółowo omówiliśmy koncepcje korzystania z widoków i tras.
Formularze i szablony
Formularze Django są wbudowane w framework i nie wymagają instalacji. Formularze są dość istotne dla aplikacji, aw Django można je przekazywać do tagów szablonów i można je renderować w szablonach. Jednak w przypadku Flaska musimy użyć Flask-WTF.
Korzystaliśmy również z Flask-Appbuilder do tworzenia formularzy. Ponadto WTF-Alembic może służyć do generowania formularzy HTML na podstawie modeli bazodanowych.
Oba frameworki obsługują szablony Jinja2 i oba obsługują obsługę plików statycznych z wbudowanymi funkcjami do generowania adresów URL zasobów i są obecnie dość powszechnym wzorcem we wszystkich frameworkach.
Chociaż istnieją różne sposoby przekazywania zmiennych i renderowania szablonów w ich określonych metodach widoku, obie struktury mają tę samą składnię dostępu do zmiennych w szablonach.
Elastyczność
Django, ze względu na swój rozmiar i złożoność, jest mniej elastyczne niż Flask. Flask można łatwo rozszerzyć za pomocą wielu rozszerzeń, które obsługuje. Dlatego skonfigurowanie Flaska wymaga więcej czasu i wysiłku, ponieważ musimy ocenić więcej rozszerzeń.
Swoboda przyznana programistom w pewnym sensie skutkuje wolniejszym rozwojem i dostarczaniem. Z drugiej strony, Django kieruje się zestawem już ustalonych konwencji i podąża za archetypami, które wymagają mniejszego odchylenia od celów projektu.
Krzywa uczenia się
Prawie tyle samo czasu potrzeba na nauczenie się zarówno Django, jak i Flaska. Flask ma mniejsze API; w związku z tym ludzie mogą być w stanie ukończyć go szybciej, jeśli chodzi o podstawowy szkielet. Równie trudne staje się korzystanie z jego rozszerzeń. Wkrótce może się to stać uciążliwe.
Jednak tylko dlatego, że wszystko nie jest zapakowane w jednym opakowaniu, łatwiej jest przećwiczyć rozdzielanie problemów w przypadku frameworka Flask.
Zalecamy poznanie wzorców, a nie stosowanej składni. Zarówno Django, jak i Flask mają doskonałą dokumentację. Możesz go łatwo śledzić podczas tworzenia funkcji.
Rozmiar i czas trwania projektu
Kiedy pracujesz nad większym projektem z większymi zespołami, lepiej jest skorzystać z dojrzałości Django i szerokiego wsparcia ze strony współpracowników. Jeśli Twój projekt jest mniejszy i wymaga mniejszej liczby programistów, lepiej wybrać Flask.
Co więcej, jeśli Twój projekt będzie trwał długo, Django jest właściwym wyborem; w przeciwnym razie możesz wybrać Flask.
typ aplikacji
Wcześniej Django uważano za właściwy wybór, gdy istniało zapotrzebowanie na pełnoprawne aplikacje internetowe na skalę korporacyjną. Ale dziś Flask jest równie dojrzały i może dobrze służyć w tych samych warunkach.
Jednak programiści zwykle wybierają Flask bardziej do tworzenia małych lub statycznych witryn internetowych lub podczas wdrażania szybkich usług internetowych API zgodnych z REST.
Rekrutacja programistów
Posiadanie wykwalifikowanych zasobów w konwencji używanego przez Ciebie frameworka się opłaca. Możesz spodziewać się szybszego rozwoju, szybszego testowania, szybszej dostawy i szybszych napraw błędów.
W przypadku Flaska dość łatwo jest znaleźć nowych programistów. Jednak znalezienie wykwalifikowanych zasobów w Django jest trudne. Niewiele jest gotowych do zatrudnienia programistów Django. Co więcej, framework Django jest dość stary, a zatem większość nowych pracowników jest kosztowna w porównaniu do tych, którzy są biegli we frameworku Flask.
Nowi absolwenci kierunków technicznych również wybierają lekkie frameworki, takie jak Flask, ponieważ trendy branżowe zmierzają w kierunku tworzenia aplikacji z oddzielonymi mikrousługami lub technologią obsługującą tworzenie implementacji bezserwerowej. Javascript jest szeroko stosowany wraz ze strukturami, które są łatwiejsze w użyciu i są bardziej popularne.
Otwarte źródło
Zarówno Flask, jak i Django są projektami open source. Możesz znaleźć Django na https://github.com/django/django i Flask na https://github.com/pallets/flask. Patrząc na te projekty, liczba współtwórców Django jest znacznie większa niż tych, którzy wnoszą wkład do Flaska.
Dlatego możemy spodziewać się większej i szybszej pomocy, jeśli mamy jakieś problemy i pytania, które wymagają rozwiązania. Wbrew typowym założeniom liczba użytkowników projektu Flask jest wyższa niż Django.
Jednym z niepokojących faktów dotyczących Flask jest to, że może nie istnieć stabilne rozszerzenie dla określonego zadania. Dlatego praca polegająca na odfiltrowaniu najlepszego pozostaje po stronie użytkownika rozszerzenia.
Na przykład, użyliśmy Flask-Twitter-oembedder do pracy z API Twittera w ostatnim samouczku, ale to rozszerzenie miało pewne problemy, z powodu których musieliśmy przełączyć się z Flask-Cache na Flask-Caching.
Musieliśmy nawet dołączyć niestandardową instrukcję instalacji, aby zainstalować Flask-twitter-oembedder z naszego zaktualizowanego repozytorium Github, zamiast wspominać o tym w naszym pliku requrements.txt projektu.
Częsta konserwacja to typowe wyzwanie, z którym będziesz musiał się zmierzyć w projekcie open source. Wsparcie i zarządzanie projektem open source są zwykle powiązane z płatnymi usługami. Być może będziesz musiał długo czekać, aby naprawić kilka problemów od współtwórców projektu.
Występ
Framework Flask jest lżejszy niż Django i działa lepiej z pomijalnymi różnicami, szczególnie biorąc pod uwagę operacje we / wy.
Spójrz na poniższe porównania. Wraz ze wzrostem liczby żądań wydajność Flaska pozostaje prawie taka sama. Jednak Django potrzebuje więcej czasu na renderowanie szablonów po pobraniu danych przy użyciu ORM.
Python Flask Vs Django: porównanie tabelaryczne
| # | funkcje | Django | Kolba |
|---|---|---|---|
| 7 | Zmienna interpolacja w szablonach | W szablonach / demo.html {{tempvar}} | W szablonach / demo.html {{tempvar}} |
| jeden | Administrator domyślny | Wbudowane zaplecze administracyjne | Zainstaluj Flask-Appbuilder |
| dwa | Włącz domyślnego administratora | W settings.py upewnij się, że odkomentowałeś aplikację zainstalowaną przez administratora. ... # Definicja aplikacji INSTALLED_APPS = ( 'stronie internetowej', 'django.contrib.admin', # inny kod ) ... | Zaimportuj AppBuilder i SQLA z flask_appbuilder, zainicjuj najpierw bazę danych, a następnie Appbuilder import z kolby Flask z flask_appbuilder import AppBuilder, SQLA app = Flask (__ name__) db = SQLA (aplikacja) appbuilder = AppBuilder (aplikacja, db.session) |
| 3 | Utwórz administratora | python manage.py createduperuser | flask fab create-admin |
| 4 | Bazy danych i ORMS | Wbudowany ORM dla RDBMS Użyj Django-nonrel dla backendów NoSQL | Zainstaluj Flask-SQLAlchemy Specyficzne dla NoSQL rozszerzenie Flask, takie jak Flask-MongoEngine |
| 5 | Widoki i trasy | URLConf w urls.py ze ścieżki importu django.urls z widoków .import urlpatterns = ( ścieżka („/ ścieżka”, views.handler_method), # inne adresy URL i programy obsługi ) | Użyj dekoratora @ app.route („/ path”) w Widokach, aby zmapować trasę z funkcją. @ app.route („/ ścieżka”) def handler_method (): # inny kod z dalszą logiką |
| 6 | Szablony renderowania | W widokach z django.shortcuts import render def example_view (żądanie): tempvar = ”value_for_template” return render ( żądanie, „Demo.html”, {'Tempvar': tempvar} ) | W widokach od . import aplikacji z żądania importu kolby import z kolby render_template @ app.route („/ ścieżka”) def demo (): tempvar = ”value_for_template” return render_template ( „Demo.html”, temp_var = temp_var ) |
| 8 | Elastyczność | Mniej elastyczne | Bardziej elastyczne |
| 9 | Decyzje projektowe | Mniej decyzji projektowych z programistami. | Więcej swobody dla programistów. |
| 10 | Odchylenie projektu | Mniejsze odchylenie od celów projektu. | Więcej odchyleń ze względu na swobodę przyznaną programistom. |
| jedenaście | Rozmiar bazy kodu | Większa baza kodu | Mniejsza baza kodu |
| 12 | Liczba interfejsów API | Więcej interfejsów API | Mniej API |
| 13 | typ aplikacji | Pełnoprawne aplikacje internetowe | Mniejsze aplikacje / mikrousługi |
| 14 | Aplikacje RESTful | Framework Django REST dla aplikacji RESTful. | Użyj następujących rozszerzeń dla aplikacji RESTful. Flask-RESTful Flask-RESTX Zaloguj sie |
| piętnaście | Występ | Niska wydajność, gdy liczba żądań jest duża. | Stała wydajność przez cały czas. |
| 16 | Wkład Open Source | Więcej widelców, zegarków i zatwierdzeń. | Mniejsza liczba widełek, zegarków i zatwierdzeń. |
| 17 | Deweloperzy | Wymaga doświadczonych programistów i nie są łatwo dostępne do rekrutacji. | Większość programistów jest mniej doświadczona i występuje w odpowiedniej liczbie. |
Węzeł Flask Vs
W odniesieniu do stosu tworzenia stron internetowych okazuje się, że tworzenie aplikacji dla sieci wymaga połączenia różnych technologii. Musimy rozbić aplikację internetową na frontend i backend. Część frontendową aplikacji najlepiej opracować w technologiach działających w przeglądarce, takich jak JavaScript, HTML i CSS.
Ogólnie zaplecze jest opracowywane w językach, które są odpowiednie dla strony serwera i mogą w razie potrzeby współdziałać z podstawowym systemem operacyjnym, połączonymi bazami danych lub siecią.
Jednak struktura oparta na języku JavaScript o nazwie NodeJS zmieniła powyższy widok i umożliwiła programistom uzyskanie spójności i jednolitości w zakresie programowania aplikacji internetowych i zaplecza. Programiści mogliby tworzyć dla zaplecza przy użyciu JavaScript.
W tej sekcji Flask vs Node porównujemy Flask, który jest platformą opartą na języku programowania Python, z Node, który jest oparty na środowisku wykonawczym Chrome w przeglądarce JavaScript na podstawie różnych kryteriów, takich jak architektura, szybkość, wsparcie społeczności itp.
| # | Kryteria | Kolba | Węzeł |
|---|---|---|---|
| 7 | Debugowanie | Łatwiejsze debugowanie za pomocą debugera Pythona bez zależności. | Wymaga większego wysiłku. Łatwiej dzięki środowisku programistycznemu z biblioteką Bluebird / Promise. |
| jeden | Język Runtime | Pyton | Silnik JavaScript V8 w Chrome |
| dwa | Architektura | Nieblokujące wejścia / wyjścia wymagają użycia nieblokujących serwerów internetowych, takich jak gunicorn. Kategoria Microframework (backend). | Naturalnie zapewnia nieblokujące we / wy. Kategoria Fullstack |
| 3 | Menedżer pakietów | pypeć | npm |
| 4 | Prędkość | Wolniej z powodu oddzielnego interpretera Pythona. | Szybsze dzięki kompilatorowi Just-In-Time. |
| 5 | Otwarte źródło | tak | tak |
| 6 | Społeczność | Na Github Zegarki 2,3 K. 51,4 tys. Gwiazdek Widły 13,7 K. | Na Github 2,9 K Zegarki 71,9 tys. Gwiazdek Widły 17,6 K. |
| 8 | Konserwacja | Niskie koszty utrzymania | Wyższa konserwacja |
| 9 | Aplikacje działające w czasie rzeczywistym | Z natury nieodpowiedni. Jednak może współpracować z socket.io w przypadkach użycia w czasie rzeczywistym. Użyj przedłużki Flask-socketio. | Odpowiedni ze względu na architekturę sterowaną zdarzeniami i moduły przesyłania strumieniowego. Z natury asynchroniczny. |
| 10 | Biblioteki | Bardziej dojrzały i stabilny. | Mniej dojrzałe i stabilne, ale w ramach aktywnego rozwoju i poprawek. |
| jedenaście | Jakość kodu | Jest tworzony wyłącznie dla zaplecza. | Czasami jest zagrożony, ponieważ nowi programiści frontendu przełączają się na backend. |
| 12 | Skład zespołu programistów | Zespoły składają się zwykle z programistów zaplecza i programistów front-endu. Obawy są oddzielne. | Programiści mogą wymieniać się rolami i pracować zarówno dla interfejsu użytkownika, jak i zaplecza. |
| 13 | Integracja z istniejącym systemem i aplikacjami | Łatwiejsza integracja z innymi istniejącymi starszymi aplikacjami zaplecza przy użyciu ekosystemu Pythona do uczenia maszynowego i aplikacji Big Data. | Dość nowy i wymaga utworzenia niestandardowych lub nowych bibliotek w celu integracji z innymi istniejącymi aplikacjami. |
Często Zadawane Pytania
Q # 1) Czego powinienem się najpierw nauczyć, Django czy Flask?
Odpowiedź: Lepiej jest najpierw wybrać Flask. Gdy zdobędziesz trochę doświadczenia w tworzeniu stron internetowych, możesz zacząć korzystać z Django. Django zakłada, że wiesz już, jak działają aplikacje internetowe i sam dba o większość funkcjonalności.
Pytanie 2) Czy Flask czy Django są lepsze?
Odpowiedź: Zarówno Flask, jak i Django są doskonałe i nadają się do swoich celów. Django służy do tworzenia bardziej znanych aplikacji na skalę korporacyjną. Flask służy do tworzenia statycznych i mniejszych aplikacji. Kolba nadaje się również do prototypowania. Jednak z wykorzystaniem rozszerzeń Flask możemy tworzyć również duże aplikacje.
P # 3) Jakie firmy używają Flask?
najlepszy darmowy ripper DVD do zaszyfrowanych płyt DVD
Odpowiedź: Niektóre firmy korzystające z Flask to Reddit, Mailgun, Netflix, Airbnb itp.
Q # 4) Jakie witryny używają Django?
Odpowiedź: Niektóre witryny korzystające z Django to Instagram, Spotify, YouTube, Dropbox, Bitbucket, Eventbrite itp.
Wniosek
Nie powinniśmy tak naprawdę długo zajmować się jednym frameworkiem. Powinniśmy być gotowi, aby nauczyć się nowych zestawów technologii i przyjąć popularne stosy. Niektórzy z nas chcą stosunkowo po wyjęciu z pudełka, podejść z baterią ze sztywnymi cyklami uwalniania, utrzymując ściślejszą kompatybilność wsteczną itp.
Jeśli uważasz, że bardziej należysz do tej grupy, musisz wybrać Django. Jednak niewiarygodne jest również korzystanie z nowych funkcji i elastyczności platformy Flask. Jeśli chcesz zachować spójność między frontendem a backendem, możesz wybrać platformę z pełnym stosem, taką jak NodeJS.
Wybór frameworka jest bardziej wyborem, który zależy od kontekstu i problemów, które próbujemy rozwiązać. Wybór frameworka jest zawsze trudny. Mamy nadzieję, że w tym samouczku przedstawiliśmy najważniejsze punkty recenzji, które pomogą Ci w sfinalizowaniu jednej platformy. Jednak zalecamy zapoznanie się z obydwoma frameworkami.
Łatwiej jest zacząć od Flaska, a następnie przejść do Django po zdobyciu pewnego doświadczenia w tworzeniu stron internetowych. Jeśli z jakiegoś powodu twoje wysiłki programistyczne wymagają użycia JavaScript, możesz iść dalej z NodeJS.
=> Sprawdź WSZYSTKIE samouczki dotyczące kolb tutaj
rekomendowane lektury
- Python Django Tutorial - Pierwsze kroki z Django
- Wzorce projektowe Flask i najlepsze praktyki dla aplikacji internetowych
- Szablon kolby, formularz, widok i przekierowanie z przykładami
- 31 najpopularniejszych pytań do wywiadów z Python Flask z odpowiedziami
- Jak skonfigurować środowisko testowe Node.js: samouczek dotyczący Node.js.
- Samouczek TestNG: Wprowadzenie do Framework TestNG
- Struktura oparta na słowach kluczowych w selenie z przykładami
- Samouczek programu Robot Framework - instalacja funkcji i oprogramowania