Heroku для начинающего

Привет. Я с Heroku уже 3 года плотно работаю.
Это облачный сервис где ты можешь запускать любые НЕ Salesforce проекты. Мы там хостим кучу наших Python, NodeJS, .Net(пока один тестовый) проектов.

В Heroku ничего магического нет. Это просто слой абстракции над обычным Linux сервером. Ты типа добавляешь в свой проект специальный файл с описание как запустить твое приложение и просто через git отправляешь проект на Heroku. Heroku его сам разворачивает, стягивает зависимости (компилит если надо) и запускает. Думать об инфраструктуре вообще не надо. Есть куча так называемых Add-ons в Marketplace. Нада база данных Postgres или MongoDB - подключил аддон нужный. Надо пробвинутое логирование - подключил аддон. Приложение работает в так называемом Dyno. Это типа сервака виртуального. Можно выбирать разные типы Dyno в зависимости от требуемых ресурсов или поднимать сразу несколько Dyno параллельно.

Все в Heroku хорошо пока твое приложение не разрастается. За каждый дополнительный ресурс надо брать новый план, и цены растут в геометрической прогрессии. С одной стороны на Heroku вполне можно хостить полноценный сервис на бесплатных квотах (я всяких прототипов назапускал уже кучу и не заплатил ни копейки), но как только начинаешь выходить на продакшен уровень бабки начинают улетать с огромной скоростью. У нас проекты в компании вообще не highload но средний чек уже давно исчисляется десятками тысяц баксов в месяц! Сейчас по этому поводу огромный вопрос стоит - переехать куда-нибудь (я как раз в соседней ветке уже писал про Docker/Kubernates).

Но для своих каких-то домашних проектов, для быстрых демо и прототипов Heroku тема!!! (но если ты не Salesforce разраб )

Как вариант, если Heroku философия нравится но платить влом, то есть пара проектов для развертывания своего Heroku - один из них: https://github.com/dokku/dokku

На счет использовать Heroku c Salesforce - Heroku не примечателен для Salesforce кроме того что SF купил его. Есть какой-то Salesforce Connect который стоит каких-то нереальных денег и ничего не дает. Все можно сделать и обычным SF API.

Так что изучать Heroku особого смысла нет если ты не занимаешь разработкой на том же python и хотя бы пару раз уже не разворачивал свой проекто где-то на VPS, чтобы почувствовать всю прелесть Heroku.

вот здесь описано, как, зачем и почему интегрировать СФ и Хероку:

https://trailhead.salesforce.com/en/content/learn/modules/salesforce_heroku_integration/getting_started_with_integration

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

Den Brown

что по-мне, так пока единственный рабочий вариант использования Хероку - это например сайт на Друпале, который через хероку интегрируется с СФ.

Хероку был еще когда разработчики Salesforce еще под стол пешком ходил. Хероку это не ДЛЯ Salesforce, ПОД Salesforce, ни в Salesforce. Salesforce просто его купили (патамушта бабла девать некуда). При желании на Хероку свой Salesforce можно написать (возможно Salesforce на нем изначально и крутился раз к нему такое внимание). Рабочих вариантов использования Хероку просто тьма и 99% вообще с Salesforce не связана. А ссылка дельная, реально описаны хорошие случаи. Надо просто найти им применения в пуле текущих задач вашей фирмы.

Den Brown

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

Drupal это одна из PHP CMS скорее для малого бизнеса. Кроме PHP есть и другие языки которые больше ентерпрайз, есть другие CMS и фреймворки. Причем я сразу скажу Drupal разраб это последний чел который пойдет смотреть на Heroku, потому что PHP хостингов хоть попой ешь. А вот запустить тот же ASP.NET или Spring (Java) или Django (Python) это уже задачка посерьезнее. Тут Heroku и выходит на арену.

Самый частый случай когда Heroku может понадобиться это когда ваш кастомный функционал перестает вписываться в Salesforce, а платить за дополнительные ресурсы влом. К примеру можно вынести часть "неважных" данных из Salesforce в базу Postgres. Сделать какой-нибудь продвинутый бэкап данных. Или у вас есть сложные и долгие батчи которые хочется ускорить. Или к примеру хочется объединить множество оргов под одним API. Можно сделать какой-нибудь тул по управлению/мониторингу оргов.
Это все совсем не интересно пока у вас задачи уровня 1 клиент = 1 орг. Но когда проект вырастает до пакета с множеством клиентов, которые еще хотят использовать какой-нибудь общий ресурс, вот тут уже приходится включять мозг

