Речь не о "выборе первого backend языка", речь о том, что вы достигли в этом языке уровня Senior и хотите двигаться дальше:

👶🏾 Ката открытий – Python / PHP / Java / C# / Ruby / Node.js / Scala / Elixir

Это языки, с которых большинство начинает, они научат вас стандартам разработки (кто-то лучше, кто-то как Node.js), дадут возможность написать свои первые маленькие и средние+ приложения, но рано или поздно вы устанете от их неповоротливости и устарелости:

– жирный рантайм
– или отсутствие, или толстое управление многопоточностью
– отсутствие контроля за памятью
– долгие сборки (по статистике 90% людей перешедших с Java обнаружили свой второй язык пока ждали сборку своего Java приложения)
– отсутствие встроенных инструментов

👨🏾Ката скорости – Golang / Haskell

Тут уже стэк, который про скорость, тонкий рантайм и обязательно типизация.

Тут вы можете удобно и просто писать от мини приложений, до распределенного Highload и даже баз данных.

👨🏾‍🦳 Ката оптимизации – Rust / Zig

Когда готов пожертвовать простотой во имя скорости (благодаря memory management).

💀 Ката смерти – C / C++

Когда готов пожертвовать душой, во имя максимальной оптимизации.

🤡 Ката "ты совсем долбоеб?" – Python / PHP / Java / C# / Ruby / Node.js

Если ты прошел весь этот путь и вернулся обратно, ты или гений, или конченный

>Речь не о "выборе первого backend языка"

А если речь всё же об этом ?

Вот здесь

Тут скажу следующее:

1. Вокруг этого не образовалось никакой экосистемы готовых решений и плагинов, а главное коммьюнити и вакансий

То есть с RoR, Django, Asp, Symfony сравнивать нельзя

2. Непопулярно и никогда не станет, потому что слишком давно существует от слишком известного человека

И это в очередной раз проигрыш вышеназванным

3. Субъективно, но если что-то написано полностью на JS без TS то оно имеет право на существование только в случае платформы для разработки (Svelt как пример)

4. Там написано сначала «lightweight”, а потом самые тяжелые паттерны в мире «DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach;»

Превращать Ноду в Java / C# - очень плохая идея (говорю как человек, который когда-то это делал)

Ну и впринципе Шемсединов крутой и есть у него много интересных идей, но его стиль из эпохи больших решений, которые себя не оправдали, поэтому его точно надо послушать, но только чтобы понимать «как было тогда», а потом понять «ах вот почему мы сейчас делаем не так»

Правильно, сейчас же можно накинуть еще железа и х*ярить тонны бойлерплейта и говнокода сразу в прод

Если это к защите о "DDD, layered (onion) architecture, DI, SOLID and GRASP principles, contract-based approach" то они предполагают такую далекую абстракцию от источника данных и железа, что тебе приходится работать неоптимально с точки зрения инфры, чтобы поддержать "чистоту бизнес логики"

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

А вот когда ты перестаешь создавать кучу слоев абстракций и в HTTP контроллере (ну максимум выделить функции от интерфейса например в "features") пишешь 1 оптимальную SQL команду на UPDATE FROM SELECT, итерируешь по результатирующему курсору отправляя каждый готовый кусочек данных в сокет HTTP ответа, ты тратишь минимум ресурсов, так еще и логика намного понятнее

Кому понятнее ? Инженеру за рейт от 5000$ ?

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

А если нужен будет супер хайлоад , то вход пойдет С или Раст

Хорошо, рад что это кому-то помогает

Так может есть что то , что может больше помочь и вы об этом знаете?

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

1.Как не терять темпы добавления новых фичь?

2.Как организовать код и совместную разработку?

3. как делать быстрый онбординг новых инженеров в команду?

Я постарался описать все лучшие техники удобного, простого и понятного написания кода и сложил их в книгу https://fop.davidshekunts.ru/

Не буду говорить что это «для всех», это для тех кому откликнется

Если не откликается тогда можно попробовать что-то другое

Сейчас мы командой из 7 бэков и 3-х фронтов пилим уже 3 High load проекта, а до этого делали на базе подобный методологии в компании где 300 разработчиков и тоже хорошо работало

Ознакомлюсь

Буду рад комментариям)

Я советую C# хотя сам не использую. Советую, потому что весь материал про архитектуру обычно идет с примерами на C# либо Java (но первый чаще). И как-то дела с этим обстоят хреново у тех кто начал с Node.js.ts и как-то дорос выше мидла, по моим наблюдениям

Да, люди начавшие с Node.js имеют шанс быть неплохими разрабами, только если попали в руки профи (но это так на любом стеке), поэтому в 90% случаев уровень разрабов крайне низкий

Java – просто у меня личная ненависть, C# – даже когда-то писал, в целом, очень хороший язык

Да, на любом стеке важно найти источник правильного опыта, НО на C# и Java гораздо легче, даже несознательно встать на путь истинный. Берем книгу по ASP.net и как правило там хоть как-то коснуться Clean Arch., DDD, расскажут почему такая практика хороша, а такая-то приведет к оверпостингу и т.д. В общем там реально все нацелено на энтерпрайз. Очень много людей из серьезных сфер которые готовы делиться опытом. Курсы, книги про Node.js это про микросайт или как сделать чтобы нечто заработало. Просто технические детали.
Я считаю что Java со слишком сложной судьбой: сначала он отставал, потом его ускоренно начали лепить, кидали постоянно из рук в руки. Лет пять назад вообще непонятно было объяснить откуда брать эту яву (сейчас есть проще - temurin). Поэтому говорю просто, в 2023 году начинайте с C#.

