Spring MVC: что происходит со статикой?

Я только начал изучать Spring.

Скажите, пожалуйста, применяется ли в мире Spring веб-сервер nginx?

Если да, то для каких задач (балансировка нагрузки, раздача статики)?

Если nginx применяется для раздачи статики, как ему "подсунуть" эту статику? Обычно она у него лежит где-то в каталоге типа /var/www/my_site/static. И перекладывать ее туда я привык специальным скриптом из коробки фреймворка. Но фреймворк это должен уметь делать. Т.е. он должен потом суметь эту статику найти, потому что ему же рендерить html надо. Спринг такое умеет?

Если nginx не применяется для раздачи статики, то как ее раздают?
Томкатом? Что работает быстрее при раздаче статики: Tomcat или nginx?

А если я хочу часть функционала использовать повторно, видимо, мне reusable функциональность надо будет скомпилировать в jar и использовать его в своих проектах как библиотеку. Это что же - Томкат будет будет jar-файлы молотить?

А если я захочу использовать CDN, надо же будет все-таки статику скопировать туда. Значит, Спринг должен как-то узнать, где у него статика будет на проде лежать. Как это сделать?

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

0

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

1

Меня интересует сейчас только MVC. Чтобы сайт заработал, нужно его обеспечить статикой тоже.

Я разговариваю с опытными ребятами, но они мне толком ничего не говорят. И ответ может быть таким: я изначально статику делу отлельно, а собираю ее с помощью вебпак.

Ну, не знаю. Сомнительно что-то. Просто получается, что структура проекта вряд ли интуитивно понятна.

Хорошо, допустим CDN. Но Spring должен узнать, где положена статика. Как это можно сделать, чтобы не хардкодить?