Dmitry Shnyrev

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

Aws тоже решает эту задачу

wilder

Aws тоже решает эту задачу

Так я поэтому и написал выше что Heroku != Salesforce.
И AWS решает и Google Cloud Platform решает и MS Azure решает (и даже простой VPS в кучу). Все это, как и Heroku, это всего лишь облачные платформы чтобы запускать ваши проекты. Вот я и пытаюсь донести что не с Хероку надо начинать, а начинать надо с задачи и проекта. А где его развернуть уже дело техники. Просто Heroku проще продать Salesforce клиенту .
И кстати поэтому я выше упомянул что лучше воздержаться от использования вариантов интеграции с припиской Connect (Heroku Connect, Salesforce Connect) пока в этому не будет критической необходимости. Все можно и решается с помощью Salesforce REST/SOAP API и посему проект получается Heroku-независимым. Как к примеру в нашем случае - все проекты что есть в нашей компании хоть и хостятся в данный момент на Heroku, но готовы в любой момент переехать на любую другую платформу без каких либо переделок.

я хероку начал потихоньку изучать так как это для меня просто "дверь" из мира "придворного" СФ программирования в мир свободного программирования.

но и далеко от СФ "кормушки" отходить не надо. поэтому в первую очередь смотрю как это все совместить с СФ.

а началось все вот с этих статей:

https://medium.com/salesforce-architects/heroku-pattern-cross-org-data-synchronization-addcaa2c970a

https://medium.com/salesforce-architects/do-you-need-an-event-bus-a-quick-overview-of-five-common-uses-722ae9b50765

О! Хорошие статьи! Есть о чем подумать.
Но сразу предупреждаю это приглашение в ад. Все красиво на словах, но придется вылезти из зоны комфорта Salesforce и простые порой вещи буду выворачивать мозг.

Вот к примеру в двух статьях описана Apache Kafka. Это просто диспетчер сообщений и ничего больше. Publisher положил сообщение, Subscriber/Consumer забрал. ВСЕ! Это всего лишь Salesforce Platform Events только для всего остального мира. Ничего сам Kafka не делает за тебя. Всю обвязку все равно придется пилить за пределами Kafka. Это как запилить какой-то триггер на SF который будет посылать сообщение в очередь Platform Events а какой нибудь Lightning Component будет читать это сообщение. Триггер и Lightning Component придется пилить и они будут содержать 100% всей бизнес логики.

А на счет билета в ад. Вот прекрасное видео я недавно смотрел как раз в тему как простая на взгляд технология Apache Kafka может доставить геморроя. Salesforce разрабы про это все не думают потому что за нас думает сам Salesforce под капотом.

https://www.youtube.com/watch?v=m5CDfrQLzrs

ЗЫ:
Но вот с этой штукой (скрин из статьи)
Я бы вообще такого архитектора выгнал и отобрал все сертификаты. Удачи в дебагинге этой хрени если что-то пойдет не так (запасайтесь вазелином).

Позвольте немного порассуждать на тему очередей. Сейчас как раз темя для меня актуальная (хочу найти простое, надежное решение под .net, оказывается тут эта тема немного запутаннее).
Для чего нужны очереди? Очереди это способ асинхронного общения между микросервисами/асинхронными задачами. И с первого взгляда кажется совсем простой задачей которая не достойна потраченного времени. НО если капнуть глубже всплывают куча нюансов. Вот как раз со всеми этими нюансами и позволяют бороться штуки типа Apache Kafka (кстати по секрету других аналоги проще/сложнее тоже есть). Но очередь можно запилить и самому в виде простой таблицы в базе данных. Делаем таблицу Queue и складываем туда наши сообщения в виде рекордов. А какой нибудь асинхронный обработчик (Worker) по CRON берет и выгребает из очереди эти сообщения для обработки.

Просто? Конечно.

Но вот у нас появляется два Workers которые работают параллельно. Вот тут и начинается гемор с параллельно работой. Я конечно привел простейший пример и скажем на уровне базы можно работать с блокировкой записи при обращении к ней первым Worker. Но вдруг Worker умрет и сообщение останется заблокированным и не обработанным? Тоже решается с помощью обертки в try/catch но позволяет отловить исключения только внутри самого приложения, а что если упадет/перезагрузится сам сервер. И вот таких "а что если" всплывает море. И начинаются костылеписания. И в итоге придумывается новый велосипед Kafka2.

