Dlaczego warto używać Django w Google App Engine?


88

Podczas badania Google App Engine (GAE) widać, że używanie Django jest niezwykle popularne w programowaniu w Pythonie na GAE. Przeszukuję sieć, aby znaleźć informacje o kosztach i korzyściach używania Django, aby dowiedzieć się, dlaczego jest tak popularne. Chociaż udało mi się znaleźć wiele różnych źródeł dotyczących sposobu uruchamiania Django w GAE i różnych metod robienia tego, nie znalazłem żadnej analizy porównawczej na temat tego, dlaczego Django jest lepsze od korzystania z frameworka aplikacji internetowej dostarczanego przez Google.

Aby było jasne, od razu widać, dlaczego używanie Django w GAE jest przydatne dla programistów z istniejącym zestawem umiejętności w Django (bez wątpienia większość programistów internetowych w Pythonie) lub istniejącym kodem w Django (gdzie używanie GAE jest bardziej ćwiczeniem portowania). Mój zespół jednak ocenia GAE do wykorzystania w zupełnie nowym projekcie, a nasze dotychczasowe doświadczenia dotyczą TurboGears, a nie Django.

Trudno było ustalić, dlaczego Django jest korzystne dla zespołu programistów, kiedy biblioteki BigTable zastąpiły ORM Django, sesje i uwierzytelnianie są koniecznie zmienione, a szablony Django (jeśli jest to pożądane) są dostępne bez użycia całego stosu Django.

Wreszcie, jasne jest, że używanie Django ma tę zaletę, że zapewnia „strategię wyjścia”, jeśli później chcieliśmy odejść od GAE i potrzebujemy platformy do kierowania exodusu.

Byłbym bardzo wdzięczny za pomoc we wskazaniu, dlaczego używanie Django jest lepsze niż używanie aplikacji webowej w GAE. Jestem też kompletnie niedoświadczony z Django, więc rozwinięcie mniejszych funkcji i / lub udogodnień, które działają w GAE, jest również dla mnie cenne.


święty gówno Terry Bradshaw pisze kod?
Woot4Moo

4
Django jest korzystne, ponieważ jest niesamowite. To naprawdę to. :)
jathanism

Jestem też nowy w silniku aplikacji Google i jest to strasznie dobrze sformułowane pytanie nawet na 2018 rok (chociaż Django ORM wydaje się, że jest teraz znacznie lepiej obsługiwany w GAE). :)
Divij Sehgal

Odpowiedzi:


19

Używamy django w naszych instancjach appengine głównie wtedy, gdy musimy udostępniać użytkownikowi rzeczywiste strony internetowe. Ma świetny silnik szablonów, routing adresów URL i całą wbudowaną obsługę żądań / odpowiedzi / błędów. Więc nawet jeśli nie możemy używać magicznych rzeczy orm / admin, ma wiele do zaoferowania.

Dla usług API stworzyliśmy coś bardzo prostego webob. Jest znacznie lżejszy, ponieważ nie potrzebuje wszystkiego, co oferuje django, a zatem jest trochę szybszy w niektórych sytuacjach.


1
Dzięki Koen. Część mojego zamieszania co do atrakcyjności Django wynikała z pomysłu, że routing adresów URL i obsługa żądań / odpowiedzi / błędów były również cechami dostarczonej aplikacji internetowej i że silnik szablonów może być używany bez Django, a także z aplikacją internetową. Czy się mylę? Czy Django zapewnia te usługi lepiej niż framework webapp?
Travis Bradshaw

Powiedziałbym, że są bardziej rozbudowane i elastyczne w django. Więc lepiej, jeśli naprawdę tego potrzebujesz :-)
Koen Bok,

2
Myślę, że to jest odpowiedź, której szukam! To, że Django jest w dużej mierze zbędne dla aplikacji internetowej, ale w funkcjonalności, którą współdzielą, Django robi w bardziej elastyczny i niezawodny sposób. Wygląda na to, że to z pewnością decyzja „na marginesie”, ale myślę, że wszystkie inne sugestie, wraz z twoją, stanowią przekonującą odpowiedź. Dzięki.
Travis Bradshaw

1
Moduły Pythona napisane w C również nie są obsługiwane.
Ryu_hayabusa,

51

