Друзья.
Хочу поделиться планами по разработке интересного продукта.
Пока выдалось свободное время, решил прокачаться в теме Angular2 + Salesforce.
И чем дальше погружаюсь понимаю что тут полное болото. Примеры в интернете - кто во что горазд, тупо сборники обрывков знаний. Если еще с стороной SF более менее все понятно (тем у кого есть опыт), то на стороне NodeJS творится полный звиздец. (вот тут https://habrahabr.ru/post/312022/ написана чистая правда).
Поэтому решил сделать еще один тул 
чтобы облегчить жизнь SF разработчиков с базовыми знаниями JS (ну естественно и самому прокачать на практике всю кухню).
В планах замутить локальное приложение (в идеале десктопное, в реале пока консольное). которое будет предоставлять шаблон (скелет) для проекта. В проекте можно будет работать с несколькими (не одним как в Angular CLI) независимыми ангуляр приложениями (есть и такая необходимость). Все можно будет разрабатываться и запускаться локально (делаю специальный локальный сервер-wrapper, который будет эмулировать SF окружение). Все будет компилиться на лету (то есть нажал CTRL+S и пошел в браузер смотреть). Локальный сервер-wrapper будет предоставлять доп возможности для отладки, чтобы облегчить жизнь программисту. После окончания разработки все будет собираться в static ресурс и отправляться на орг (ну этим никого не удивлю - каждый кто практикует JS+SF уже делал свой велосипед). Плюс на стороне SF будет делаться специальный managed package который обеспечит прозрачную работу локального дев сервера, а также предоставит специальные врапперы для того чтобы чтобы сократить работу бэкенд программистов до написания чистой бизнес логики.
Все это не пустые желания, а опыт накопленный за несколько лет (а в особенности за последний год работы с ангуляром 1). Просто теперь осталось все наработки спроецировать на ангуляр 2 и обернуть это все в красивую обертку.
Вот такие у меня планы
Надеюсь получится что-то стоящее и я не прогадал в выбором технологий
Да еще, тем кто не сталкивался со ангуляром 2 - все это дело будет крутиться на TypeScript что сильно поможет делать качественные и большие Enterprise приложения.
Да, еще забыл написать.
В структуру проекта будут включен набор компонентов заточенных под lighnting. Это тоже сильно упростит разработку фронтенда. По сути разработка превратится в составление шаблонов из готовых кирпичиков (компонентов) с навешиванием своей бизнес логики.
Ну и как изюминка - опыт полученный при разработке локального дев сервера я пущу на разработку специального клиента для запуска а2 приложений локально (по типу десктопных), ну а в еще большую перспективу сделать мобильный клиент
Так что будем переделывать Salesforce с его Lightning, Salesforce 1
Часть проекта как я понимаю будет открытая ?
Вот это кстати один из проблемных вопросов.
На стороне SF точно будет managed package.
А nodejs часть пока вся как на ладони. Ищу варианты как это все дело закрыть. Посматриваю в сторону Electron (link) (собственно как сделали MavensMate)
Открытыми останутся структура проекта и набор готовых компонентов.
А так ты правильно подметил, надо про это задуматься сразу, иначе пойдет по рукам проект.
А почему managed, можешь объяснить подробнее?
Да все из меркантильных побуждений
Скрыть часть логики от посторонних глаз.
А также опыт показывает что unmanaged packages или просто код из git используется на проектах как попало. Пусть это будет такой себе черный ящик. Есть конечно и проблемы с этим 
Managed package надо на AppExchange минимум выложить, вернее пройти code review, а то не всем понравится ставить непонятно что на свои проды. Да и со staсktrace недавно были проблемы. Но это можно думаю будет обойти какой-нибудь лайтовой версией в виде отдельного unmanaged сервис класса уже чисто под прод (в основной версии пакета есть много логики для обслуживания локального дев сервера которая не нужна на проде).
Ну и еще один крайне интересный момент - ограничение излишней свободы в разработке сильно положительно влияет на работу команды. Всякие там code styles, жесткая структура проекта, неизменные сервис методы, набор стандартных компонентов позволит меньше заниматься велосипедописанием и работать с кодом на более высоком уровне.
Крутые специалисты конечно могут меня осудить, но крутым программистам вся эта затея и нафиг не нужна - можно с тем же успехом пилить по старинке на чистом ангуляре и со своим набором сборщиков.
То бишь ты планируешь потом писать гайд как пользоваться твоими классами пакета?
Я сразу делаю демо проект в котором будет все красиво работать на реальных данные. Останется только подсмотреть то что заинтересует. Но это касается именно стандартных компонентов. Но они и так будут в открытом доступе. Что касается именно managed package, то там собственно описывать то и нечего будет - это пока всего лишь прокси сервер для пересылки запросов от англуляр компонентов в твои будущие сервис классы (в перспективе еще будет небольшая коллекция служебных методов для работы с метадатой). Но все это будет все использоваться уже более на высоком уровне абстракции - ангуляр сервисах и компонентах. Лезть внутрь пакета вообще не надо будет.
И идеальном случае схема будет выглядеть так:
Твой компонент -> Мой ангуляр сервис для работы с SF -> Мой пакет -> Твой Apex Class с нужным методом.
Тебе не придется думать как составлять запрос как его отравлять, как логиниться, как принимать и парсить его на стороне SF и так далее. Все будет сводиться к паре строк на стороне SF и Арекс классу построенного по определенному шаблону. Минимум кодирования - максимум производительности.
Жду 
хочу уже глянуть на это :)
