Задать вопрос

Как перенести крупное PHP приложение на Python?

Всем привет!

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

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

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

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

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


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

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

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

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

Возможно мы где-то пропустили важные моменты для понимая сути проблемы - пишите, обязательно дополним.
  • Вопрос задан
  • 4387 просмотров
Подписаться 6 Оценить 6 комментариев
Ответ пользователя Viktor Vsk К ответам на вопрос (6)
viktorvsk
@viktorvsk
Откуда уверенность, что поддерживать Франкенштейна будет проще, чем просто сложное приложение? И что значит "поддерживать"? Вам не хватает гибкости для дальнейшего расширения? Тогда однозначно затык не в языке или базе, а в структуре.

Раскладывайте все по полочкам, выясните цели, а там уже посмотрите, может действительно будет выгоднее переписать с нуля.

Не хотите даже структуру базы и работу с сессиями менять? Тогда все просто:
1. Разработчиков Джанго меньше, чем разработчиков пхп (подставьте ваш фреймворк)
2. Разработчиков перепиленного под пхп джанго еще меньше, чем просто разработчиков джанго.

Я бы может сказал, что в Rails есть некоторые возможности поизвращаться, что б поддерживать кастомные названия таблиц, структуры и т.д., но как-то не логично: использовать фреймворк (культуру, опыт и бестпрактис сообщества), что бы пойти против культуры, бестпрактис и опыта сообщества.
Ответ написан