На чем бы сваять web UI и сервер с нуля?

[Oleg-NY]

Почитал тут разборки насчет разных фреймворков и патернов. Возник вот такой простой вопрос: а если бы не было никаких начальных условий (ну разве что сервер на Linux), то что бы вы выбрали в качестве front-end и back-end?
Понятно, что нынче модно микросервисную архитектуру между ними устраивать, но вот выбор фреймворка по обе стороны часто зависит от того, чем конкретный девелопер владеет лучше всего. А если бы была полная свобода выбора и возможность сваять проект "чтобы в душе парение эдакое..."?
В инете полно всяких сравнений типа "Angular vs React vs Vue", а также Node.JS vs Django плюс еще мелкософт вносит сумятицу с воим Core...
Опять же, ИМХО, на стороне сервера как-то не культурно нынче без ORM ваять, а значит это выбор Entity Framework против Django против много чего еще.
Плюс если есть желание полностью оутсорснуть public часть UI (application) включая сервер для него, а внутреннюю копоративную ваять in-house, выбор серверной платформы становится еще более интересным (если только, конечно, не принять, что общего между ними будет только DB).

[liamkin]

пробуйте WordPress - я про него хорошее читал. Сайт фирмы schiit.com на нем сделан. Можете зайти посмотреть.

[KVA]

но вот выбор фреймворка по обе стороны часто зависит от того, чем конкретный девелопер владеет лучше всего. А если бы была полная свобода выбора и возможность сваять проект "чтобы в душе парение эдакое..."?

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

Так же что бы говорить конкретно о технологиях надо больше вводных как о самом UI, так о backend. А иначе это просто сотрясение воздуха.

[Oleg-NY]

Девелоперов можно набрать каких угодно с какой угодно квалификацией. Это всего-лишь вопрос денег...
Тут важно проект зачать правильно! О том и речь... ))

Не знаю какие именно вводные могут так уж сильно повлиять на выбор UI фреймфорков. Скорее back-end больше зависит от объемов данных, транзакций в секунду и наверное чего-то еще, но в данном случае все достаточно средненько - никаких больших чисел так, что какой-нибудь open source типа PostgreSQL вполне должен справиться.

Я вполне себе представляю как множно было бы нечто подобное сделать, но хотелось бы услышать возможно неожиданные мнения, особенно учитывая разнообразие выбора и различных сочетаний начиная от сваять все на Django плюс немного JS до зоопарка в виде Angular/React/Vue + Node.JS/.NET Core или даже WPF для внутренних приложений.

[KVA]

Девелоперов можно набрать каких угодно с какой угодно квалификацией. Это всего-лишь вопрос денег...
Тут важно проект зачать правильно! О том и речь... ))

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

Не знаю какие именно вводные могут так уж сильно повлиять на выбор UI фреймфорков. Скорее back-end больше зависит от объемов данных, транзакций в секунду и наверное чего-то еще, но в данном случае все достаточно средненько - никаких больших чисел так, что какой-нибудь open source типа PostgreSQL вполне должен справиться.

Вы сильно недооцениваете UI и сложности связанные с ним. Как back-end зависит от объемов данных, транзакций в секунду так и UI зависит от количества юзеров, сложности самого UI и т.д. Если вам нужен сайт с 10 статическими страницами это одно. Если две страницы с формами с тремя полями это другое. UI аля Salesforce это третье. Соответственно фреймворки будут разные.

вполне себе представляю как множно было бы нечто подобное сделать

Выделенное выше как то не вяжется одно с другим.

но хотелось бы услышать возможно неожиданные мнения, особенно учитывая разнообразие выбора и различных сочетаний начиная от сваять все на Django плюс немного JS до зоопарка в виде Angular/React/Vue + Node.JS/.NET Core или даже WPF для внутренних приложений.

Хотите неожиданного - пожалуйста. Напишите на Elixir Phoenix. Phoenix is a web development framework written in the functional programming language Elixir. Как можно написать UI на функциональном языке я не представляю, но я видел результат и впечатлен.

[Oleg-NY]