Хорошо. Значит приходим к выводу надо использовать Kafka (или любой аналог)! Блин, но тут встает вопрос - для кафки нужен отдельный сервер, отдельное хранилище, правильно настроенный мониторинг и возможно какой-нибудь прикрученный UI. А еще нужен админ, которые знает как работать с Кафкой, и которые знает как разруливать косяки, потому что эта тема явно выходит за рамки знаний простого разраба. А в нашем домашнем проекте нам и надо всего лишь сделать очередь для каких нибудь простых событий, которые случаются с периодичностью 100 событий в день (не миллионы в секунду на которые рассчитана Кафка).

И вот ломаешь голову - а стоит писать свой микро велосипед или купить промышленный экскаватор чтобы выкопать лунку под помидор в огороде.

Вот как раз над этой хренью сейчас и ломаю голову в рамках изучения .net

Dmitry Shnyrev

Позвольте немного порассуждать на тему очередей. Сейчас как раз темя для меня актуальная (хочу найти простое, надежное решение под .net, оказывается тут эта тема немного запутаннее).
Для чего нужны очереди? Очереди это способ асинхронного общения между микросервисами/асинхронными задачами. И с первого взгляда кажется совсем простой задачей которая не достойна потраченного времени. НО если капнуть глубже всплывают куча нюансов. Вот как раз со всеми этими нюансами и позволяют бороться штуки типа Apache Kafka (кстати по секрету других аналоги проще/сложнее тоже есть). Но очередь можно запилить и самому в виде простой таблицы в базе данных. Делаем таблицу Queue и складываем туда наши сообщения в виде рекордов. А какой нибудь асинхронный обработчик (Worker) по CRON берет и выгребает из очереди эти сообщения для обработки.

Просто? Конечно.

Но вот у нас появляется два Workers которые работают параллельно. Вот тут и начинается гемор с параллельно работой. Я конечно привел простейший пример и скажем на уровне базы можно работать с блокировкой записи при обращении к ней первым Worker. Но вдруг Worker умрет и сообщение останется заблокированным и не обработанным? Тоже решается с помощью обертки в try/catch но позволяет отловить исключения только внутри самого приложения, а что если упадет/перезагрузится сам сервер. И вот таких "а что если" всплывает море. И начинаются костылеписания. И в итоге придумывается новый велосипед Kafka2.

Хорошо. Значит приходим к выводу надо использовать Kafka (или любой аналог)! Блин, но тут встает вопрос - для кафки нужен отдельный сервер, отдельное хранилище, правильно настроенный мониторинг и возможно какой-нибудь прикрученный UI. А еще нужен админ, которые знает как работать с Кафкой, и которые знает как разруливать косяки, потому что эта тема явно выходит за рамки знаний простого разраба. А в нашем домашнем проекте нам и надо всего лишь сделать очередь для каких нибудь простых событий, которые случаются с периодичностью 100 событий в день (не миллионы в секунду на которые рассчитана Кафка).

И вот ломаешь голову - а стоит писать свой микро велосипед или купить промышленный экскаватор чтобы выкопать лунку под помидор в огороде.

Вот как раз над этой хренью сейчас и ломаю голову в рамках изучения .net :D

Если нет сильного DevOps ничего нет более надежного чем готовые cloud решения AWS, Google Cloud, Azure Cloud и прочее. У AWS вообще куча сервисов под любой чих.

В зависимости от назначения очереди можно использовать SQS, SNS, Event Bus и прочее. И до какой-то степени это даже все бесплатно. Ничего не пропадет и не потеряется, если использовать по рекомендациям

Heroku, к слову, хостит и менеджит все на AWS. Раньше даже было все очень похоже с амазоновским Elastic Beanstalk сервисом, не знаю как сейчас они сильно отличаются по возможностям или нет.

Raman Silin

Если нет сильного DevOps

раз коснулись этой темы, что такое DevOps по вашему мнению?

если читать статьи, то обычно DevOps характеризуют как "философию", а там поди разбери, что конкретно они имели ввиду.

поэтому здесь интересны именно частные мнения людей о том, что они вкладывают в это понятие

Den Brown

раз коснулись этой темы, что такое DevOps по вашему мнению?

