Навіщо використовувати Django на Google App Engine?


88

Досліджуючи Google App Engine (GAE), стає зрозуміло, що використання Django надзвичайно популярно для розробки в Python на GAE. Я перебирав Інтернет, щоб знайти інформацію про витрати та переваги використання Django, щоб з’ясувати, чому він такий популярний. Хоча мені вдалося знайти широкий спектр джерел про те, як запустити Django на GAE та різні методи цього, я не знайшов жодного порівняльного аналізу, чому Django є кращим, ніж використання фреймворку webapp, наданого Google.

Щоб бути зрозумілим, одразу стає очевидним, чому використання Django на GAE корисно для розробників із наявним набором навичок в Django (більшість веб-розробників Python, без сумніву) або наявним кодом у Django (де використання GAE - це більше вправа перенесення). Однак моя команда оцінює GAE для використання в абсолютно новому проекті, і наш існуючий досвід стосується TurboGears, а не Django.

Було досить складно визначити, чому Django вигідний для команди розробників, коли бібліотеки BigTable замінили ORM Django, сеанси та аутентифікація обов'язково змінюються, а шаблонування Django (за бажанням) доступне без використання всього стека Django.

Нарешті, зрозуміло, що використання Django має перевагу у забезпеченні "стратегії виходу", якщо ми згодом хотіли відійти від GAE і нам потрібна платформа для націлювання на вихід.

Буду вдячний за допомогу, вказавши, чому використання Django краще, ніж використання webapp на GAE. Я також абсолютно недосвідчений у роботі з Django, тому розробка менших функцій та / або зручностей, які працюють на GAE, також є для мене цінною.


святе лайно Террі Бредшоу пише код?
Woot4Moo

4
Django вигідний, оскільки він приголомшливий. Це справді все. :)
ятанізм

Я також новачок у програмі додатків Google, і це жахливо сформоване питання навіть на 2018 рік (хоча Django ORM, здається, зараз набагато краще підтримується на GAE). :)
Divij Sehgal

Відповіді:


19

Ми використовуємо django у наших екземплярах додатків, здебільшого, коли нам потрібно обслуговувати фактичні веб-сайти для користувача. Він має чудовий механізм шаблонів, маршрутизацію URL-адрес та вбудовану обробку запитів / відповідей / помилок. Тож навіть незважаючи на те, що ми не можемо використовувати магічні речі orm / admin, у нього багато чого.

Для сервісів API ми створили щось дуже просте webob. Він набагато легший, тому що йому не потрібно все, що пропонує django, а тому в деяких ситуаціях трохи швидший.


1
Дякую Коен. Частина моєї плутанини щодо привабливості Django випливала з ідеї, що маршрутизація URL-адрес та обробка запитів / відповідей / помилок також були особливостями наданого веб-додатка і що механізм шаблонів можна використовувати без Django, як і з веб-додатком. Я помиляюся? Чи надає Django ці послуги краще, ніж фреймворк webapp?
Тревіс Бредшоу

Я б сказав, що вони більш обширні та гнучкі в джанго. Тож краще, якщо вам це насправді потрібно :-)
Коен Бок,

2
Я думаю, що це відповідь, яку я шукаю! Цей Django в основному є надлишковим для веб-додатків, але функціональність, якою вони діляться, робить Django більш гнучким та надійним способом. Здається, це, безсумнівно, рішення "на маржі", але я думаю, що всі інші пропозиції, плюс ваша, дають вагому відповідь. Дякую.
Тревіс Бредшоу

1
Модулі Python, написані на мові C, також не підтримуються.
Ryu_hayabusa

51

Django, мабуть, не є правильним вибором для вас, якщо ви впевнені, що GAE підходить саме вам. Сильні сторони цих двох технологій не дуже добре узгоджуються - ви повністю втрачаєте багато чудової норми Django на GAE, і якщо ви все-таки використовуєте її, ви пишете код, який насправді безпосередньо не підходить для bigtable та способу роботи GAE.

Річ у GAE полягає в тому, що він отримує велику масштабованість, змушуючи писати код, який легко масштабується з нуля. Ви просто не можете зробити кілька речей, які погано масштабуються (звичайно, ви все ще можете писати погано масштабований код, але уникаєте деяких підводних каменів). Компромісом є те, що ви насправді кодуєте навколо фреймворку, якщо ви використовуєте щось на зразок Django, яке розроблене для іншого середовища.

Якщо ви бачите, що коли-небудь виходили з GAE з будь-якої причини, вкладаючи інвестиції в інфраструктуру, для вас існує проблема. Кодування для bigtable означає, що буде важче перейти до іншої архітектури (хоча проект apache працює, щоб вирішити це для вас за допомогою компоненту HBase проекту Hadoop). Щоб перейти з GAE, було б ще багато роботи.