Django prawdopodobnie nie jest właściwym wyborem dla Ciebie, jeśli jesteś pewien, że GAE jest właśnie dla Ciebie. Mocne strony tych dwóch technologii nie pasują do siebie zbyt dobrze - całkowicie tracisz wiele wspaniałego ormu Django w GAE, a jeśli go używasz, piszesz kod, który nie jest bezpośrednio odpowiedni dla bigtable i sposobu, w jaki działa GAE.

Rzecz w GAE polega na tym, że uzyskuje wielką skalowalność, zmuszając cię do pisania kodu, który łatwo skaluje się od podstaw. Po prostu nie możesz zrobić wielu rzeczy, które słabo się skalują (oczywiście, nadal możesz pisać słabo skalowalny kod, ale unikniesz niektórych pułapek). Kompromis polega na tym, że naprawdę kończysz kodowanie wokół frameworka, jeśli używasz czegoś takiego jak Django, które jest zaprojektowane dla innego środowiska.

Jeśli zauważysz, że kiedykolwiek opuszczasz GAE z jakiegokolwiek powodu, inwestujesz w infrastrukturę, jest to dla ciebie problem. Kodowanie dla bigtable oznacza, że ​​trudniej będzie przejść na inną architekturę (chociaż projekt Apache pracuje nad rozwiązaniem tego problemu za pomocą składnika HBase projektu Hadoop). Przeniesienie się z GAE wciąż wymagałoby dużo pracy.

Co motywuje używanie GAE, oprócz bycia produktem Google i fajnym modnym hasłem? Czy jest jakiś powód, dla którego skalowanie za pomocą czegoś takiego jak oferta mediatemple prawdopodobnie nie zadziała dobrze? Czy jesteś pewien, że sposoby skalowania GAE są odpowiednie dla Twojej aplikacji? Jak wypada koszt w porównaniu z serwerami dedykowanymi, jeśli spodziewasz się dostać do tej dziedziny wydajności? Czy możesz dobrze rozwiązać swój problem, korzystając z narzędzi dostarczanych przez GAE, w porównaniu z bardziej tradycyjną konfiguracją serwera z równoważeniem obciążenia?

Wszystko to powiedziawszy, chyba że absolutnie pozytywnie potrzebujesz skrajnie niedorzecznego skalowania, które oferuje GAE, osobiście sugerowałbym, aby ta konkretna usługa nie ustrukturyzowała wybór frameworka. Lubię Django, więc powiedziałbym, że powinieneś go używać, ale nie w GAE.

Edycja (czerwiec 2010): Jako aktualizacja tego komentarza jakiś czas później: Google ogłosił funkcje GAE podobne do sql, które nie są darmowe, ale pozwolą ci łatwo wykonywać takie czynności, jak uruchamianie poleceń w stylu SQL w celu generowania raportów na temat twoich danych.

Ponadto nadchodzą zmiany w języku zapytań GAE, które pozwolą na tworzenie złożonych zapytań w znacznie łatwiejszy sposób. Obejrzyj filmy z konferencji Google I / O 2010.

Co więcej, w ramach projektu Summer of Code 2010 trwają prace, które powinny zapewnić obsługę jądra django bez obsługi sql, a co za tym idzie, znacznie ułatwić pracę z GAE.

GAE staje się coraz bardziej atrakcyjna jako platforma hostingowa.

Edycja (sierpień 2011):

Firma Google właśnie znacznie podniosła koszt większości użytkowników platformy, zmieniając strukturę cen. Problem z blokowaniem się poprawił (jeśli Twoja aplikacja jest wystarczająco duża, możesz wdrożyć alternatywy dla apache), ale w przypadku większości aplikacji uruchamianie serwerów lub wdrożenia VPS są tańsze.

Bardzo niewiele osób ma naprawdę duże problemy z danymi. „Och, mój startup może kiedyś się skalować” nie jest problemem z dużymi danymi. Twórz rzeczy teraz i wyciągaj je za drzwi, używając standardowych narzędzi.


Dzięki za przemyślaną odpowiedź, Paul. Oceniamy GAE głównie dlatego, że model kosztów dobrze pasuje do naszego proponowanego biznesplanu. Możliwość swobodnego uruchamiania, a następnie stopniowego skalowania za pomocą bardzo szczegółowego modelu kosztów jest bardzo atrakcyjna. Ponadto nie spodziewamy się konieczności przenoszenia lub migracji z GAE w przyszłości, a blokowanie platformy dla tego projektu jest dopuszczalne. Uwzględniłem komentarz dotyczący strategii wyjścia w moim pytaniu przede wszystkim po to, aby być dość wyczerpującym w tym, czego nauczyłem się podczas czytania i badań przed opublikowaniem tego pytania. Dzięki jeszcze raz!
Travis Bradshaw