До этого думал что знаю что за зверь такой DevOps но как появился вопрос сразу появилось и сомнение.
В общем до этого думал что DevOps это разраб которые знает все по чуть-чуть. Куда его не поставь он везде пригодится (фронтенд/бэкенд/администрирование инфраструктуры и прочее).
Но решил порыться и нашел такую статью на моем любимом ресурсе
https://habr.com/ru/post/469277/
и там в комментах как всегда вся соль - человек выделил самое главное в этой статье. Мне понравилось это определение и в принципе оно не далеко ушло от моего личного понятия:

DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы высокоуровнево, помимо этого понимающая также пред и пострелизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.

Простыми словами DevOps - разраб которые вовлечен во все этапы развития проекта - от кодирования до развертывания на проде. И DevOps это не бэкенд java разраб который только умеет варить java у себя на локалке или javascript разраб который не имеет ни малейшего понятия как запустить java бэкенд. DevOps это и бэкенд разраб и фронтенд разраб и еще AWS/DB админ.

Хотя вот сейчас перечитал и у меня возник вопрос а чем DevOps отличается от Архитектора?

А есть еще такое понятие как Full Stack Developer.

Нашел еще один интересный ресурс и определениями.

https://www.reddit.com/r/cscareerquestions/comments/91i4h3/whats_the_difference_between_fullstack_and_devops/

Dev ops is the discipline of being involved in both development and deployment.
Full stack is when you work on everything in the stack from database to javascript.

Получается что выше я описал DevOps как FullStack разраба. Хм!

В общем у нас в компании я ближе к Full Stack разрабу - знаю и делаю ВСЕ - от JS до ... .

Есть у нас разрабы которые к примеру 99% python/salesforce, но также и Deployment захватывают (то есть могут запилить и развернуть проект). Это наверное DevOps.

А есть и такие кто "чисто" программисты - их касается только запили/пофиксить что-то локально/на сандбоксе и залить в git и все!

Den Brown

Raman Silin

Если нет сильного DevOps

раз коснулись этой темы, что такое DevOps по вашему мнению?

если читать статьи, то обычно DevOps характеризуют как "философию", а там поди разбери, что конкретно они имели ввиду.

поэтому здесь интересны именно частные мнения людей о том, что они вкладывают в это понятие

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

Например, разработчик делает приложение на Salesforce или тот же Heroku (то есть бизнес логику), а вот его запуск, масштабирование, отказоустойчивость серверов и среды, где крутится приложение, различные деплойменты - это уже DevOps.

Версии и релизы на Salesforce создают разработчики, а вот DevOps делает так, что когда создается орг - то создается/используется какая-то инфраструктура и ставится определенная версия Salesforce

Raman Silin

Например, разработчик делает приложение на Salesforce или тот же Heroku (то есть бизнес логику), а вот его запуск, масштабирование, отказоустойчивость серверов и среды, где крутится приложение, различные деплойменты - это уже DevOps.

Мне почему-то это определение скорее похоже на чистого Админа. DevOps сам и девелопит и все остальное что описано выше.

Raman Silin

Если нет сильного DevOps

вот здесь я подумал, что имеется ввиду DevOps как процесс. А вы оказывается говорите о человеке-роле...

я думаю DevOps - инженер - это чисто HR - маркетинговое словосочетание.

согласен вот с этим комментом из статьи выше:

Нет людей devops-инженеров. Devops — это методология. ...
Наверное есть devops-евангелисты, но не более. Все остальное — это извращенное недопонимание рынка

так что такое по вашему DevOps как процесс?

Dmitry Shnyrev

Raman Silin

Например, разработчик делает приложение на Salesforce или тот же Heroku (то есть бизнес логику), а вот его запуск, масштабирование, отказоустойчивость серверов и среды, где крутится приложение, различные деплойменты - это уже DevOps.

Мне почему-то это определение скорее похоже на чистого Админа. DevOps сам и девелопит и все остальное что описано выше.

Так вот DevOps и есть то соединение админа и разработчика, которое увеличивает скорость процесса разработки, деплоймента, масштабирования и отказоустойчивости среды

Безусловно, изначально DevOps это методология. Но если есть какая-то методология и практики, то человека, который занимается внедрением этих практик и процессов можно назвать специалистом. И из-за того, что это технический специалист, то отсюда получается devops-инженер.

Да, при моем первом упоминание я имел инженера, правильно было бы написать нет сильного devops-инженера

DevOps - методология
DevOps-инженер - человек, который непосредственно внедряет практики (то есть это может быть даже разработчик)

Den Brown

так что такое по вашему DevOps как процесс?

То есть все те процессы которые ускоряют разработку и релиз, и процессы, которые гарантируют работоспособность.

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

Raman Silin