Що є основним мотиватором використання GAE, крім того, що це продукт Google, і круте модне слово? Чи є причина, що масштабування за допомогою чогось на кшталт пропозицій mediatemple навряд чи вийде для вас? Ви впевнені, що способи масштабування GAE підходять для вашої програми? Як вартість порівняється із виділеними серверами, якщо ви очікуєте досягти цієї сфери продуктивності? Чи можете ви добре вирішити свою проблему, використовуючи інструменти, які надає GAE, порівняно з більш традиційною настройкою сервера із збалансованою навантаженням?

Все це сказано, якщо ви абсолютно не потребуєте прикордонного смішного масштабування, яке пропонує GAE, я особисто пропоную не дозволяти цій конкретній послузі структурувати ваш вибір структури. Мені подобається Django, тому я б сказав, що ви повинні використовувати його, але не на GAE.

Редагувати (червень 2010 р.): Оновлення цього коментаря десь пізніше: Google оголосив такі можливості, як sql, для GAE, які не є безкоштовними, але дозволять вам легко робити такі речі, як запуск команд у стилі SQL для створення звітів про ваші дані.

Окрім цього, в мові запитів GAE відбудуться майбутні зміни, які дозволять набагато простіші складні запити. Подивіться відео з Google I / O 2010.

Крім того, в рамках проекту Summer of Code 2010 проводиться робота, яка повинна забезпечити підтримку не-sql ядра django, а отже, значно полегшити роботу з GAE.

GAE стає все більш привабливим як хостингова платформа.

Редагувати (серпень 2011 р.):

А Google просто значно підвищив вартість для більшості користувачів платформи, змінивши структуру цін. Проблема блокування стала кращою (якщо ваша програма досить велика, ви можете розгорнути альтернативи apache), але для більшості програм запущені сервери або розгортання VPS дешевші.

Дуже мало людей справді мають проблеми з великими даними. "О, мій стартап може колись масштабуватися" - це не велика проблема. Збирайте речі зараз і виводьте їх за двері за допомогою стандартних інструментів.


Дякую за вдумливу відповідь, Пол. Ми оцінюємо GAE здебільшого тому, що модель витрат добре відповідає запропонованому нами бізнес-плану. Можливість запускати безкоштовно, а потім поступово масштабувати з дуже детальною моделлю витрат є дуже привабливою. Крім того, ми не очікуємо необхідності переїзду або міграції з GAE у майбутньому, і блокування платформи для цього проекту є прийнятним. Я включив коментар до "стратегії виходу" у своєму питанні, перш за все, намагаючись бути досить всебічним у тому, що я дізнався під час читання та досліджень, перш ніж розміщувати це питання. Знову дякую!
Тревіс Бредшоу

Як ви оцінюєте витрати часу на розробку? Однією з приємних речей Django є те, що ви витрачаєте менше часу, турбуючись про визначення своїх моделей даних, ніж у Bigtable. Bigtable змушує вас бути набагато чіткішими щодо своїх звичок, перш ніж зможете ним взагалі користуватися. Деякі запити значно простіші за допомогою "звичайного" sql.
Пол Макміллан,

3
Будьте обережні, щоб не перещипнути копійки занадто надмірно. Безкоштовно - це приємно, але послуга швидко коштує реальних грошей. Якщо ви користуєтеся послугою "безкоштовного" рівня, розмістіть його на якомусь іншому сервері / хостингу, за який ви вже платите. Якщо ви потрапляєте на невільний рівень обслуговування, $ 20 / міс за VPS, який ви можете легко масштабувати пізніше, шумить, що стосується вартості.
Пол Макміллан,

11
tbradshaw, не забудьте врахувати, як часто вам будуть потрібні спеціальні звіти, що запускаються на вашому наборі даних. Я беру участь у зростаючому соціальному застосуванні, і GAE стає ... Я не скажу кошмар, але отримувати знання з наших даних надзвичайно ресурсомірно. Між очищенням старих журналів від Google та надзвичайною довжиною, необхідною для розгортання всіх даних, це робить спосіб звітності значно дорожчим, ніж SQL db. Це вартість, яку я не враховував, починаючи роботу. По-друге, якщо ви дійсно зростаєте і починаєте заробляти гроші, контроль, який ви втрачаєте щодо резервних копій, є, ну, фактором.
JasonSmith

2
Що стосується проблем із блокуванням, перевірте AppScale, який є клоном Google App Engine. Ми працюємо над платформою з моменту першого виходу GAE і маємо на ній багато користувачів для своїх робочих програм python та java. Ви маєте прямий доступ до машин, на яких він працює, тому ви маєте більше контролю над інфраструктурою. github.com/AppScale/appscale.git
Navraj Chohan

16

Я зробив багато проектів на GAE. Хтось у django, хтось у звичайних рамках.

Для дрібниць я зазвичай використовую їх звичайні рамки для простоти та швидкості. Як http://stdicon.com , http://yaml-online-parser.appspot.com/ або http://text-twist.appspot.com/ .

Для великих речей я використовую django, щоб скористатися всіма приємними проміжними програмами та плагінами. Як http://metaward.com .

В основному мій лакмусовий тест - це займе у мене більше 2 тижнів, щоб написати і стати РЕАЛЬНИМ проектом програмного забезпечення? Якщо так, перейдіть за допомогою django за аддонами.

