Какие есть практики интеграции статического сайта и динамического веб-приложения?

Question

[Олег Правдин]

Здравствуйте. Во время изучения веба пришел к выводу, что для веб приложения необходима "обертка" в виде различной +-статики: домашняя страничка, "о компании", лэндинг страницы, страницы с прайсом на продукт, FAQ и прочие, где не требуется быстрое изменение контента. В крайнем случае к статике можно подключить отдельные динамические компоненты (например, подготовленные Vue компоненты и т.п.).
Я прихожу к выводу, что для таких объемов контента нет смысла писать свой костыль-CMS в приложении. Вместо этого я заинтересовался применением популярных CMS или генерируемых сайтов (когда сайт пишется на локальной машине, а затем "компилируется" в статику). Возникли несколько вопросов:

• Какие вообще решения и продукты для этого используют?
  
• Как конфигурируется веб-сервер в таких случаях? По умолчанию отдает данные из статики, а начиная с какого-то пути - (/app, например) - общается с приложением? Приложение на субдомене app.site.com?
  
• Как называется такая разработка вообще? Проще говоря, что мне забить в гугл, чтобы наткнуться на статьи с примерами таких интеграций?
  
• Если я что-то делаю не так, то что?
  

Answer 1

[Robur]

разделяете в голове одно от другого отдельно статика (html/js/ картинки, вот это все что лежит просто в файлах в том же виде в котором их получит клиент), отдельно HTTP api.
Дальше ответы на большинство ваших вопросов приходят сами. в целом - как угодно, в зависимости от ваших условий, желаний и предпочтений.

Можно статику отдавать по одному имени, а апи по другому. app.mydomain.com и api.mydomain.com
или и то и другое по одному имени, но для апи будет отдельный путь /api например или и для апи и для статики будут разные пути mydomain.com/app и mydomain.com/api
или на разные порты
Можно разделение сделать на nginx/apache. А можно на уровне вашего бекенда.
А можно статику вообще положить в облако и пусть они там думают про все. А бекенд положить в какие-нибудь контейнеры. Или вообще на serverless технологиях и вообще не знать где этот ваш код запускается и как к нему запросы идут, достаточно знать только урл.

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

Но самый обычный способ - статика на один урл, апишка на другой.

Answer 2

[Владимир Будаков]

Вбей в гугл «flat file CMS».
Такие CMS генерируют статические страницы, есть админка для управления контентом. Для простеньких проектов, как ты описал, пойдут.

Answer 3

[lukoie]

Есть ЦМСки, которые могут и динамику, и там же позволяют делать статические страницы. Например так можно в ОктябрьЦМС.
Та даже в банальном Вордпрессе есть возможность так сделать.
Если надо ручками, просто разделяете по путям. Либо по субдомену(хуже для сео, удобней в администрировании) либо по субдиректории(лучше для сео).

Comments

[Олег Правдин]

Есть ли смысл индексировать само приложение если оно все равно работает только после авторизации

[lukoie]

Олег Правдин, для развития своего проекта все равно понадобится сео, потому надо будет какой то бложик, какие то информационные страницы. Если динамический контент будет только по авторизации - то не будет проблемы использовать субдомен.
Если же будет динамический контент и для неавторизированных, то лучше субдиректория, чтобы поисковик индексировал как один сайт, а не два, как в случае с субдоменом.

[Олег Правдин]

lukoie, Динамический только для авторизованных :)
Поэтому я и поинтересовался у опытных людей, как лучше сочетать (или не сочетать) этот контент

[lukoie]

Олег Правдин, тогда разницы нет. А потому удобней на субдомен вешать. И тут уже по выбору, как решите - если будет сайтик(одностраничник или бложик), то в корень ложите его,а свой динамический ложите в субдомен. Так удобней и доступы организовать для разрабов, и бекапиться, и вообще управлять.
Если же надо чтобы удобней доступаться пользователям(на сервис.ру а не апп.сервис.ру) то ложите динамику в корень, а сайтик в субдомен. И для неавторизованных - редирект из корня в субдомен(например если пришли на сервис.ру незалогиненными, то отдавать им блог.сервис.ру).
То есть тут нет единственно-правильного решения, всё зависит от общей концепции проекта и внутреннего дзена его продактменеджера.