+

тут всё не так просто, на мой взгляд.
вот например, взять дефолтный фениксовый проект, с него можно собрать какие-то общие знания о beam-специфике применительно к вебне, но - имхо, в фениксе далеко не всё сделано по уму, например в плане supervision tree. типа - почему пул коннектов к бд не под основным приложением?.. где описано, как будет правильнее и какие там трейдофы - я вообще хз. в общем и целом, про otp, которая является основой для этого слоя архитектуры, есть книжка чезарини и томпсона "проектирование масштабируемых систем с erlang/otp", тут в файлах есть скан, но на какие вопросы она ответит - не знаю даже.

феникс - это вебня, по большей части стейтлесс, и не весь спектр возможных кейсов покрывает. есть, например, стейтфул вещи с process per entity как точка синхронизации и in-memory кэш, тут приходится уже находить трейдофы между производительностью и консистентностью данных, и я вообще не уверен, что где-то про такое читал(ну кроме life beyond distributed transactions хелланда, которое вообще больше про философию).

в сети много материалов по riak/riak core, особенно интересные от Mariano Guerra(https://marianoguerra.github.io/), но это очень специфичная штука и границы применимости ее нужно понимать самому.

про beam-специфику можно поискать посты и рассказы Макса Лапшина, у него много интересного про отзывчивость, производительность, наблюдаемость системы и интроспекцию. я, собственно эрланг учил по ходу написания плагинов в его старый erlyvideo, и это мне довольно много дало.  

какие-то философские вещи можно почерпнуть из продуктов clojure-комьюнити, там водятся правильные идеи и философия, но их нужно адаптировать, потому что beam сильно отличается от jvm.

Спасибо за чтиво на вечер, если есть что-то ещё классное почитать, то кидай, пожалуйста!

Да, Чезарини с Томпсоном огонь чтиво!)

А почему cowboy не под основным приложением?

я хз, честно говоря.
наверное, Лоик считает это приемлемым дефолтом, с учетом того, что в ranch есть embedded mode, на который можно переключиться минимальными усилиями.

Я думаю пацаны брали познания в основном из ковбоя, потому что с ним они в общем-то работали

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

Наверное многие вещи можно будет проработать, без позиции сеньора, если сделать кравлер где данные приходят из множества разных потоков и подцепить к нему кавку. Как думаешь?

Есть пример hello world с запуском под своим supervision tree?

init([]) ->
    RanchSupSpec = {
        ranch_sup, 
        {ranch_sup, start_link, []}, 
        permanent, 
        5000, 
        supervisor, 
        [ranch_sup]
    },
    ListenerSpec = ranch:child_spec(
        echo, 
        100, 
        ranch_tcp, 
        [{port, 5555}], 
        echo_protocol, 
        []
    ),
    {ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}.

не оно?

С ковбоем вроде нет, но там не сложнее, чем с echo.

А почему коннектам к базе нужно быть под основным аппом?

Всё равно эти знания будут на уровне пользователя. Надо же знать тонкости конфигурации, деплоя, починки сбоев — всё вот это вот

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

Так разве Repo не запускается в основном аппе? Вроде он там запускается
А в ecto запускается только Registry реп, зачем он нужен с основной аппе?

я точно не знаю, какую задачу выполняет Repo, но реально пул запускается под db_connection.

Попробовал прочитать что же всё-таки запускает этот Repo и там столько вызовов, что просто ужас

Но, как я понял, Repo (в случае с постгрёй) запускает процесс, который падает, когда падает пулл из db_connection
Так что связь есть

Связь типа: поставим камеру, которая будет смотреть на соседнее дерево, и когда оно упадем - включим бензопилу и спилим наше