DevOps-инженер - человек, который непосредственно внедряет практики (то есть это может быть даже разработчик)

логика понятна.

но вот если бы мы не знали такого слова как DevOps и никто бы его не придумал, то как бы мы называли человека, который все это делает:

Raman Silin

То есть все те процессы которые ускоряют разработку и релиз, и процессы, которые гарантируют работоспособность.

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

или если бы мы не знали DevOps, то мы бы этого и не делали?

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

До введения такого слова как DevOps кто-то же это пытался и делал, но все развивалось и ввели такое определение.

а вообще, хорошая идея.

добавлю-ка я себе в резюме DevOps...

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

Dmitry Shnyrev

Так я поэтому и написал выше что Heroku != Salesforce.

Я думаю что Heroku имеет непосредственное отношение к EverGreen, другое дело что не понятно на каком он сейчас свете.

Sergey Prishchepa

Heroku имеет непосредственное отношение к EverGreen

Что такое EverGreen? Первый раз слышу это название.

Dmitry Shnyrev

Что такое EverGreen? Первый раз слышу это название.

первая ссылка в google https://developer.salesforce.com/blogs/2019/11/introducing-salesforce-evergreen.html

Sergey Prishchepa

первая ссылка в google

У меня в гугле этой ссылке даже на первой странице не видно .
Вот поэтому и спрашиваю.
Вот ссылки из моего гугла
https://www.evergreen-marine.com/
https://www.evergreen-line.com/
https://midacompany.ru/catalog/ever-green-international.php
https://ru.wikipedia.org/wiki/Evergreen_Group
https://kemping.by/catalog/rybalka/voblery/voblery_evergreen/

По ходу воблеры из kemping.by важнее чем Salesforce EverGreen

Sergey Prishchepa

https://developer.salesforce.com/blogs/2019/11/introducing-salesforce-evergreen.html

Вчитался статью по ссылке и достаточно интересно звучит. Странно что я до сих пор не слышал ни про Evergreen ни про Customer 360 Platform
Надо будет изучить!!!
Сергей пасиб за ссылку.
А ты работал с этими штуками?

Dmitry Shnyrev

По ходу воблеры из kemping.by важнее чем Salesforce EverGreen

Любые воблеры важнее чем SF!

Dmitry Shnyrev

А ты работал с этими штуками?

Неа

Sergey Prishchepa

первая ссылка в google https://developer.salesforce.com/blogs/2019/11/introducing-salesforce-evergreen.html

прочитал - ничего не понял

кто нибудь в двух словах объясните что это такое Evergreen, который based on Kubernetes

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

Den Brown

Sergey Prishchepa

первая ссылка в google https://developer.salesforce.com/blogs/2019/11/introducing-salesforce-evergreen.html

прочитал - ничего не понял

кто нибудь в двух словах объясните что это такое Evergreen, который based on Kubernetes

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

не прогресса и перемен, а фич ради фич, новых сервисов ради новых сервисов

Den Brown

кто нибудь в двух словах объясните что это такое Evergreen, который based on Kubernetes

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

А вот что такое Evergreen это вот:

Evergreen supports technologies and architectural patterns that make development teams productive and happy:

Functions-as-a-Service for writing business logic and event processing in languages like Node.js, Java and Apex, using the full power of those languages’ package ecosystems. Functions can be triggered directly from Apex or using Platform Events, with many more invocation types and event sources to come.
Microservices for building serverless HTTP apps and APIs that can be quickly evolved by small agile teams and composed into complex, engaging digital experiences. Services and functions are serverless, consume no resources when idle and automatically and elastically scale with traffic.
Managed data stores like Postgres, Apache Kafka and Redis that complement the Salesforce Data APIs for high-performance persistence and real-time eventing.

Это ни что иное как общее описание Heroku. И ключевое для тебя здесь понятие "serverless". Короче если совсем просто (насколько мне позволяет понять моя эрудиция). Это будет Heroku встроенный прямо в Salesforce (вернее в Customer 360 Platform). А если вообще на пяльцах, то это будет типа ты сделал стандартный проект под SF но теперь у тебя не только Apex для бэкенда доступен, но и другие "languages like Node.js, Java", которые как раз таки и будут запускаться и автоматически скейлится с помощью Kubenates и Docker контейнеров.

Штука как по мне достаточно прикольная, странно такую фичу еще не засунули в наш стандартный SF.

Картинка очень хорошо подтверждает мои слова