Девелоперов можно набрать каких угодно с какой угодно квалификацией. Это всего-лишь вопрос денег...
Тут важно проект зачать правильно! О том и речь... ))

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

Ну да, конечно. А как оценивать принятые им решения? У каждого архитектора своя правда. И все равно все скорее всего будет сделано как умеет, а не как лучше...

Не знаю какие именно вводные могут так уж сильно повлиять на выбор UI фреймфорков. Скорее back-end больше зависит от объемов данных, транзакций в секунду и наверное чего-то еще, но в данном случае все достаточно средненько - никаких больших чисел так, что какой-нибудь open source типа PostgreSQL вполне должен справиться.

Вы сильно недооцениваете UI и сложности связанные с ним. Как back-end зависит от объемов данных, транзакций в секунду так и UI зависит от количества юзеров, сложности самого UI и т.д. Если вам нужен сайт с 10 статическими страницами это одно. Если две страницы с формами с тремя полями это другое. UI аля Salesforce это третье. Соответственно фреймворки будут разные.

Вполне возможно, ибо я не UI девелопер. Я лишь хотел сказать, что я не знаю в каких терминах или параметрах можно описать такую сложность. Понятно, что то, что можно сделать в WPF, например, далеко не всегда реализуемо в браузере на чем бы то ни было если только не сменить всю концепцию визуализации данных и интерактивности. А при чем тут "количество юзеров" к UI, кстати?
А если говорить о конкретике, то как я сообщал ранее, в проекте не предполагается масса пользователей (это не public сервис) с улицы.

вполне себе представляю как множно было бы нечто подобное сделать

Выделенное выше как то не вяжется одно с другим.

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

но хотелось бы услышать возможно неожиданные мнения, особенно учитывая разнообразие выбора и различных сочетаний начиная от сваять все на Django плюс немного JS до зоопарка в виде Angular/React/Vue + Node.JS/.NET Core или даже WPF для внутренних приложений.

Хотите неожиданного - пожалуйста. Напишите на Elixir Phoenix. Phoenix is a web development framework written in the functional programming language Elixir. Как можно написать UI на функциональном языке я не представляю, но я видел результат и впечатлен.

Экзотика это хорошо, конечно, но замучаешься искать кадры на рынке и придется в результате писать все самому... Хотелось бы все же оставаться в main stream.

Вот например нынче в моде microservices architecture которая не особо-то отличается технологически, а скорее идеологически, но, как говорится, есть нюансы. Наверняка есть сочетание фреймворков, в которых это реализуется легко и непринужденно.

[tessob]

Для фронта взял бы:

• Nginx для раздачи статики и проксирования
• Angular CLI, т.к. заставляет всех ходить строем
• Docker, где все это будет жить

В результате будет фронт, который хорошо скалируется горизонтально. С ростом числа пользователей поднимается еще больше дешевых виртуалок. С бекэндом немного сложнее, т.к. очень зависит от реализуемой логики. Но за основу бы, наверное, брал Spring Boot на Netty + PostgreSQL с реактивными драйверами.

[Komissar]

Drupal

[KVA]

То нужны неожиданные мнения, то мэнстрим. Вы уж определитесь там.

Если нужен мейнстрим то Angular 8 + Asp.Net core с любой базой по вкусу.

[liamkin]

Ну еще про REACT слышал хорошее. А так, если бы я вдруг стал фрилансером-вебмейкером для многих-нескольких компаний, взял бы Wordpress. Сам-то я на Яве пишу, базы данных знаю, могу ручками все написать - но ленюсь. За вебсайт много не дадут. Лучше брать полуготовое решение и допиливать мелкие детали.

[Oleg-NY]

Наверное я не совсем ясно сформулировал суть проекта, ибо это совсем не про content management.
Это все про довольно простой web UI к, по сути, базе данных (CRUD, configuration, etc.), вокруг которой вертятся некие real-time процессы.
Понятно, что никто напрямую к BD ходить не будет. Скорее всего это будет чистый REST API поверх ORM, но не исключен и какой-нибудь message-oriented middle-layer тоже.
Данный UI - вообще не основной "прикол" проекта, а чисто пользовательский интерфейс к системе, который в стародавние времена был бы скорее всего написан на Windows Forms или вроде того. Просто нынче модно UI ваять в web, да и оутсоурснуть довольно легко координируясь только через Swagger, например.
Поскольку есть свобода выбора фреймворков как front-end, так и back-end, то и вопрос состоит в том, что было бы здесь наиболее гармоничным решением.

