Прошу совета, на чем лучше написать «Личный кабинет» к системе

Здравствуйте

Прошу совета, на чем лучше написать «Личный кабинет» к системе.
БД: MySQL
Основная система: дикий зоопарк из костылей и подпорок на C++/Python/PHP

ЛК явно будет Long Term Project, и хотелось бы выбрать технологию, чтобы даже если я уйду из проекта, другие смогли ее поддерживать еще долгое время.

Ограничений собственно нет.

Хотелось бы, использовать какой-либо framework, чтобы рутину он взял на себя (авторизация, сессии, кэш и т.д.)

В настоящее время раздумываю над SpringMVC+Hibernate vs Play!Framework или удариться в другую сторону Kohana/PHP/Python/Django/Node.JS

Так же хотелось бы, чтобы это было не сильно требовательное к железу (например запустить на ДО на серваке за $5)

В общем прошу совета у всех.

PS. Не хотелось бы, чтобы выбранные технологии, через несколько лет превратились в динозавров, как на другом проекте, где до сих пор приходится писать на Struts 1.x

С уважением, Денис

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Для построения Личного кабинета я бы сначала выбрал надежного поставщика, вроде Herman Miller www.hermanmiller.com/...paces/private-office.html
Для поддержки костылей и подпорок с учетом Long Term Project — внимательно изучил решения от www.thisoldhouse.com/toh/yard-and-garden
С рутиной — проблемами с кешем и авторизацией во время сессия могут помочь парни из ccssvm.com/ccss-demo-video

Для изоляции С++/Python/PHP в зоопарке нужно разумное зонирование и крепкие решетки.

Ну и хороших вам смотрителей, чтобы текущие обитатели вдруг не превратились в динозавров.

Извиняюсь за 5 коп., но очередной раз вижу перед собой выбор:

Kohana/PHP/Python/Django/Node.JS
Mazda / Хетчбек / Микроавтобус / Mercedes-Benz / Электромобиль
В настоящее время раздумываю над SpringMVC+Hibernate vs Play!Framework
Когда-то и я почти так же раздумывал, но у вас неточность. SpringIoC это не SpringMVC. Да, это соотносящиеся части, но не более того. К тому же именно SpringMVC это по сути Enterprise level Framework (EE) + без SpringSesurity (исключительно EE) я не представляю чтоб он кому-то нужен был. В то время как Play!Framework это быстрый, лёгкий, масштабируемый MVC фреймворк, бегающий под SE, выполняющий, как фреймворк, по сути те же задачи что и SpringMVC, но более годный для RAD, не требующий сервлет контейнета и прочего (он сам на Netty основан, но, к дичайшему сожалению, не позволяет вклиниватся в его луп)
Также стоит помнить что Play!Framework это stateless решение — например сессии как у сервлетов или как у PHP у него изначально нет, прикручивается самостоятельно. Хотя я конечно влюбился в этот фреймворк без оглядки, правда сейчас планирую из проекта убирать всё отношение к Spring. Как для моего проекта это overhead — сейчас использую IoC и Data JPA, буду мигриговать на гуся и Neo4j.
P.S. Если надумаешь таки PHP то не советую брать что-то менее «mature» чем Symfony. Да и её — исключительно последнюю. И жёстко следить за исполнением стандартов диктуемых фреймворком. Всегда говорил что главная беда (их много) PHP — это его низкий порог входа.
SpringMVC
Я написал только первое, хотя оно за собой тянет много чего
Play мне тоже очень понравился, и минусы Вы точно расписали

Пробовали Play стартовать на ДО минимальной конфигурации?

Да, он вообще не требователен. Это ведь по сути Netty + Akka + пара обёрток. У меня всё бегает под Java 8 Server JRE и PostgreSQL больше ресурсов требует чем приложение.

PHP
просто потому что проще, быстрее, дешевле.
Кроме того, сишник или джавист гораздо быcтре освоит PHP чем наоборот.
Проблемы типа не умею или не признаю другой язык — это детский сад не относящийся к делу.

Проблемы типа не умею или не признаю другой язык — это детский сад не относящийся к делу.
согласен, но мир не идеален

Команда как раз сильно разная:
1. Первый знает Perl но не любит ничего другого
2. Второй знает Python и JavaScript и не любит остальное
3. Третий знает PHP и другого просто не знает
4. Четвертый знает С++ и больше вообще ничего

