Коллеги, назревает необходимость переноса портала с ASP.Net/Oracle на Apache/Postgres. Импортозамещение так сказать.
Кроме того там давно пора все переписывать.
Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики.
php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
Здравствуйте, pugv, Вы писали:
P>Коллеги, назревает необходимость переноса портала с ASP.Net/Oracle на Apache/Postgres. Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики. php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
С такими требованиями — что угодно. Просто выбираешь, с чем интересно познакомиться, что интересно выучить, и вперёд. Нужно больше исходных данных для совета.
Здравствуйте, anonymous, Вы писали:
A>С такими требованиями — что угодно. Просто выбираешь, с чем интересно познакомиться, что интересно выучить, и вперёд. Нужно больше исходных данных для совета.
Спасибо. Ну а каких данных? Развесистая учетная система по сути. Положить в базу/взять из базы, посчитать, нарисовать страничку, отдать клиенту. Одновременно работающих пользователей 3-5 тысяч. Хорошо бы, чтоб какой-нибудь ORM нормально прикручивался.
Здравствуйте, pugv, Вы писали:
A>>С такими требованиями — что угодно. Просто выбираешь, с чем интересно познакомиться, что интересно выучить, и вперёд. Нужно больше исходных данных для совета. P>Спасибо. Ну а каких данных? Развесистая учетная система по сути. Положить в базу/взять из базы, посчитать, нарисовать страничку, отдать клиенту. Одновременно работающих пользователей 3-5 тысяч. Хорошо бы, чтоб какой-нибудь ORM нормально прикручивался.
В том то и дело, что у всех перечисленных есть ORM и не один и ещё больше фреймворков для отрисовки и отдачи страниц, которые выдержат такое количество клиентов. Вот если б требования были типа наличия или отсутствия статической типизации, тогда уже можно обсуждать варианты. Разве что вместо Java я б рекомендовал на Goovy смотреть, ближе по синтаксису к другим будет.
Здравствуйте, anonymous, Вы писали:
A>В том то и дело, что у всех перечисленных есть ORM и не один и ещё больше фреймворков для отрисовки и отдачи страниц, которые выдержат такое количество клиентов. Вот если б требования были типа наличия или отсутствия статической типизации, тогда уже можно обсуждать варианты. Разве что вместо Java я б рекомендовал на Goovy смотреть, ближе по синтаксису к другим будет.
Статическая типизация конечно плюс, при прочих равных.
Просто думал может есть какой-то "стандарт" для продакшн-приложений нынче, наиболее широко используемый и оптимальный по производительности/трудоемкости.
P>Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики. P>php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
Стандартный ответ — на том, что хорошо знает команда. Но если именно модное — то это angularjs на морде, nodejs в бэкэнде, и NoSQL хранилище (Postgress, да и вообще SQL это в бакэнде не модно). Скорее всего вообще не взлетит, или будет в ужасном состоянии настолько что все кинут проект и разбегутся, но реально некоторое время будете писать на пике хайпа.
.
Python — пик хайпа уже позади, ощущение что с ним ты ближе к гуглу — всё слабее, да и гугл предал наклепав всяких Go, проблемы остались.
Ruby — Связка Ruby/RoR долгое время учила всех как надо делать это красиво. Все скопировали, в результате сейчас преимуществ около нуля.
Nodejs — В начале испугали экспонентой, особенно учитывая что хайп формировали команды стартапщиков которые своё время вообще не считают — вместо этого там меряются долями. Сейчас у тех аутсорс контор которые повелись, начинает появляться статистика по проектам и медленно наступает прозрение. Но те, кто в бакэнде догадались применить TypeScript — сейчас смотрят на остальных как на лузеров. Т.е. если и выберешь nodejs — возьми TypeScript или аналоги.
Java — В роли догоняющих уже лет 15. Как следствие ты успеешь написать портал на всех технологиях выше, и взявшись повторить его же на Java обнаружишь что они как раз сделали те фичи которые были у конкурентов.
Учитывая сколько разного за эти годы умерло, а ASP.NET ещё бодрячком — я бы советовал оставить где есть (даже не покрытая тестами но работающая бизнес-логика дорогого стоит!), взять VS 2015 и изучить все последние мутации которые произошли за эти годы (Web API, Razor, работа на Linux, развёртывание в облачка, и т.п.). Если у вас будет бутстрап-джаваскриптовая морда, с логикой торчащей наружу исключительно через WebAPI, полный реалтаймовый апдейт всех формочек и гридов через SignalR — через год будете модные-модные.
Здравствуйте, pugv, Вы писали:
P>Коллеги, назревает необходимость переноса портала с ASP.Net/Oracle на Apache/Postgres. Импортозамещение так сказать. P>Кроме того там давно пора все переписывать. P>Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики. P>php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
Java. Быстрая(уж точно быстрее динамики вроде руби и похапэ), удобная, имеет тысячи библиотек на все случаи жизни.
Питон малопредсказуем, чего только стоят его exception'ы.
Здравствуйте, pugv, Вы писали:
P>Просто думал может есть какой-то "стандарт" для продакшн-приложений нынче, наиболее широко используемый и оптимальный по производительности/трудоемкости.
Нет, разброс используемых технологий очень велик. Есть, конечно, мода, но она постоянно меняется. (См. http://rsdn.ru/forum/web/6025923.1
Здравствуйте, pugv, Вы писали:
P>Да в том-то и дело, что команда знает в основном C++/C#.
Пишите на C++. Все нагруженные веб бекенды на С++, для управления соединениями, поступающими запросами
(раскидывание по кластеру), передачей данных, с выводом в PHP/Python/Perl на которых скриптуются логики управления
передаваемым и принимаем контентом.
Здравствуйте, pugv, Вы писали:
P>Коллеги, назревает необходимость переноса портала с ASP.Net/Oracle на Apache/Postgres. Импортозамещение так сказать. P>Кроме того там давно пора все переписывать. P>Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики. P>php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
Java
Выше Вы писали, что команда знает C++/C# — в яве фич меньше (причем сейчас уже почти исправились), но в целом очень близка к шарпу. Мне кажется это главное преимущество.
Плюс ИМХО сложную логику под веб существенно проще писать на яве, куча библиотек, живей всех живых, куча относительно стандартных решений.
Ну и по паре легких минусов других вариантов:
Ruby — я в своё время несколько дней пытался понять как развернуть уже готовый сайт на RoR: костыль на костыле, ноль документации по стандартным решениям и т.д.
PHP — между версиями легонько ломают совместимость. Всё зависит от того как писать и ломают её в основном по незаметным мелочам, но в яве таких фокусов на вскидку не помню.
Python — не всем нравиться (мне допустим нет). Плохая карма, после полностью сломаной совместимости между 2 и 3 версиями.
Здравствуйте, 11molniev, Вы писали:
1>Java 1>Выше Вы писали, что команда знает C++/C# — в яве фич меньше (причем сейчас уже почти исправились), но в целом очень близка к шарпу. Мне кажется это главное преимущество.
Да, тоже об этом подумал.
А какие конкретно фреймворки и IDE лучше?
Здравствуйте, pugv, Вы писали:
P>Здравствуйте, 11molniev, Вы писали:
1>>Java 1>>Выше Вы писали, что команда знает C++/C# — в яве фич меньше (причем сейчас уже почти исправились), но в целом очень близка к шарпу. Мне кажется это главное преимущество.
P>Да, тоже об этом подумал. P>А какие конкретно фреймворки и IDE лучше?
Среди IDE попробуйте jetbrains intellij idea. ИМХО она даже чуть лучше связки Visual Studio C++/C# + Visual Assist и имеет большой отрыв от конкурентов.
Среди фреймворков есть Spring MVC и Hibernate — по идее они должны покрыть все стандартные потребности.
Хотя в принципе можно писать и просто JSP + логику без фреймворков — но это немного не по фуншую.
Единственный тонкий момент, у явы, особенно с фреймворками порог вхождения больше чем у остальных вариантов (ASP.NET, PHP, Python, Node.JS). Нельзя взять и написать на яве сайт не вникая в стек технологий, надо сначала немного познакомиться с теорией, но как только этот барьер преодолеете все станет очень просто.
Здравствуйте, pugv, Вы писали:
P>Да в том-то и дело, что команда знает в основном C++/C#.
Я бы предложил вашей команде разбить задачу на две:
— серверная часть на C++/C# (лучше С++), база данных на Postgre, доступ к данным только по HTTP(S)/REST (еще лучше по ODATA чтоб Excel использовать)
— Web клиентская часть на JS/jQuery/Bootstrap (возможно +Angular, но я бы не стал его использовать), статическая (без использования серверных приблуд)
Плюсы такого подхода:
— пишите на знакомом языке, не сильно меняя (но это как захотите) структуру данных;
— жесткое разделение разделение серверной и клиентской части упростит тестирование;
— клиентские приложения работают повсеместно (на смартфонах кэшируется статическая часть, т.е. вся!);
— можно написать дополнительное клиентское приложение на любом языке и на любой платформе (для вас, например, на C#/WPF).
Ваши советы лично мне кажутся чем-то из разряда "в предмете не разбираюсь, но мнение имею".
_>Но те, кто в бакэнде догадались применить TypeScript — сейчас смотрят на остальных как на лузеров. Т.е. если и выберешь nodejs — возьми TypeScript или аналоги.
И получить проблемы того, что этими инструментами пользуются "два" человека. Например, результат выдачи гугла по запросу "typescript + promises" весьма удручающий.
_>Java — В роли догоняющих уже лет 15. Как следствие ты успеешь написать портал на всех технологиях выше, и взявшись повторить его же на Java обнаружишь что они как раз сделали те фичи которые были у конкурентов.
Добро пожаловать из криокамеры. Если не сложно, то не могли бы вы назвать фреймворк, который из коробки поддерживает вебсокеты. Вот догоняющая 15 лет ява со спрингом почему-то это умеет.
Здравствуйте, pugv, Вы писали:
P>Коллеги, назревает необходимость переноса портала с ASP.Net/Oracle на Apache/Postgres. Импортозамещение так сказать. P>Кроме того там давно пора все переписывать. P>Так вот вопрос: на чем сейчас модно писать backend? Приложение не то чтобы high-load, но довольно развесистое, с кучей бизнес-логики. P>php/java/python/ruby? Интересуют pros/cons, ну и любые доводы тех, кто в теме.
Здравствуйте, anatoly1, Вы писали:
A>Добро пожаловать из криокамеры. Если не сложно, то не могли бы вы назвать фреймворк, который из коробки поддерживает вебсокеты. Вот догоняющая 15 лет ява со спрингом почему-то это умеет.
Mojolicious, например. WS же — не rocket science, вообще не проблема его уметь.
Здравствуйте, smeeld, Вы писали:
P>>Да в том-то и дело, что команда знает в основном C++/C#. S>Пишите на C++. Все нагруженные веб бекенды на С++, для управления соединениями, поступающими запросами S>(раскидывание по кластеру), передачей данных, с выводом в PHP/Python/Perl на которых скриптуются логики управления S>передаваемым и принимаем контентом.
Вообще-то, как причастный теперь к бэкэнду одного из самых больших Интернет-сервисов в мире, могу сказать, что это не совсем так.
Здравствуйте, hi_octane, Вы писали:
_>Ruby — Связка Ruby/RoR долгое время учила всех как надо делать это красиво. Все скопировали, в результате сейчас преимуществ около нуля.
Со всем согласен кроме этого. Все только пытались копировать, но каждый скопировал только какую-то часть, тем более на другой язык рубийные фишки так просто не скопировать. На PHP как всегда все время получалось что-то убожественное, питон пошел своим путем (Django). Стоит рассматривать фреймворки для nodejs, ASP.NET MVC и возможно груви, но все они заметно отстают, как в базовой части так и в подключаемых компонентах. Имеет смысл их применять только если команда знакома с рельсами хуже чем с ними либо реально необходимы преимущества статики. Про быстродействие говорить смысла нет, те, кто выбирает движок на форуме все равно очень не скоро подойдут к пределу быстродействия технологии.
Это не в порядке холивара, сам пытался объективно сравнить. С ASP.NET и RoR достаточно собак съедено, а незрелость нодовских фреймворков видна невооруженным взглядом.
