Comments 24
Спасибо! Очень интересно, как раз тоже искали такую возможность
Вы написали, что клауд функции не являются универсальным решением. Можете ли вы привести примеры задач, для которых они наиболее подходят?
Сами клауд функции являются универсальным решением, просто другой подход к решению задач. Но в таком изолированном виде они годятся только для очень ограниченного списка задач, честно говоря, не приходит в голову других задач, кроме тех, что я описал. А так можно писать телеграм бота на клауд функции. У Google Cloud из коробки можно Next приложение развернуть. Как раз хотелесь бы чтобы кто-то поделился опытом такого изолированного использования.
а как происходит мониторинг и отладка клауд функций? прямо там же в яндекс клауде получается?
Вообще, есть такой пакет: https://www.npmjs.com/package/@yandex-cloud/serverless-live-debug
Но я отлаживал через TDD, а когда что-то непонятное было, то да в яндекс клауде много инструментов. Как и приведенный мной, тоже хотелось бы опробовать, вероятнее, если будет проект с состоянием на сервере, то придется воспользоваться им, а в моих кейсах не было необходимости.
Спасибо, звучит здорово. А какой принцип работы cloud-функций?
при каждом вызове поднимается nodejs, обрабатывает запрос и потухает через какое-то время, если не приходит новый запрос. Но лучше почитать об этом в документации.
То есть по факту народ заново изобретает CGI?
Да.
Основное отличие — биллинг по времени исполнения. Провайдеру это удобно, так как он может исполнять функции на простаивающем оборудовании, и за счёт этого давать привлекательные цены. Но не у всех провайдеров получается хорошее соотношение, как обычно нужно считать, потому что для некоторых задач виртуалка будет дешевле.
Наконец-то я поняла, зачем нужны клауд-функции, спасибо?
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
В М2 есть строгое разделение на бэкендеров и фронтендеров, как и во многих компаниях. Это вызывает много сложностей, одна из которых — необходимость договариваться, а разработчики — далеко не всегда самые общительные люди.
Есть решение. Нужно придумать новую роль в команде, которая будет объединять между собой бэкендеров и фронтендеров, например, FrontBack, по аналогии с DevOps. :)
То есть то что фронты стали писать бакенд. Это какое-то чудо, и достижение которым следует поделится с миром, при том что бакенд команда имеется.
А я вам скажу, что это не чудо, и не достижение. Это провал вашего менеджмента, который вы разгребаете.
А какие этот может иметь негативные последствия? У вас был опыт?
Опыта такого к счастью не было.
А какие могут быть негативные последствия еще Иван Андреевич Крылов в своей басне обозначил)
Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник,
И дело не пойдет на лад.
Да и примечено стократ,
Что кто за ремесло чужое браться любит,
Тот завсегда других упрямей и вздорней:
Он лучше дело все погубит,
И рад скорей
Посмешищем стать света,
Чем у честных и знающих людей
Спросить иль выслушать совета.
это басня и иногда имеет смысл. но есть и другие примеры: например, Ломоносов, Эйнштейн. бекендеры не рождаются бекендерами, это не передается по наследству, а учиться никогда не рано.
Но главное, если разработчик надел на себя колпак фронтендера или бекендера и больше ничего слышать не желает, то это не разработчик, а переводчик с человеческого языка на компьютерный. Серьезный разработчик все равно так или иначе разбирается в смежных областях и разбирается в прикладных областях. Задачи в любой области бывают разной сложности, а с точки зрения бизнеса важно чтобы задачи решались как можно быстрее и как можно быстрее приносили деньги. и если в какой-то момент возникает перекос в задачах бекенд или фронтенд, если он кратковременный, то вопрос найма, а это тоже задача у которой есть цена или затраты обычно не стоит, а просто часть команды простаивает, а другая часть команды задерживает прибавление полезной ценности. Люди еще и болеют. И в такой момент фронтендер может решить пару простых задач с бекенда, чем поможет бизнесу, а еще его экспертиза будет расти по мере возникновения и решения таких задач и в пределе сравняется с эффективностью бекендера. Но в целом все зависит и от конкретных людей и от процессов в компании и в командах, наверное, там где применяется водопадная модель планирования мой подход будет иметь отрицательный эффект. А в мини продуктовых командах, где ценные фичи (которые приносят деньги) выпускаются по несколько в неделю это имеет смысл.
Ломоносов, Эйнштейн, и другие - гении, "штучный товар". А мы о массовом говорим. Насчет "Серьезный разработчик все равно так или иначе разбирается в смежных областях...", Соглашусь, так или иначе должен, я и сам немного фронт наверное даже где-то на уровне мидла :) Сейчас вот например смотрю на Next.js AppRoute, в жизни всякое бывает может пригодится :) Более того я в нескольких MVP делал фронт сам, и это меня еще больше убедило, если это больше, чем просто демка, то нужен человек который полностью погружен в тему.
Фулстеки ценны и имеют смысл только на начальном этапе: MVP, первые спринты стартапов и т.п, когда важно как можно быстрее что-то показать, и нет времени и/или ресурсов на создание полноценной команды. И это перекликается с тем что вы написали, да. Но это все точно не про сложившийся проект, который приближается или уже в продакшене.
Serverless в первый раз