[Oleg-NY]

То нужны неожиданные мнения, то мэнстрим. Вы уж определитесь там.

В пределах разумного! ))

Если нужен мейнстрим то Angular 8 + Asp.Net core с любой базой по вкусу.

Я все еще подозрительно отношусь в Core, хотя и говорят, что он стал вполне себе полноценным и стабильным.
Есть какие-нибудь веские аргументы "за" по сравнению с тем же Django хотябы?

[Oleg-NY]

Кстати вот тут предлагают Go для сервера. Чем не экзотика? ))
Надо бы только понять что для него есть уже в качестве фреймворков для web.

[Oleg-NY]

Для фронта взял бы:

• Nginx для раздачи статики и проксирования
• Angular CLI, т.к. заставляет всех ходить строем
• Docker, где все это будет жить

Тут вопросов нет. Поскольку между front- и back-end чистый REST, то по-другому и делать нет смысла, будь-то докер или какой другой контейнер. Про "ходить строем" да, читал и скорее всего это правильно, осбенно в свете аутсорса. Я бы не рискнул какому-нибудь условному индусу отдать проект на Питоне, например. Хотя мне тут вчера один товарищ из Бангалора такую фортран-программу выдал на C#, что... талантливые они все-таки все там! )))

В результате будет фронт, который хорошо скалируется горизонтально. С ростом числа пользователей поднимается еще больше дешевых виртуалок. С бекэндом немного сложнее, т.к. очень зависит от реализуемой логики. Но за основу бы, наверное, брал Spring Boot на Netty + PostgreSQL с реактивными драйверами.

Тут вы меня озадачили. Надо будет почитать... )

[mister-X]

А чем вам JHipster неподходит. там почти все есть. 80% кода generated production ready! Хочешь angular, or react or even your custom UI. Docker or cloud.

Sent from my SM-G950U using Tapatalk

[KVA]

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

А зря. Давно стабильный и полноценный. Я на следующей неделе вторую апликуху на Core релизить буду (internal trading system). Первая уже год на автопилоте работает и кушать не просит. Я иногда вспоминаю о ней, логинюсь и удовлетворенно замечаю что все порядке и ничего не отвалилось.

Есть какие-нибудь веские аргументы "за" по сравнению с тем же Django хотябы?

Безумно веский аргумент - я Core намного лучше знаю чем Django.

Еще раз дам совет. Делайте на том что знаете лучше. Идеального ничего нет в природе - что-то лучше что-то хуже. Если же хотите поучится чему-то берите что хотите и пишите на том. Для ваших вводных разницы не будет никакой.

[3DD]

React + AWS

[tessob]

Кстати вот тут предлагают Go для сервера. Чем не экзотика? ))
Надо бы только понять что для него есть уже в качестве фреймворков для web.

Не скажу за всю Одессу, но я начал остывать к Go. По крайней мере пока они не выкатят 2-ую версию с генерикам я больше не рискну тащить его в продакшен. Пока, для меня в GO две большие проблемы:
1) Слабая поддержка управления зависимостями. Сейчас они наконец ушли от GOPATH и пришли к .mod файлам, но с версионированием зависимостей пока еще явные проблемы. По факту с Go почти не реально организовать команду больше 3-4 человек работающих над одним проектом.
2) Убогий, нет УБОГИЙ полиморфизм! В конечном итоге ваше приложение скатится к единственному передаваемому типу interface{}. Чтобы это понять, представьте, что у вас в яве все методы будут принимать и возвращать Object.
3) Это скорее моя персональная боль, но в Go очень убогие аннотации. Все это нужно писать в одну строчку с очень неоднозначным синтаксисом.

В плане фреймворков там тоже все не однозначно. Нормального ORM нет. Нормальный сервер будет сильно уступать тому же Netty.

