Управление ассетами в WEB приложениях на Symfony


 На сегодняшний день существует большое количество фреймворков которые можно использовать в качестве фундамента для реализации разного рода WEB приложений. В нашей компании основным инструментом является Symfony. Чем этот фреймворк так хорош и почему мы его используем я опишу в следующей статье, а возможно даже в цикле нескольких статей. В данной же статье я постараюсь для вас описать концепцию управления так называемыми ассеты приложения на примере Symfony, хотя данный подход может быть так же актуален и для других фреймворков.
 В каждом WEB приложении в виду специфики исполнения клиентской части приложения в браузере пользователя используются JavaScript, CSS, LESS, SCSS, спрайты изображений. Каждая из этих составляющий состоит из библиотечной части и части созданной разработчиками приложения с использованием библиотечной части. Если с собственными ассетими все более менее понятно, то с библиотечными частями существует проблема поддержания актуальности версий в зависимостях. Для этих целей мы используем менеджер пакетов bower. Так же для управления собственными ассетами необходим инструмент обработки, компиляции, копирования и удаления. В данный момент существует множество инструментов для этих целей: Grunt, Gulp, Webpack. Каждый из этих инструментов хорош по своему, мы обычно в своих проектах используем Gulp.
 Менеджеры ассетов это хорошо, но мы придерживаемся политики минимального набора установленных компонентов на стейджинг и продакшн серверах. Каким образом мы следуем этому правилу? Все дело в том что все собранные ассеты можно подготавливать на стороне разработчика и не нагружать деплоймент такой работой. Рассмотрим для примера проект на Symfony со следующей структурой основного бандла:

AppBundle/
|- Resources/
   |- assets/
      |- fonts/
      |- images/
      |- javascripts/
      |- less/
      \- sprites/
   |- bower_components/
   \- public/
      |- css/
      |- img/
      |- fonts/
      \- js/
|- bower.json
\- gulpfile.js

 На примере данной структуры можно выделить несколько нюансов:

  1. Так как в проекте присутствуют несколько бандлов то у каждого бандла свой bower.json и gulpfile.js — благодаря этому поддерживается целостность самого бандла и его можно вынести в отдельный репозиторий для повторного использования в другом проекте.
  2. Разработка ведется в assets директории а Gulp настроен на целевую директорию сборки public и при этом assets и public отслеживаются и присутствуют в коммитах git.

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


Comments 4


Приветствую Вас и желаю успехов на платформе Голос!

В этой статье вы сможете найти ответы на большинство вопросов, возникающих у новичков. Также большую подборку ссылок на полезные материалы вы можете найти по этой ссылке
Оперативно получить помощь, вы можете присоединившись к нашему сообществу в Телеграм

Буду признателен, если расскажете, откуда Вы узнали о платформе Голос (ответьте цифрой):
1) увидел в Facebook
2) увидел в ВКонтакте
3) из поиска Google
4) из поиска Яндекс
5) из Steem
6) рассказал друг
7) другое (укажите в комментарии)

Чтобы быстрей освоится, присоединяйтесь к конкурсу для новичков, который идёт прямо сейчас!

20.09.2017 15:36
0

6

20.09.2017 15:50
0