среда, 25 января 2017 г.

Про Docker и Ruby on Rails sprockets and precompiled assets.

Рельсы идут не тем путем.

По-хорошему монолит на рельсах нужно дробить, а то получается 1С:Бухгалтерия, со всеми включенными галочками по-умолчанию. В данном случае умолчания в рельсах слишком greedy.

Взять вот sprockets. Его задача вообще один раз запуститься, минифицировать css и js, и замолчать навеки. При этом он требует кучу разнообразных зависимостей типа execjs, nodejs или v8 от гугла в качестве движка минификации.

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

Как было бы делать правильно? Минификацию JS и CSS отрезать и делать ее опциональной, отдельной утилитой, если хотите, в составе рельс. Такой же как и rake. Назвать ее minirake и дать набор ключей для запуска. Но! У нас по всему фреймворку нужно протянуть новые названия файлов, которые генерятся при минификации! Потому что как же нам еще разделить код и данные? Короче, считаю это ошибкой дизайна, когда оптимизация НАВЯЗАНА разработчику, то есть для 99% сайтов она будет делаться ПРЕЖДЕВРЕМЕННО.

Тоже самое можно сказать и про turbolinks. Во-первых очень мало народу понимает как оно в реальности работает, соответственно каких косяков ожидать. Это та же самая, мать ее, premature optimization. Всегда гораздо сложнее упрощать что-то сложное, чем добавлять и ускорять по мере необходимости.

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

И вот здесь детальнее, о чем я имею в виду https://blog.red-badger.com/blog/2016/06/22/docker-and-assets-and-rails-oh-my

Комментариев нет:

Отправить комментарий