Jak oceniasz koszt czasu rozwoju? Jedną z fajnych rzeczy w Django jest to, że spędzasz mniej czasu na martwieniu się o definiowanie modeli danych niż w przypadku Bigtable. Bigtable zmusza cię do bardziej precyzyjnego określenia swoich zastosowań, zanim będziesz mógł go w ogóle używać. Niektóre zapytania są znacznie łatwiejsze w przypadku „normalnego” sql.
Paul McMillan,

3
Uważaj, aby nie uszczypnąć zbytnio groszy. Bezpłatna jest fajna, ale usługa szybko kosztuje prawdziwe pieniądze. Jeśli wybierasz „darmowy” poziom usług, umieść go na innym serwerze / hostingu, za który już płacisz. Jeśli wchodzisz na niewolny poziom usług, 20 USD miesięcznie za VPS, który możesz łatwo skalować później, jest hałasem, jeśli chodzi o koszt.
Paul McMillan,

11
tbradshaw, nie zapomnij zastanowić się, jak często będziesz potrzebować raportów ad-hoc, uruchamianych na Twoim zestawie danych. Jestem zaangażowany w rozwijającą się aplikację społecznościową, a GAE staje się ... Nie powiem koszmarem, ale czerpanie wiedzy z naszych danych jest niezwykle wymagające. Pomiędzy usuwaniem starych dzienników przez Google a ekstremalnymi długością wymaganą do przeglądania wszystkich danych, sprawia to, że sposób raportowania jest o wiele droższy niż baza danych SQL. To koszt, którego nie brałem pod uwagę na początku. Po drugie, jeśli naprawdę się rozwijasz i zaczynasz zarabiać, kontrola, którą tracisz nad kopiami zapasowymi, ma znaczenie.
JasonSmith,

2
W przypadku problemów związanych z blokowaniem sprawdź AppScale, który jest klonem Google App Engine. Pracujemy nad platformą od momentu pojawienia się GAE i mamy na niej wielu użytkowników do swoich produkcyjnych aplikacji w języku Python i Java. Masz bezpośredni dostęp do maszyn, na których działa, dzięki czemu masz większą kontrolę nad infrastrukturą. github.com/AppScale/appscale.git
Navraj Chohan

16

Zrobiłem wiele projektów na GAE. Niektóre w django, inne w ich normalnym frameworku.

W przypadku małych rzeczy zwykle używam ich normalnych ram dla prostoty i szybkości. Podobnie jak http://stdicon.com , http://yaml-online-parser.appspot.com/ lub http://text-twist.appspot.com/ .

W przypadku dużych rzeczy używam django, aby wykorzystać wszystkie fajne oprogramowanie pośrednie i wtyczki. Podobnie jak http://metaward.com .

Zasadniczo mój test lakmusowy brzmi: Czy to zajmie mi więcej niż 2 tygodnie, aby napisać i być PRAWDZIWYM projektem oprogramowania? Jeśli tak, przejdź z django do dodatków.

Ma tę dodatkową zaletę, że jeśli twój projekt źle pasuje do BigTable, szybko się przenosisz (tak jak ja. Czy BigTable jest wolny, czy jestem głupi? )


+1, bigtable jest po prostu zły dla niektórych rodzajów projektów i zapytań. Świetnie nadaje się do tego, co robi Google, i może być okropny w przypadku tego, co chcesz robić.
Paul McMillan

Dzięki Paul! Czy możesz połączyć mnie z jakimikolwiek zasobami opisującymi oprogramowanie pośrednie i wtyczki Django, które działają w GAE? Jeśli istnieją dodatki przydatne w naszym projekcie, z pewnością byłby to powód, aby wybrać Django, a nie aplikację internetową. Te bardziej użyteczne (jak sesja i uwierzytelnianie) wydają się mieć wyraźne zależności ORM od Django.
Travis Bradshaw

2
Zasadniczo każdy dodatek, który nie ma pliku models.py, będzie działał idealnie. A jeśli mają models.py, prawdopodobnie możesz wykonać konwersję 1 do 1 na bigtable i nadal go używać, jeśli chcesz. Niektóre, których używam, to django_annoying, django_debug_toolbar oraz z sekcji dotyczącej wkładów csrf, humanize i oczywiście admin.
Paul Tarjan,

