Лукас Фриц

Я присоединился к команде Exponea 4 месяца назад (в апреле 2016 г.) с желанием изменить мир к лучшему, разработав многообещающий продукт и воплотив в реальность свежее технологическое видение.

Все, что у меня было, — это любовь к фронтенд-технологиям (в частности, Angular) и решению сложных задач с производительностью и визуализацией, надежда расширить свои навыки в улучшении пользовательского опыта одностраничных приложений (то, что я влюбился, когда работал с Андресом Галанте) и, наконец, что не менее важно, рекомендация моего друга Вильяма, который заверил меня, что проект находится в хорошем состоянии. С другой стороны, присоединение к работающему проекту всегда сопряжено с определенными трудностями: много нового нужно узнать, особенности продукта и кодовой базы, к которой нужно привыкнуть…

Exponea ничем не отличалась. В то время приложение было Angular 1.4, и оно было логически разделено на 47 модулей, которые разделяли 123 общих директивы Angular. В целом кодовая база выглядела хорошо управляемой с несколькими действительно умными идеями. Но были и вещи, которые мне не нравились, такие как структура таблиц стилей CSS и, самое главное, отсутствие сквозных тестов. (Подробнее об этом позже.)

Быстрый рабочий цикл для повышения производительности

Спустя несколько вводных задач стало очевидно, что настройка разработки потребует некоторого внимания — шаг сборки LESS с перезагрузкой приложения занял слишком много времени. Те, кто имел возможность работать со мной ранее, знают, что я отношусь к быстрой разработке действительно серьезно ;-)

Улучшение времени сборки МЕНЬШЕ

Несколько хирургически точных вырезов в сборке Gulp — это все, что понадобилось, чтобы избавить профиль разработки процесса сборки от ненужных тем приложений, ввести кэширование промежуточных результатов компилятора LESS и отключить минимизацию. Полученные таблицы стилей CSS были перезагружены на месте без необходимости полного обновления страницы с помощью Browsersync, а исходные карты были созданы, чтобы помочь людям ориентироваться в коде перед компиляцией. В целом, это огромный прирост производительности, и требуется всего 3 секунды, чтобы увидеть изменения в файлах LESS.

Как большое количество маленьких файлов может убить браузер

Однако вскоре я обнаружил другого, более зловещего виновника медленного цикла разработки: все HTML-шаблоны и исходники JS отправлялись в браузер неминифицированными, разбитыми на сотни файлов во время разработки. Браузеру потребовалось еще несколько секунд, чтобы извлечь все исходники из HTTP-сервера Flask, работающего внутри бродячей машины.

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

Service Worker спешит на помощь

Service Worker служит промежуточным звеном между браузером и HTTP-сервером, обрабатывая все запросы ресурсов и позволяя предварительно загружать, кэшировать (или создавать) файлы в первую очередь для автономного использования веб-страницы.

В нашем случае Service Worker кэширует все запросы, не относящиеся к API, и открывает сокет для процесса-наблюдателя Gulp. Процесс отслеживает все файлы JS и HTML и обновляет Service Worker об изменениях, внесенных в исходный код. Service Worker, в свою очередь, удаляет файл из кеша, заставляя браузер загрузить новую версию файла. С этим изменением мы смогли сократить время, необходимое приложению для перезагрузки после каждого изменения, до 3 секунд в случае изменений файлов LESS и 4 секунд в случае изменений файлов JS и HTML.

Вуаля, разработчики снова счастливы!

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

Наши текущие усилия и планы на будущее

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

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

В процессе мы придумали новую компонентно-ориентированную архитектуру CSS и начали создавать демонстрацию наших компонентов. Сейчас мы переходим на TypeScript и вскоре планируем перейти на Angular 2.0.

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

PS: В настоящее время мы находимся в процессе обновления до AngularJS 2.0 и мы ищем новых разработчиков, которые нам помогут.

PSS: Хотите знать, как все началось? Читать часть I: Первое приложение на AngularJS в моей жизни: история Exponea