Serverless #2: Наносервисы?

[@pepapigbro2938]

Ты объясняешь как боженька, Спасибо

[@THEFIGHTMOMENTS]

Такое чувство как будто вернулся в универ на пары

[@Awarskiy]

А зачем мучиться с NodeJs, если с PHP все так хорошо? Чтоб был единый язык, для "легкой" поддержки frontend`а и backend`а?

[@JavaScriptNinja]

с РНР не все так хорошо :)

[@darktmdarkness6952]

Ровно по той простой причине, что PHP хорош для мелких сайтов и интернет магазинов. Хотите блог, в нем много статики и нет высокой нагрузки, то нет проблем PHP, хорош. Но чем больше вы масштабируете свое приложение, чем больше приходится на него нагрузки и динамики, тем больше PHP ловит проблем и тем становится хуже. По факту, если у вас сервис типо гугл почты + какой-нибудь магазин средней руки + платежный сервис, и это все это засунуто под одну крышку, то условный Node.js в этом деле побеждает условный PHP с разгромным счетом, без каких либо шансов для пыхи. Пример можете масштабировать на любой мессенджер, биржу крипты и прочие динамически радостные вещи с высоким откликом для пользователя. Добавим еще нагрузки под пару миллионов запросов в день и тут даже нода становится не очень таким вариантом. Вообще в 2018 году, все крупные компании так или иначе седевшие на пыхе, ползут на go. Это такая улучшенная и прокачанная версия ноды от гугла, только умеющая в многопоток, компилирующаяся в бинарку и предназначенная для создания крутых веб-приложений под высокой и сверхвысокой нагрузкой, но могущая вообще во все.

[@musicits_fun]

После front-end мучаться с nodejs не приходится. Когда ты работаешь с одним и тем же языком, по моему это логично и удобно и естественно. И плохо, что исторически получилось иначе. Тогда нужно для фронтэнда нужно было сделать php.

[@kemnet]

@@musicits_fun вот было бы здорово научиться все делать каким-нибудь одним инструментом, молотком например :). Для разных задач придумали разные инструменты.

[@musicits_fun]

@@kemnet не логичный пример. nodejs - решает все потребности/задачи на сервере, что и php. Зачастую, такие выводы делают люди, просто не делавшие проекты на nodejs и webjs одновременно. Где требуется мощный и front end и back end. Удобство даже ещё в том, что библиотеки одни и те же, даже многие функции те же можно использовать. А это значит, что изучать меньше, внедряешь быстрее, ошибок меньше, качество кода лучше. Я использую сейчас в проекте nuxt + firebase. Поэтому часть кода обращения к бд, авторизации, файлам и т.д... происходит часть в front end, часть в backend. И за счет nuxt грань между backend и frontend очень сильно размывается. Один и тот же код, прямо в одном файле, запускается сначала на backend, а затем на fronend. Естественно используются те же подключенные библиотеки в этом одном и том же файле. Несколько раз были ситуации, когда код переносился из backend, в frontend и делалось это одним ctrl+c и ctrl+v.

[@alexanderdmitriev8525]

Эрланг уже давно изобрели, а js программисты только приходят к его архитектуре :)

[@JavaScriptNinja]

Конкурентное программирование эрланге (да, да, я писал плагины для ejabberd на нем) имеет мало общего с концепцией серверлесс

[@alexanderdmitriev8525]

​@@JavaScriptNinja плагины это конечно хорошо, но концепция OTP как раз описывает структуру похожую на serverless. gen_server мало чем отличается от облачных функций идеологически - изолированный стейт, запуск экземпляров, эвенты и т.п. Расширяйся горизонтально пока память не закончится и так же легко "отпускает" память когда не нужно. Разница только в том, что запускается это все в эрланговсткой вм , а не гдето в облаке.

[@kemnet]

@@JavaScriptNinja модель акторов представляет некоторую среду в которой запущены нано сервисы (акторы), которые умеют обмениваться сообщениями, только помимо эта среда дает еще гарантии однопоточного выполнения в рамках каждого актора и локальное состояние, которое защищено таким образом от конкуретного доступа. В случае serverless каждая функция это аналог актора, облачный провайдер это среда их выполнения, а состояние в этом случае хранится во внешних сервисах провайдера. Вот только плотность размещения акторов - миллионы на какой-нибудь t3.small, а сколько будет стоить запустить миллионы lambda ? Для редких операций хорошо, но говорить что это подходящий вариант для масштабирования нагрузки можно только с большой натяжкой www.rdegges.com/2018/to-30-billion-and-beyond/

[@JavaScriptNinja]

@@kemnet сравнивать инстанс лямбды с актором некорректно. Я думаю вы сами прекрасно понимаете почему. Что касается плотности упаковки - над этим работают, сегодня 5 видео с этой серии про изоляты как раз про это

[@kemnet]

@@JavaScriptNinja c акторами я работал гораздо больше чем с лямбдами, поэтому и хотелось бы услышать преимущества последних. Про изоляты посмотрел, очень интересно, но задержка с 100-200мс против микросекунд в случае акторов это совсем разные области применения, да и плотность несопоставима даже в случае изолятов. Javascript очень сильно продвинялся за последние годы, но все равно он подходит не для всех задач, как и лямбды, в этом нет ничего плохого, я как раз и хочу понять где стоит применять js и лямбды