Привет

Oleg-NY писал(а): Пт июн 07, 2019 3:21 pm Я все еще подозрительно отношусь в Core, хотя и говорят, что он стал вполне себе полноценным и стабильным.

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

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

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

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

React + AWS

Oleg-NY писал(а): Пт июн 07, 2019 6:18 pm Кстати вот тут предлагают Go для сервера. Чем не экзотика? ))
Надо бы только понять что для него есть уже в качестве фреймворков для web.

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

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

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

Расширю "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

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

на здоровье

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

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

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

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

Oleg-NY писал(а): Пн июн 10, 2019 1:27 pm Опять же, вся перелесть в ORM в том, что можно быстро соскочить если что!

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

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

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

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

KVA писал(а): Пн июн 10, 2019 1:49 pm

Oleg-NY писал(а): Пн июн 10, 2019 1:27 pm Опять же, вся перелесть в ORM в том, что можно быстро соскочить если что!

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

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

KVA писал(а): Пн июн 10, 2019 1:49 pm

Насчет скорости микросервисов, странно было бы сравнивать с 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.

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

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

Во-вторых, если вам база нужна преимущественно для чтения, то постгреса вам будет за глаза. Только, мой совет - идите срезу в облако. Тот же Амазон из коробки сейчас поднимает рид-онли реплики для постгреса и меняет железо под ними по требованию. Все это в несколько кликов. Если вы решите делать это своими силами, то столкнетесь с более острой проблемой - как найти в проект вменяемого DBA.

tessob писал(а): Вт июн 11, 2019 4:44 am Если вы решите делать это своими силами, то столкнетесь с более острой проблемой - как найти в проект вменяемого DBA.

Oleg-NY, колитесь это проект для себя с нуля или на дядю работа? И кто есть в наличии прямо сейчас? От этого и будем плясать подбирая вам технологии и команду.

tessob писал(а): Вт июн 11, 2019 4:44 am Во-вторых, если вам база нужна преимущественно для чтения, то постгреса вам будет за глаза. Только, мой совет - идите срезу в облако. Тот же Амазон из коробки сейчас поднимает рид-онли реплики для постгреса и меняет железо под ними по требованию. Все это в несколько кликов. Если вы решите делать это своими силами, то столкнетесь с более острой проблемой - как найти в проект вменяемого DBA.

а можете провести простой эксперимент? в табличку без индексов из тройки-четверки полей заинсертить 2-3 млн записей, удалить и еще пару раз повторить. оставить одну запись. как быстро "фулскан" одну запись теперь вытянет?
в гуглоклауде их mysql превращается в тыкву после такого теста, селект 1 записи минуты занимает, при том что датафайл таблички порядка 180 мб.

tessob писал(а): Вт июн 11, 2019 4:44 am
Во-первых, аутсорснуть - это всегда страшно. Я много раз думал, что хуже чем сейчас накодить уже не возможно... но Вы знаете, есть таланты, которые меня снова и снова переубеждали.

Во-вторых, если вам база нужна преимущественно для чтения, то постгреса вам будет за глаза. Только, мой совет - идите срезу в облако. Тот же Амазон из коробки сейчас поднимает рид-онли реплики для постгреса и меняет железо под ними по требованию. Все это в несколько кликов. Если вы решите делать это своими силами, то столкнетесь с более острой проблемой - как найти в проект вменяемого DBA.

Я вас прекрасно понимаю, но... я не могу все один делать тем, более, что UI рисовать и кодить просто не моё. А аутсорсить тоже надо с умом. Индия отпадает. Есть пара вариантов в России, но "будем посмотреть"! Поскольку UI - не соль проекта, то и риск не велик. В крайнем случае доделаем/переделаем... ))

KVA писал(а): Вт июн 11, 2019 1:05 pm

tessob писал(а): Вт июн 11, 2019 4:44 am Если вы решите делать это своими силами, то столкнетесь с более острой проблемой - как найти в проект вменяемого DBA.

Oleg-NY, колитесь это проект для себя с нуля или на дядю работа? И кто есть в наличии прямо сейчас? От этого и будем плясать подбирая вам технологии и команду.

Всякий проект это и на дядю и на себя. В части последнего собственно и вопрос был изначально про технологии. Любую подобную возможность надо использовать для собственного обогащения как материально, так и интеллектуально. )) Если бы было 100% "на дядю" (шабашка?), то и сомнений бы не было - делаешь на том, что умеешь, дабы оптимизировать единственный показатель деньги/время.

Команду будем подбирать, когда принесут чемоданы денег, а пока только технологии и желательно open source. Не догоним, так согреемся! ))