Це має додаткову перевагу, якщо ваш проект погано підходить для BigTable, ви швидко портуєте (як я це робить, BigTable повільний чи я німий? )


+1, bigtable - це просто погано для деяких видів проектів та запитів. Це чудово для того, що робить Google, і може бути жахливим для того, що ви хочете зробити.
Пол Макміллан,

Дякую Поле! Не могли б ви зв’язати мене з будь-якими ресурсами, що описують проміжне програмне забезпечення Django та плагіни, які працюють на GAE? Якщо є доповнення, корисні для нашого проекту, це, безсумнівно, було б причиною скористатися Django, а не webapp. Більш очевидно корисні (наприклад, сеанс та автентифікація) мають чіткі залежності Django ORM.
Тревіс Бредшоу

2
В основному будь-який аддон, який не має models.py, буде працювати ідеально. І якщо у них є models.py, ви, мабуть, можете перетворити 1 на 1 у bigtable і все одно використовувати його, якщо хочете. Деякі, якими я користуюся, - це django_annoying, django_debug_toolbar, а також із розділу внеску csrf, humanize і, звичайно, admin.
Пол Тарян

11

Я думаю, що всі ці відповіді трохи застарілі.

Тепер ви можете використовувати Google Cloud SQL

Django - це популярний незалежний веб-фреймворк Python. У поєднанні з Google Cloud SQL вся його функціональність може бути повністю підтримана програмами, що працюють на App Engine . Підтримка використання Google Cloud SQL з Django надається за допомогою власної внутрішньої бази даних Django, яка обгортає серверну інформацію MySQL Django.

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

Ще одна свіжа новина полягає в тому, що існує підтримка BETA для PostgreSQL


3

У мене є досвід використання Django, а не GAE. З мого досвіду роботи з Django це було дуже спрощене налаштування, а процес розгортання був неймовірно простим з точки зору веб-проектів. Звичайно, мені довелося вивчити Python, щоб справді добре втриматися в речах, але в кінці дня я знову використав це для проекту. Це було майже 2 роки тому, перш ніж воно досягло 1,0, тому я знаю, що мої знання трохи застаріли.

Якщо ви стурбовані зміною платформи, то, мабуть, це був би кращий вибір.


1
Дякуємо за швидку відповідь! Хоча я погоджуюся, що Django - це структура, яка швидко розпочинається, нас насправді це не турбує. У нас є чотири досить досвідчені розробники Python з досвідом веб-розробки, тому почати роботу з будь-якими фреймворками буде швидко і безболісно. Але залишається питання, коли вибирати між Django та webapp на GAE, який кращий вибір і чому ?
Тревіс Бредшоу

@ Woot4Moo, якщо у вас немає досвіду роботи з GAE, ви б його розгорнули, я новачок у GAE, але ціна мене дуже бентежить, випадкові великі звинувачення, я думаю про pythonanywhere, чи можете ви передати мені деякі рекомендації?
Манза

0

Я не можу відповісти на запитання, але ви можете заглянути у web2py. Він багато в чому схожий на Django, але його рівень абстракції бази даних працює на GAE і підтримує більшість функціональних можливостей GAE (не всі, але ми намагаємося наздогнати). Таким чином, якщо GAE у вас чудово працює, якщо ні, ви можете перемістити свій код в іншу базу даних (SQLite, MySQL, PostgreSQL, Oracle, MSSQL, FireBird, DB2, Informix, Ingres і - незабаром - Sybase та MongoDB ).


0

Якщо ви вирішили запустити свій додаток за межами GAE, ви все одно можете використовувати Django. Насправді у вас не буде такої великої удачі з веб-додатком GAE


Дякую, хоча я згадую саме це в оригінальному запитанні: "Нарешті, очевидно, що використання Django має перевагу у наданні" стратегії виходу ", якщо пізніше ми хотіли відійти від GAE і нам потрібна платформа для націлювання на вихід. "
Тревіс Бредшоу

0

Я все ще дуже новачок у розробці движка Google App, але інтерфейси, які надає Django, виглядають набагато приємніше, ніж за замовчуванням. Переваги залежатимуть від того, що ви використовуєте для запуску Django на механізмі додатків. Помічник Google App Engine для Django дозволяє використовувати всю потужність Google App Engine із деякими функціоналами Django збоку.

Django non-rel намагається надати якомога більше потужності Django, але працює на двигуні додатків для можливої ​​додаткової масштабованості. Зокрема, він включає моделі Django (одна з основних функцій Django), але це негерметична абстракція через різницю між реляційними базами даних та bigtable. Швидше за все, відбудуться компроміси щодо функціональності та ефективності, а також збільшиться кількість помилок та примх. Звичайно, це може того варте в таких обставинах, як описані у питанні, але в іншому випадку настійно рекомендуємо використовувати помічник на початку, оскільки тоді у вас є можливість перейти до чистого двигуна додатків або Django non-rel пізніше. Крім того, якщо ви перейдете на Django non-rel,

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.