(если учитесь сами по книгам, статьям и курсам)

... и исходных код посмотреть интересных качественных проектов это тоже C#

После привития хороших практик пойдете на другие ЯП и платформы

Про простое решение из моего опыта 😋
Пока редис в режиме single node это схема кажется простым решением, потом это станет паттерн distributed lock, а потом с увеличением rps проблемой распределения партиций. В итоге самое простое будет вертикальное масштабирование такой системы, потому что такова цена самого решения.
Лучше никогда не использовать блокировки в растущем месте, иначе стоимость поддержки этого решения будет геометрически расти.

Keep-alive был включён? Звучит, как 2 варианта, не включен keep-alive и не было обработчика на ошибку сокета с закрытием, чтобы освободить инстанс сокета в коде и создать новое подключение.

И как может в неработающем сокете приходить сообщение, это наверное буферизированное сообщение в сокете висело и при чтении стрим некорректно завершал его получение, что оно всё ещё оставалось в стриме необработанным?

«А вот когда ты перестаешь создавать кучу слоев абстракций и в HTTP контроллере (ну максимум выделить функции от интерфейса например в "features") пишешь 1 оптимальную SQL команду на UPDATE FROM SELECT, итерируешь по результатирующему курсору отправляя каждый готовый кусочек данных в сокет HTTP ответа, ты тратишь минимум ресурсов, так еще и логика намного понятнее»

А зачем тогда нужна абстракция «база данных»? По этой логике, можно в файликах всё хранить и самому строить индекс. Зачем всё в строки преобразовывать каждый раз? Столько ресурсов сгорает! 😂

Да, 100%, если встанет вопрос с тем, что single instance не выдерживает, будем искать другое решение

Но я рассчитал RPS даже при росте нагрузки и мы еще очень долго не столкнемся с проблемами

Я главное хотел подсветить противодействие "best practice" и "вашей конкретной ситуации" и что если позволяют знания и решение достаточно простое, лучше ориентироваться на него, а не пытаться втащить какой-то гигантский best-practise

Обработчик был, keep-alive проверю

Сообщение не приходят, сообщения в него спокойно уходят

Там по-дороге есть еще один multiplexer, который переключает трафик между системами, есть предположение, что именно на нем зависают сокеты и он их не закрывает, тем самым и сообщений close / error / end не поступают до нас и при этом мы можем спокойно писать в сокет

Если я правильно понял вопрос, то ответ: "База данных" – это абстракция в виде технологии, а я говорю об абстракциях в твоем собственном коде

Поэтому БД – это натуральная сложность, а "свои слои абстракции" – это искусственная сложность (писал об этом в книге)

И зная, что ты любишь ФП, сразу скажу комментарий: когда мы делаем слоистую работу с IO (сначала IO, потом логика, потом IO, и так далее) то это хороший подход, потому что он не про "абстракцию", а про control-flow, где мы хотим больше оставаться в области чистых функций

Пример: паттерн "репозиторий" абстрагирует БД, а если ты делаешь SQL запрос, потом его значение передаешь в чистые функции, потом результат функций опять в SQL запрос – это просто разделение флоу работы с IO

"Зачем всё в строки преобразовывать каждый раз?" – не совсем понял)

«Пример: паттерн "репозиторий" абстрагирует БД, а если ты делаешь SQL запрос, потом его значение передаешь в чистые функции, потом результат функций опять в SQL запрос – это просто разделение флоу работы с IO»

Репозиторий не нужно делать или нужно? Я что-то не понял. 🤔

«"Зачем всё в строки преобразовывать каждый раз?" – не совсем понял)»

SQL про строки же. Сначала преобразуешь данные в строку запроса, потом её посылаешь в БД. С ответом та же ситуация, получаешь строки и парсишь. 🥸

Я много лет использовал паттерн "репозиторий" но со временем понял, что он дает больше проблем, чем помощи (если хочется подробнее, то лучше опишу отдельной статьей)

"SQL про строки же." – если тебе нужно сделать запрос в БД (если у тебя SQL БД), тебе надо будет сформировать SQL с правильной последовательностью аргументов и приложить вместе с аргументами в коннекшен, несомненно стоит делать это через Query Builder (kysely) или генеративный (sqlc)

А если ответ от БД тебе надо тоже как-то преобразовать, ты будешь его получать из курсора, модифицировать и отправлять клиенту

Или о чем ты?

Я к тому, что можно же в файлах хранить байтики, зачем эта прослойка. 😁

Зачем строить абстракные запросы и использовать сложные сериализации/десериализации? Захотел получить сущность — прочитал файл, спарсил в объект и готово. 😁

Вообще, можно так делать, просто потом возникнут вопросы скорости чтения и записи, конкурентности, размера хранилища, сложности поддержания и найма

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

Как сайд-эффект станешь автором новой крутой БД 😎

Если возникнут вопросы производительности и т.п., то можно использовать lmdb или аналоги. И репозиторий будет крайне простым. 😁

Зато не надо искать DBA специалиста по SQL. Сразу пул специалистов расширится. 😂

Я кстати сейчас изучаю исходник https://github.com/dgraph-io/badger, очень интересные чтиво