из rebar.config выпилить все зависимости от lager,
в sys.config добавить "logger.config"

жестковато получилось с большими сообщениями

Это для примера, красоту и фильтрацию по доменам - это уже на свой вкус. Есть хорошая вводная статья на эту тему у Юра. Ну и в доках всё хорошо рассказано

Спасибо!

Рассказываю про наш опыт со схемами и тп.

Однозначно, без каких-либо сомнений, api first и отдельный репозиторий.

Схема - это публичный контракт продукта на то, что он делает. Подход api first он вообще про изменение цикла разработки и про явное выделение этапа планирования и обдумывания.


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

Api first - это та бюрократия, дорастание до которой означает некоторую зрелость команды.


Генерация схемы из кода бессмысленна, потому что не является контрактом, легко может поменяться и для тех, кто пользуется продуктом, приносит мало пользы (есть, но чуточка).


Schema first позволяет начать разработку фронтенда до того, как к бекенду прикоснутся.

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


Код надо по схеме автогенерировать, чтобы он был жестким, единообразным, одинаковым, предсказуемым и отлаженным. Парстрансформы зло, но у нас есть чутка.

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


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

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

"Переливание" кода эффективнее несмотря на ненужные ошибки. По всем тем же причинам что api для людей - общение между подсистемами, независимое тестирование , свобода интеграции.

Не прочувствовал этого пока.


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

Это согласен. Особенно если даже не приходиться копировать/клонировать  данные. А вот если кроме эрланга заведется что-нибудь или другой движок взаимодействия  нарисуется внутри

Ну так то конечно. У нас порядка 10 систем на эрланге, эликсире, расте, яваскрипте, питоне и рельсах стыкуются

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

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

А на рельсах какие части? И почему именно они?

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

Для crm это важное свойство

Crm для внутренних нужд компании, если я правильно понял? Не для дистрибуции клиентам?

И да, и нет.

У нас crm, биллинг - все рядом.

Сейчас мы наш биллинг готовим клиентам для whitelabel, они не умеют делать подписки, а мы делаем хорошо

Сказавши "А"... Хочется посмотреть на примеры схем. Ну и нагло (и безнадёжно) хотеть кодогенератор в опенсурс. Мы сейчас переходим к системе типа "от нашей системы будет зависеть жизнь людей". И тут много чего НИОКР было

Ага, организую. Кодогенератором тоже поделюсь, хотя запустить его будет непросто :)

Ну внутренние наработки это понятно.

Я не уверен что для эрланга с его стандартизованност веба возможна стандартная кодогенерация.

Постараюсь оформить в опенсорс нормальный роутер для ковбоя, который мы у себя написали, но этого все равно мало