Добавлено через 10 минут
Во-первых, не хардкодить.
Во-вторых, собрать всю статику, которая лежит в проекте.
Согласно тьюториалу, статика лежит во множестве каталогов /static (https://spring.io/guides/gs/se... _home_page)

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

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

Мне бы вот как-то это понять. Потому что в тьюториалах это не написано.

0

Сообщение от Kifsif я изначально статику делу отлельно, а собираю ее с помощью вебпак.

При чём тут веб-пак — непонятно.

Сообщение от Kifsif Но Spring должен узнать, где положена статика. Как это можно сделать, чтобы не хардкодить?

Что именно у тебя в статике? JS? Ну да, хардкодить, например "/static/script/main.js", а Nginx'ом, например, "my_site/static/*" редиректить или просксировать на CDN. Или самим Nginx'ом и раздавать.

Сообщение от Kifsif И перекладывать ее туда я привык специальным скриптом из коробки фреймворка. Но фреймворк это должен уметь делать.

Каким ещё скриптом фремворка? Это делается деплой-скриптами.

Миниатюры

 

1

Сообщение от Kifsif Согласно тьюториалу, статика лежит во множестве каталогов /static

Это тьюториал для новичков. В реальном проекте статика лежит отдельно и Spring о ней не знает.

1

Есть несколько вариантов
1. У тебя рестфул бекенд и он ничего не знает о фронте. Фронт лежит в отдельном репозитории, у него свой лайфсайкл и свой деплой. Отдачей фронта занимается nginx.
2. У тебя монорепозиторий и фронт это модуль в твоем maven проекте. У фронта есть pom.xml (например с плагином frontend-maven-plugin), который запускает сборку как часть maven цикла. Путь до корня фронта указывается в pom.xml Результатом сборки является jar файл, который как зависимость добавляется в бек. В результате получается jar файл (рассматриваем версию спринг бута), в котором статику отдает embedded tomcat.
3. Статика лежит в папке /src/main/resources/static (дефолт для спринг бута) или в любой другой папке и тогда делается доп. конфигурация чтобы замапить это папку. Таким образом статику так же отдает встроенный томкат.
-------------
Как я уже написал выше, разница в скорости нивелируется тем, что все это дело сидит за CDN, который все равно поднимает caching proxy в локации юзера.

2

Сообщение от korvin_ Что именно у тебя в статике? JS? Ну да, хардкодить, например "/static/script/main.js", а Nginx'ом, например, "my_site/static/*" редиректить или просксировать на CDN.

В статике картинки для интерфейса сайта и JS.

Ну, я вообще ничего не понимаю.

Редирект или проксирование выльется в катастрофическое замедление. Это просто медленнее на прогон туда и обратно. Картинку прилагаю. Ну, ладно - пусть не на 1,1 секунду замедлится - уберем там DNS, чего-то еще. Но добрых полсекунды я потеряю.

Иначе говоря я-то предлагаю сразу раздать с CDN.

А вы мне предлдагаете такое: летит запрос на наш сервер. Но наш сервер говорит - так, ты зря сюда пришел. Иди вон там на CDN. Там возьмешь (редирект).
Или: а, ты за статикой, сейчас я сам схожу, ты тут подожди. Вот, принес. Забирай (проксирование).

Да и какой вот смысл-то CDN тогда? CDN на то и применяется, чтобы максимально близко к юзеру быть. Чтобы прогоны сократить. CDN раздает статику с ближайшего к юзеру сервера. А так мы все через себя прогоняем.

Сообщение от korvin_ Или самим Nginx'ом и раздавать.

Это было бы неплохо. Да вот беда, я не знаю, как nginx-у подсунуть эту статику.

Сообщение от korvin_ Каким ещё скриптом фремворка? Это делается деплой-скриптами.

А как фреймворк узнает, какой путь рендерить? Чтобы не было вот этих вот кругов с редиректом и проксированием, надо сразу рендерить.

Пример из Django:

Статика лежит во множественных каталогах static, по всему проекту.
И фреймворк знает, где ее взять, потому что ему сказали в настрйоках: STATIC_URL = '/static/'
Мы на локалке ведем разработку, и фреймворк об этом знает. Потому что DEBUG=True. Отладочный веб-сервер джанги берет статику оттуда, где она лежит в проекте.
В шаблоне <img src="{% static "my_app/example.jpg" %}" alt="My image">.
В настройках задается также: STATIC_ROOT = "/var/www/example.com/static/" . Это где статика будет лежать на боевом серваке.
Когда проект разворачевается на продуктивном сервере, выполняется команда python manage.py collectstatic
И по всему проекту статика собирается, и перекладывается в нужный каталог.
А в случае CDN настройки будут такие: STATICFILES_STORAGE = 'myproject.storage.S3Storage' . И все: теперь collectstatic зальет статику на Amazon’s S3.

И логично же все: и не захардкожено, и фреймворк знает, какой путь до статики рендерить.

А со Спрингом - ну, я вообще не знаю. Может, как-то и можно. Но об этом как-то никто особо не знает. Я же с ребятами разговариваю. Они говорят примерно: Интересные вопросы задаёшь. Порой даже самому приходится задуматься - "а почему я делал иначе".

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

Миниатюры

 

0

Сообщение от KEKCoGEN В результате получается jar файл (рассматриваем версию спринг бута), в котором статику отдает embedded tomcat.

JAR - это же архив. Это что томкат будет архивы лопатить постоянно? Я сейчас открыл первую попавшуюся страницу. Один html-документ, это понятно. А запросов 367. Ну, ладно, там отбросим всякие внешние гугл аналитики и прочее. Ну, пусть 100 запросов за нашей статикой. И это одна страница. Я все правильно понимаю? Т.е. веб-сервер каждый раз откроет архив, возьмет файл, закроет архив. Отдаст. Это вообще так и делается? И как это по производительности, если с nginx сравнить?

Сообщение от KEKCoGEN Статика лежит в папке /src/main/resources/static (дефолт для спринг бута) или в любой другой папке и тогда делается доп. конфигурация чтобы замапить это папку. Таким образом статику так же отдает встроенный томкат.

Это возможно. Но вот беда - бывает же reusable функционал. Его надо будет как-то к проекту подключать. И будет он, видимо, в виде jar-файла. Допустим, я напишу функционал для лайкв-дислкйков. У него есть какой-то JavaScript, потом возможность сохранить в базу данных все. Может быть, какие-то картинки. И вот я хочу это все хозяйство применять на десяти сайтах. Соответственно, это все должно удобно подключаться. Видимо, все-таки это будет jar-файл. Это что же опять архивы томкатом ворочать?

Вообще говоря, как томкат по производительности по сравнению с энджиникс при прочих равных?

0

Сообщение от Kifsif А вы мне предлдагаете такое: летит запрос на наш сервер.

думаю тебе стоит почитать как работает CDN. Запрос никогда напрямую не попадает на оконечный сервер. DNS сайта настраивается на CDN

1

Сообщение от KEKCoGEN думаю тебе стоит почитать как работает CDN. Запрос никогда напрямую не попадает на оконечный сервер. DNS сайта настраивается на CDN

Стоп, стоп. Выше было ведь написано, что запрос прилетит на наш сервер. Оттуда редирект или проксирование на CDN. Если я правлильно понял. Я акцентирую внимание только на том, что первый запрос за статикой прилетит на наш сервер, оттуда будет редирект или проксирование. И я предполагаю, что в этом случае будет очень медленно, и вообще если все через себя гнать, нет смысла в CDN.

0

Сообщение от KEKCoGEN думаю тебе стоит почитать как работает CDN. Запрос никогда напрямую не попадает на оконечный сервер. DNS сайта настраивается на CDN

Стоп, стоп. Выше было ведь написано, что запрос прилетит на наш сервер. Оттуда редирект или проксирование на CDN. Если я правлильно понял. Я акцентирую внимание только на том, что первый запрос за статикой прилетит на наш сервер, оттуда будет редирект или проксирование. И я предполагаю, что в этом случае будет очень медленно, и вообще если все через себя гнать, нет смысла в CDN.

0

Сообщение от Kifsif JAR - это же архив. Это что томкат будет архивы лопатить постоянно?

нет. На томкате в конечном итоге лежит распакованный архив.

Сообщение от Kifsif Видимо, все-таки это будет jar-файл. Это что же опять архивы томкатом ворочать?

похоже у тебя сильно не хватает понимания как работает spring boot в связке с встроенным томкатом и вообще как строятся приложения.
Все что ты написал имеет мало смысла. Если тебе это нужно как реальная задача, то лучше сделай её вместе с более опытным коллегой, если это задача для обучения, то лучше начать с более базовых концепций.

Добавлено через 7 секунд

Сообщение от Kifsif JAR - это же архив. Это что томкат будет архивы лопатить постоянно?

нет. На томкате в конечном итоге лежит распакованный архив.

Сообщение от Kifsif Видимо, все-таки это будет jar-файл. Это что же опять архивы томкатом ворочать?

похоже у тебя сильно не хватает понимания как работает spring boot в связке с встроенным томкатом и вообще как строятся приложения.
Все что ты написал имеет мало смысла. Если тебе это нужно как реальная задача, то лучше сделай её вместе с более опытным коллегой, если это задача для обучения, то лучше начать с более базовых концепций.

Добавлено через 1 минуту

Сообщение от Kifsif Я акцентирую внимание только на том, что первый запрос за статикой прилетит на наш сервер, оттуда будет редирект или проксирование.

нет. Это не так работает

1

Сообщение от korvin_ например, "my_site/static/*" редиректить или просксировать на CDN.

Я вот про эту фразу говорил. Тут было предложено редиректить. Или я неверно понимаю именно эту фразу?

Добавлено через 11 минут

Сообщение от KEKCoGEN Все что ты написал имеет мало смысла.

Вы бы лучше мне сказали, как именно правильно делать. А то постоянно: вот ты не понимаешь, смысла мало, все не так. Ну, конечно, не понимаю. Потому и спрашиваю.

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

0

Сообщение от Kifsif Вы бы лучше мне сказали, как именно правильно делать.

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

1

Сообщение от Kifsif Редирект или проксирование выльется в катастрофическое замедление.

Нет. Кроме того, статика прекрасно кэшируется браузером.

Сообщение от Kifsif Но добрых полсекунды я потеряю.

Значит, ты что-то делаешь не так.

Сообщение от Kifsif Да вот беда, я не знаю, как nginx-у подсунуть эту статику.

В build-скрипте docker-образа nginx'а.

Сообщение от Kifsif А как фреймворк узнает, какой путь рендерить?

Сообщение от Kifsif Пример из Django: Статика лежит во множественных каталогах static, по всему проекту. И фреймворк знает, где ее взять, потому что ему сказали в настрйоках: STATIC_URL = '/static/'

Сам себе ответил.

Сообщение от Kifsif Мы на локалке ведем разработку, и фреймворк об этом знает. Потому что DEBUG=True. Отладочный веб-сервер джанги берет статику оттуда, где она лежит в проекте.

Вот прекращай так делать и подними себе nginx локально. Хоть нативно, хоть через docker.

Сообщение от Kifsif Когда проект разворачивается на продуктивном сервере, выполняется команда python manage.py collectstatic

Нормальные люди давно так не делают.

Сообщение от Kifsif В общем, никто ничего не может нормально сказать.

Тебе нормально сказали и картинку показали. Кто ж виноват, что ты не понимаешь объяснения?

1

Сообщение от korvin_ Нет. Кроме того, статика прекрасно кэшируется браузером.

Кешируй в браузере - или не кешируй, это дело не изменит. И никак ничему не поможет. Причина: юзеры всегда новые. Из поиска или из рекламы пойдут, практически в 100 % случаев. Так что как ни крути, редирект выльется в потерю скорости - это к гадалке не ходить.

0

Сообщение от Kifsif Кешируй в браузере - или не кешируй, это дело не изменит. И никак ничему не поможет. Причина: юзеры всегда новые. Из поиска или из рекламы пойдут, практически в 100 % случаев. Так что как ни крути, редирект выльется в потерю скорости - это к гадалке не ходить.

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

Не хочешь редиректить/проксировать, я тебе уже писал: отдавай статику nginx'ом. В чём проблема?

1