Я не очень знаком с инфраструктурой Google Cloud, был один пет проект давно и немного забыл все, за 30 минут не поднял бы точно, а сервера на амнезии у меня давно используются для других нужд, поэтому мне было просто по клику получить новые креды и подключиться. Если бы я мог использовать гугл клауд, мне бы и не надо было стучаться из яндекс клауда, но там все по другому, вплоть до бд (firebase vs ydb). Если гипотеза выстрелит, то можно будет подумать над более целевым решением, может и без gemini, альтернативы есть.
хорошо бы, оформить приложение как сервис. было бы полезно. особенно, если вести общую базу сложности книг. можно было бы монетизировать на партнерке с kindle и audible
Я тоже подобную статью написал и тоже всю зиму грел дом. Окупается, но бассейн и прочая фигня не нужны. На кондиционере большие потери, почему просто вентиляторами теплый воздух не перегонять?
это басня и иногда имеет смысл. но есть и другие примеры: например, Ломоносов, Эйнштейн. бекендеры не рождаются бекендерами, это не передается по наследству, а учиться никогда не рано. Но главное, если разработчик надел на себя колпак фронтендера или бекендера и больше ничего слышать не желает, то это не разработчик, а переводчик с человеческого языка на компьютерный. Серьезный разработчик все равно так или иначе разбирается в смежных областях и разбирается в прикладных областях. Задачи в любой области бывают разной сложности, а с точки зрения бизнеса важно чтобы задачи решались как можно быстрее и как можно быстрее приносили деньги. и если в какой-то момент возникает перекос в задачах бекенд или фронтенд, если он кратковременный, то вопрос найма, а это тоже задача у которой есть цена или затраты обычно не стоит, а просто часть команды простаивает, а другая часть команды задерживает прибавление полезной ценности. Люди еще и болеют. И в такой момент фронтендер может решить пару простых задач с бекенда, чем поможет бизнесу, а еще его экспертиза будет расти по мере возникновения и решения таких задач и в пределе сравняется с эффективностью бекендера. Но в целом все зависит и от конкретных людей и от процессов в компании и в командах, наверное, там где применяется водопадная модель планирования мой подход будет иметь отрицательный эффект. А в мини продуктовых командах, где ценные фичи (которые приносят деньги) выпускаются по несколько в неделю это имеет смысл.
Статья не о том, что такое серверлес, а о подходе по включению например поискового индекса в тело функции. Если контент статичный, то можно не хранить данные в базе данных, а при изменении пересобирать функцию с новым индексом.
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
при каждом вызове поднимается nodejs, обрабатывает запрос и потухает через какое-то время, если не приходит новый запрос. Но лучше почитать об этом в документации.
Вообще, есть такой пакет: https://www.npmjs.com/package/@yandex-cloud/serverless-live-debug Но я отлаживал через TDD, а когда что-то непонятное было, то да в яндекс клауде много инструментов. Как и приведенный мной, тоже хотелось бы опробовать, вероятнее, если будет проект с состоянием на сервере, то придется воспользоваться им, а в моих кейсах не было необходимости.
Сами клауд функции являются универсальным решением, просто другой подход к решению задач. Но в таком изолированном виде они годятся только для очень ограниченного списка задач, честно говоря, не приходит в голову других задач, кроме тех, что я описал. А так можно писать телеграм бота на клауд функции. У Google Cloud из коробки можно Next приложение развернуть. Как раз хотелесь бы чтобы кто-то поделился опытом такого изолированного использования.
Пока никаких вариантов не рассматривал, для теста гипотезы это не нужно. По результатам теста буду смотреть все варианты.
Я не очень знаком с инфраструктурой Google Cloud, был один пет проект давно и немного забыл все, за 30 минут не поднял бы точно, а сервера на амнезии у меня давно используются для других нужд, поэтому мне было просто по клику получить новые креды и подключиться. Если бы я мог использовать гугл клауд, мне бы и не надо было стучаться из яндекс клауда, но там все по другому, вплоть до бд (firebase vs ydb). Если гипотеза выстрелит, то можно будет подумать над более целевым решением, может и без gemini, альтернативы есть.
Сервис не упадет, а у функции выскочит исключение, которое сервис должен обработать.
Согласен, что стратегически это не годится, как продакшн решение, но чтобы по быстрому протестировать гипотезу, вполне.
Это же серверный код, вряд ли МТС как-то влияет на сервера яндекс, не через мобильную же дата центр подключен.
Да, умеет
а зарплата-то изменилась? в начале была затравка про 30тыс, но к концу эта тема так и не раскрылась.
браузер не запоминает, но JS с этим спраляется
хорошо бы, оформить приложение как сервис. было бы полезно. особенно, если вести общую базу сложности книг. можно было бы монетизировать на партнерке с kindle и audible
Я тоже подобную статью написал и тоже всю зиму грел дом. Окупается, но бассейн и прочая фигня не нужны. На кондиционере большие потери, почему просто вентиляторами теплый воздух не перегонять?
можно выключать, но это вручную, или от внешней погоды автоматику настроить.
я купил за 15тыс.
это басня и иногда имеет смысл. но есть и другие примеры: например, Ломоносов, Эйнштейн. бекендеры не рождаются бекендерами, это не передается по наследству, а учиться никогда не рано.
Но главное, если разработчик надел на себя колпак фронтендера или бекендера и больше ничего слышать не желает, то это не разработчик, а переводчик с человеческого языка на компьютерный. Серьезный разработчик все равно так или иначе разбирается в смежных областях и разбирается в прикладных областях. Задачи в любой области бывают разной сложности, а с точки зрения бизнеса важно чтобы задачи решались как можно быстрее и как можно быстрее приносили деньги. и если в какой-то момент возникает перекос в задачах бекенд или фронтенд, если он кратковременный, то вопрос найма, а это тоже задача у которой есть цена или затраты обычно не стоит, а просто часть команды простаивает, а другая часть команды задерживает прибавление полезной ценности. Люди еще и болеют. И в такой момент фронтендер может решить пару простых задач с бекенда, чем поможет бизнесу, а еще его экспертиза будет расти по мере возникновения и решения таких задач и в пределе сравняется с эффективностью бекендера. Но в целом все зависит и от конкретных людей и от процессов в компании и в командах, наверное, там где применяется водопадная модель планирования мой подход будет иметь отрицательный эффект. А в мини продуктовых командах, где ценные фичи (которые приносят деньги) выпускаются по несколько в неделю это имеет смысл.
А какие этот может иметь негативные последствия? У вас был опыт?
и отлично подходит для петпроектов, когда трафик маленький, у яндекса куча условно бесплатного.
Статья не о том, что такое серверлес, а о подходе по включению например поискового индекса в тело функции. Если контент статичный, то можно не хранить данные в базе данных, а при изменении пересобирать функцию с новым индексом.
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
функция пустышка это как пример итона исподняет роль шаблона для команды create. используя этот подход мы сделали поиск и ротацию для баннеров: вот пример поиска https://m2.ru/support/ на том же сайте на главной есть баннеры, они от регионов зависят и тп. но я же не могу весь код к статье приложить, она же не про поиск.
при каждом вызове поднимается nodejs, обрабатывает запрос и потухает через какое-то время, если не приходит новый запрос. Но лучше почитать об этом в документации.
Вообще, есть такой пакет: https://www.npmjs.com/package/@yandex-cloud/serverless-live-debug
Но я отлаживал через TDD, а когда что-то непонятное было, то да в яндекс клауде много инструментов. Как и приведенный мной, тоже хотелось бы опробовать, вероятнее, если будет проект с состоянием на сервере, то придется воспользоваться им, а в моих кейсах не было необходимости.
Сами клауд функции являются универсальным решением, просто другой подход к решению задач. Но в таком изолированном виде они годятся только для очень ограниченного списка задач, честно говоря, не приходит в голову других задач, кроме тех, что я описал. А так можно писать телеграм бота на клауд функции. У Google Cloud из коробки можно Next приложение развернуть. Как раз хотелесь бы чтобы кто-то поделился опытом такого изолированного использования.