то есть на любом языке я нахожу полезную либу, деплою ее на Хероку, оформляю как Functions-as-a-Service, и бац, она доступна прямо в апекс тригере или может вызываться в LWC. при этом Functions-as-a-Service не является web-service, это что-то вроде "статик метода", который просто вызывается в коде, и возможно даже держит контекст (кто текуший СФ юзер и прочее).

правильно?

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

ну, если я прав, то это меняет картину.

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

теперь, если что то возможно сделать программными средствами, то значит к этому функционалу можно организовать доступ из апекса

Есть такая новая фича, называется Salesforce Functions.
Пока в пилоте, но принцип там такой -

1. CLI: Ставим Salesforce Functions SFDX Plugin (sfdx plugins:install evergreen)
2. CLI: Authenticating to Developer Hub
3. На дев хаб орге: Активируем Functions (SETUP -> Functions -> Enable Functions)
4. В момент активации Salesforce добавит этот орг в качестве Data Source для Salesforce Functions, а так же будет создан Permission Set с именем "Functions". Собственно будет автоматом создан Heroku аккаунт - он будет являться Salesforce Functions аккаунт (туда код на различных языках деплоится будет)
5. CLI: Authenticate CLI with Salesforce Functions (sfdx evergreen:auth:login)
6. CLI: Создаем DX проект + скрэтч орг
7. CLI: создаем функцию (sfdx evergreen:function:create MyFunction -l javascript)
- javascript - это пока единственный поддерживаемый язык на время пилота
8. Обращаем внимание на папку functions
├── README.md
├── config
│ └── project-scratch-def.json
├── forceapp
│ └── main
│ └── default
│ ├── ...various directories...
│ ├── classes
│ └── permissionsets
├── functions
│ └── MyFunction
│ ├── README.md
│ ├── function.toml
│ ├── index.js
│ ├── package.json
│ └── test
│ └── unitTests.js
├── package.json
├── scripts
└── sfdx-project.json

9. пишем код в index.js
пример

const sdk = require('@salesforce/salesforce-sdk');

/**
* Describe MyFunction here.
*/
module.exports = async function (event, context, logger) {
logger.info('Invoking MyFunction...');

// You can set a breakpoint here to inspect the variables that are passed in.

// Insert a new Account with the name given in the event payload.
const acct = new sdk.SObject('Account');
const name = event.data.AccountToCreate__c || 'MyAccount'
acct.setValue('Name', `${name}-${Date.now()}`);
const insertResult = await context.org.data.insert(acct);
logger.info(JSON.stringify(insertResult));

// Query Accounts to verify that our new Account was created.
const fields = event.data.fields ? event.data.fields.join(', ') : 'Id, Name, CreatedDate'
const soql = `SELECT ${fields} FROM Account ORDER BY CreatedDate DESC LIMIT 5`;
logger.info(soql);
const queryResults = await context.org.data.query(soql);
logger.info(JSON.stringify(queryResults));

return queryResults;
}

10. Можно запустить этот код локально (установив Docker)
sfdx evergreen:function:start --verbose
sfdx evergreen:function:invoke http://localhost:8080

либо вызывать из Apex кода предварительно задеплоив
sfdx evergreen:function:deploy -t MyTarget -u MyScratchOrgAlias
sfdx evergreen:org:bind -u MyScratchOrgAlias -t MyTarget

public with sharing class FunctionApex {
public static void test() {
System.debug('Invoking MyFunction');

functions.Function myFunction = functions.Function.get('MyFunction');
functions.FunctionInvocation invocation = myFunction.invoke('{"fields":["Id","Name"]}');
String jsonResponse = invocation.getResponse();

System.debug('Response from MyFunction ' + jsonResponse);
}
}

В общем очень многообещающая фича.

Тут полная дока, но не уверен будет ли она доступна еще
https://sf-fns-docs.herokuapp.com/#/
Username=functions Password=pilot

Офигеть, Рустам.
Это лучшее сообщение что я читал за последние несколько лет.
Собственно все мои предположения подтвердились!
Спасибо что поделился опытом.
Интересно как ты вышел на эту тему и тем более закрытую доку (если не секрет). Предполагаю что какие-то закрытые рассылки для "своих"? .

PS: Возможно моя карьера с SF не накрылась полностью и когда-нибудь мои навыки пригодятся для данной фичи . С удовольствием буду следить за развитием событий!

ну, вот, началась эта тема со скучного "динозавра" Хероку, но потихоньку вывела на что-то новое и интересное