но каждый в своем деле мастер

в итоге нет пересечения, чтобы хоть что-то было понятно остальным
и не реально выделить какой-то элемент доминирующий

Я бы максимально разделил сервер-сайд и клиент-сайд части в условиях зоопарка. То есть в идеале одностраничное приложение на клиенте, общающееся с сервером по API типа Restfull или XML RPC с JSON или XML. Для сервер-сайда выбрал бы (из Python/PHP) платформу которая имеет больше шансов стать доминирующей в проекте (на чём пишутся новые подсистемы? что лучше знает остальная команда?), а потом бы выбирал фреймворк на этой платформе, опять же исходя из того, что уже есть, что в планах для других подсистем, что предпочитает команда. По сути если жестко разделяем фронт и бэк, то обычно достаточно микрофреймворков, если логика приложения (не путать с бизнес-логикой) довольно проста.

Django конечно же. Новые технологии только добавят сложности, а не улучшат дело. Или ты хочешь чтобы вместо

Основная система: дикий зоопарк из костылей и подпорок на C++/Python/PHP
Был
система: дикий зоопарк из костылей и подпорок на C++/Python/PHP/Java/Scala/JavaScript ?
ЛК явно будет Long Term Project, и хотелось бы выбрать технологию, чтобы даже если я уйду из проекта, другие смогли ее поддерживать еще долгое время.

Вы вероятно уже работаете с этими людьми, попробуйте оценить их опыт и возможности обучения. Если это к примеру люди которые собаку съели на PHP, но в другие технологии ни ногой, то SpringMVC+Hibernate покажется им ночным кошмаром. Разумнее взять что-то уже знакомое для них.

Второй момент от того какого рода задачи будет выполнять этот ЛК? Наверняка же какие-то модули можно будет переиспользовать из существующей системы или настраивать взаимодействие с ними.

Так же хотелось бы, чтобы это было не сильно требовательное к железу (например запустить на ДО на серваке за $5)

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

SpringMVC+Hibernate покажется им ночным кошмаром
с этим согласен
SpringMVC+Hibernate покажется им ночным кошмаром
Если учесть что доктрина почти полностью была слизана с хайбернейта то нет.

От Java отказался бы сразу.
Смотрите в сторону стека MEAN или PHP/Python.
Front end: AngularJS/Backbone/Ember + Twitter bootstrap (есть даже темы под материал дизайн).

Смотря, ЧТО ТАКОЕ этот личный кабинет, насколько часто его люди должны посещать в рамках твоего сервиса. Одно дело если пользователь в нём «живёт», как например личный кабинет Аукро у торгаша. Другое — если это просто админка под настройки и редкие функции типа «пополнить счёт».

В большинстве случаев роль личного кабинета переоценена. Пили на чём хочешь. Как правило, нагрузка на личные кабинеты незначительна, то есть даже самый страшный монстр с лёгкостью пойдёт на любом серваке. И пусть он будет динозавром, потом переписать его по частям обычно не проблема. Главное побыстрее поднять и не заморачиваться.

В рамках системы, Пользователь именно «живет» там, потребляя и мониторя систему.
Но нагрузка будет не большая (не так уж и много этих Пользователей)

Вот и вопрос, на чем быстрее поднять

Так надо быстрее поднять или с прицелом на долгосрочное обслуживание?

Если быстрее, то на клиенте лучше всего Ангулар юзать. На нем можно сравнительно быстро и выразительно че-нить написать.
Если с прицелом на долгосрочное обслуживание — то что-нибудь более гибкое. Я бы в сторону Реакта посмотрел.

Если с прицелом на долгосрочное обслуживание
как по мне лучше Ember

Спорить не буду, с ним не работал.
Какие преимущества у Эмбера? Насколько я знаю — он достаточно формализирован и не самый простой в освоении. Ну и в плане распространнености кажется проигрывает тому же реакту.

в виду того что:

Основная система: дикий зоопарк из костылей и подпорок на C++/Python/PHP
вы хотите туда добавить еще и джаву?

я бы выбирал ту технологию которая +/- будет сочетатся с текущим стеком, то есть смотрел бы на фреймворки на PHP/Python

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

Хотел тоже применить принцип «На чем написано на том и продолжаем писать», но тут не подходит, много всего и много разного.

Добавив в зоопарк еще и Джаву будет «было: хаос, станет хаос+1»

Підписатись на коментарі