Перенос крупного PHP приложения на Python

Рейтинг: 4Ответов: 2Опубликовано: 08.12.2014

Требуется перенести крупный (с очень сложной структурой) веб-проект на Python-платформу. Приложение представляет из себя что-то вроде социальной сети или сообщества для корпоративного использования.

База данных меняться не будет (MySQL), а её структура и подавно. Поэтому будущая система должна писаться с оглядкой на уже существующие данные и базу.

Система должна быть очень гибкой и удобной для всевозможных изменений.

Изначально планировали смотреть на Django. Но немного познакомившись - смутились:

  1. Структура пользователей (и не только) в базе должна строго ложиться на уже существующую. Структура Django нам не подходит. Или нужно переписывать стандартную структуру и исправлять это (что мы так понимаем делать крайне не рекомендуется).
  2. Тоже самое касается прав доступа, логов, отчасти сессий (не принципиально) и прочих плюшек которые идут в джанго "из коробки"
  3. Админка "из коробки" не подходит по всевозможным причинам. Начиная с дизайна-юзабилити и заканчивая структурой. Из-за этого мы плачем по ночам...
  4. ORM хорош, но есть места где придётся им пренебречь

Отсюда выходит, что большинство тех возможностей которые имеет (или может в перспективе иметь с установкой подходящих плагинов или расширений) Django - для нас не актуальны.

Поэтому вопрос таков: на чем стоит разрабатывать приложение?

В качестве вариантов рассматривали Flask и Pylons, но по ним информации (а тем более кадров) намного меньше. Поэтому будем рады замечаниям на этот счет.

Подтвердите, опровергните наши размышления либо предложите какой-то свой вариант решения проблемы. Очень будем признательны за развернутый ответ.

Возможно мы где-то пропустили важные моменты для понимая сути проблемы - пишите, обязательно дополним.

Ответы

▲ 4

я выскажу свое мнение:

1) Для крупных проектов используется JAVA либо C#

2) Некоторые используют PYTHON (типа яндекса) кто-то и PHP

3) PHP - крутится в этом направлении (сайтов и соц.сетей)

4) "Убогость PHP" ну никак не оправдано, это довольно быстрый язык и на нем стоит куча сайтов (до недавнего времени ВК стоял на ПХП и проблем не было)

5) ПХП обновляется динамично что дает через некоторое время оптимизацию тех функцию которые на сегодняшний момент работают не так глатко.

6) раз у вас там мега-сеть, легче купить вторую машину, которая будет брать часть нагрузки, чем все переписывать.

7) поддерживать ПХП (по мне так) легче.

8) Хотите быстродействие? берите вон KPHP

▲ 4

Вставлю и я свои 5 копеек..

На Flask и Pylons у меня опыта нет, потому дам только контр-аргументы к вашим по Django:

  1. Структуру пользователей можно переписать, если речь о большом проекте, то это не самая сложная задача с которой придется столкнуться. Что такое фреймворк вообще? - это среда, это набор инструментов. Никто не обязывает использовать все инструменты. Если хоть чуть более половины инструментов представленных тем или иным фреймворком вам подходит, то уже есть смысл его использовать. А идеально ни один универсальный фреймворк под специфический проект не подойдет, имхо.
  2. Систему прав доступа само собой надо делать под себя. Я как бы за три года ни разу не видел, чтобы кто-то джанговской всерьез пользовался, ну разумеется за исключением базовых опций (суперпользователь, статус персонала).
  3. Ну опять, Django-админка она для удобства на этапе разработки или для полноценного использования в небольших проектах, хотя ее можно кастомизировать достаточно глубоко, и существует на эту тему некоторое количество сторонних пакетов. Но в вашем случае, для корпоративной системы все равно свою писать нужно.
  4. ORM потому и хорош, что удобен быстротой и простотой в несложных популярных случаях, но никто не обещал, что он пригоден абсолютно везде, там где проще вам будет, то пишите себе на здоровье raw-запросы.

ПС: Если ваша команда пока только будет начинать изучать новые инструменты и еще нет выработанных привычек, то можно взять Flask ибо он слывет своей минималистичностью, вы сами напишете к нему что нужно и не будет избыточности в вашем случае. Но если в будущем надо будет набирать новых разработчиков, то мне кажется на Django найти специалиста куда проще, чем на всякую экзотику.