11

Myślę, że wszystkie te odpowiedzi są nieco przestarzałe.

Teraz możesz użyć Google Cloud SQL

Django to popularny framework sieciowy Python innej firmy. W połączeniu z Google Cloud SQL wszystkie jego funkcje mogą być w pełni obsługiwane przez aplikacje działające w App Engine . Obsługa korzystania z Google Cloud SQL z Django jest zapewniana przez niestandardową bazę danych Django, która otacza zaplecze MySQL Django.

https://cloud.google.com/python/django/appengine

kolejną świeżą wiadomością jest to, że istnieje wsparcie BETA dla PostgreSQL


3

Mam doświadczenie w używaniu Django, a nie GAE. Z moich doświadczeń z Django wynika, że ​​była to bardzo uproszczona konfiguracja, a proces wdrażania był niezwykle łatwy pod względem projektów internetowych. To prawda, że ​​musiałem nauczyć się Pythona, aby naprawdę dobrze się opanować, ale pod koniec dnia użyłem go ponownie w projekcie. To było prawie 2 lata temu, zanim osiągnęło 1.0, więc moja wiedza jest nieco przestarzała.

Jeśli martwisz się o zmianę platform, przypuszczam, że byłby to lepszy wybór.


1
Dziękuję za szybką odpowiedź! Chociaż zgadzam się, że Django jest frameworkiem, który można szybko rozpocząć, nie jest to dla nas problemem. Mamy czterech dość doświadczonych programistów Pythona z doświadczeniem w tworzeniu stron internetowych, więc rozpoczęcie pracy z dowolnym frameworkiem będzie szybkie i bezbolesne. Pozostaje jednak pytanie, przy wyborze między Django a aplikacją internetową na GAE, który jest lepszym wyborem i dlaczego ?
Travis Bradshaw

@ Woot4Moo, jeśli nie masz doświadczenia z GAE, na którym go wdrożyłeś, jestem nowy w GAE, ale cena bardzo mnie dezorientuje, losowe opłaty hughe, myślę, że gdziekolwiek python, czy możesz przekazać mi jakieś zalecenia?
Manza,

0

Nie mogę odpowiedzieć na pytanie, ale możesz zajrzeć do web2py. Pod wieloma względami jest podobny do Django, ale jego warstwa abstrakcji bazy danych działa na GAE i obsługuje większość funkcji GAE (nie wszystkie, ale staramy się nadrobić zaległości). W ten sposób, jeśli GAE działa świetnie, jeśli nie, możesz przenieść swój kod do innej bazy danych (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres, a wkrótce - Sybase i MongoDB ).


0

Jeśli zdecydujesz się uruchomić swoją aplikację poza GAE, nadal możesz używać Django. Z aplikacją internetową GAE nie będziesz miał tyle szczęścia


Dzięki, chociaż wspominam dokładnie o tym w pierwotnym pytaniu: „Wreszcie, jest jasne, że używanie Django ma tę zaletę, że zapewnia„ strategię wyjścia ”, jeśli później chcieliśmy odejść od GAE i potrzebujemy platformy do wycelowania w exodus. "
Travis Bradshaw

0

Wciąż jestem bardzo nowy w rozwoju silnika aplikacji Google, ale interfejsy, które zapewnia Django, wydają się znacznie ładniejsze niż domyślne. Korzyści będą zależeć od tego, czego używasz do uruchamiania Django w silniku aplikacji. Pomocnik Google App Engine dla Django umożliwia wykorzystanie pełnej mocy Google App Engine z niektórymi funkcjami Django po stronie.

Django non-rel stara się zapewnić jak najwięcej mocy Django, ale działa na silniku aplikacji, aby zapewnić dodatkową skalowalność. W szczególności zawiera modele Django (jedna z podstawowych funkcji Django), ale jest to nieszczelna abstrakcja ze względu na różnice między relacyjnymi bazami danych a bigtable. Najprawdopodobniej wystąpią kompromisy w zakresie funkcjonalności i wydajności, a także zwiększona liczba błędów i dziwactw. Oczywiście może to być tego warte w okolicznościach takich jak te opisane w pytaniu, ale w przeciwnym razie zdecydowanie zalecamy użycie helpera na początku, ponieważ wtedy możesz później przejść do czystego silnika aplikacji lub Django non-rel. Ponadto, jeśli przełączysz się na Django non-rel,

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.