Го хорош, если вам нужно: запилить мультиплатформенный CLI или запилить микросервис, который делает что-то одно, например - что-то конвертирует между форматами или опрашивает другие сервера или что-угодно сопоставимо маленькое, что вы например хотите поднимать как лямбду в AWS или как таску в Кубурнетис.

[3DD]

Расширю "React + AWS":
Front-End:
1. React (state management: Redux or Context API, React hooks); CSS: SASS or SCSS or LESS; Tests: JEST
2. React native for mobile

Back-end:
AWS Gateway API, Lambda, etc

[Oleg-NY]

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

[3DD]

на здоровье

[liamkin]

ну если вам стандартное трехуровневое бизнес приложение с базой данных - то тогда другое дело. Я думал вебсайт абстрактный.
Ява с базой данных какой-нибудь, я Оракл люблю, если деньги есть.
А если хотите странного, то есть Nginx модификация OpenResty, там можно скриптовать на Lua - например Lua будет выдавать вам JSON из базы данных, а ваш Javascript web framework - рисовать его на экране юзера. Преимущества- очень собака будет быстрой, Lua имеет JIT, что в сочетании с быстротой Nginx будет бомбой. Будет бить любой PHP раз в 10.

[Oleg-NY]

Oracle в данном случае это как реактивный двигатель дельтаплану! )) Думаю PostgreSQL должен справиться...
Опять же, вся перелесть в ORM в том, что можно быстро соскочить если что!

Насчет скорости микросервисов, странно было бы сравнивать с PHP (он разве что в России еще настолько популярен, что кому-то и может придти в голову как вариант...)
Что насчет сравнения с Django например (если говорить о скриптах) или .NET core?

Кстати, скорость OpenResty+Lua поди от прямых sql к базе или все-таки с ORM?

[KVA]

Опять же, вся перелесть в ORM в том, что можно быстро соскочить если что!

Xa-xa 3 раза. Это как же надо напортачить с выбором базы чтобы потом по-живому соскакивать на что-то другое?

Насчет скорости микросервисов, странно было бы сравнивать с PHP (он разве что в России еще настолько популярен, что кому-то и может придти в голову как вариант...)
Что насчет сравнения с Django например (если говорить о скриптах) или .NET core?

Кстати, скорость OpenResty+Lua поди от прямых sql к базе или все-таки с ORM?

Сколько у вас юзеров или запросов к базе в секунду предвидится? Без этой информации выбор базы или сравнение скоростей прямых sql с ORM premature optimization.

[Oleg-NY]

Опять же, вся перелесть в ORM в том, что можно быстро соскочить если что!

Xa-xa 3 раза. Это как же надо напортачить с выбором базы чтобы потом по-живому соскакивать на что-то другое?

Что значит "по-живому"? Нормальное развитие продукта, ИМХО! Прототип вообще на SQLite работал и ничего! думаю и продакшн потянул бы, но лучше сразу перейти на взрослый вариант. Хотя будет интересно и SQLite потестить под рабочей нагрузкой... Напортачить это когда не работает вообще или заплатить кучу денег за Oracle и использовать на 10%.

Насчет скорости микросервисов, странно было бы сравнивать с PHP (он разве что в России еще настолько популярен, что кому-то и может придти в голову как вариант...)
Что насчет сравнения с Django например (если говорить о скриптах) или .NET core?

Кстати, скорость OpenResty+Lua поди от прямых sql к базе или все-таки с ORM?

Сколько у вас юзеров или запросов к базе в секунду предвидится? Без этой информации выбор базы или сравнение скоростей прямых sql с ORM premature optimization.

Юзеров как раз не много, да и Web UI - не основная функция проекта. Чисто менеджмент и мониторинг. Потому и простор выбора фреймворка для UI такой, что все равно, лишь бы работало и было не страшно оутсоурснуть...
Вот для back-end требований куда больше потому, как практически real-time и время отклика от REST API довольно критично (не больше секунды при теоретической пиковой нагрузке 256 одновременных транзакций). Каждая транзакция (помимо складывания всего и вся в лог, что само по себе отдельная задача) это - довольно простая выборка из DB, обработка и отсылка по внешним REST API.