Итак, у меня есть сайт. На нем раздельная структура, BackEnd и FrontEnd
Для FrontEnd - отдельный сервер, для backend - тоже отдельный, назовем их условно front.domain.com и back.domain.com. Вот тут оговорюсь, возможно, я не верно разделяю Front и Back, с такой кросс-серверной структурой я работаю первый раз, по этому возможно ошибка допущена еще в "фундаменте" проекта.
Проверяйте, правильно делаю?
1. На сервере ForntEnd - отрисовка страниц, но не средствами JS, а средствами PHP. Почему - оговорю ниже, возможно это тоже не верно
2. На сервере BackEnd - получение данных из базы некоторые функции, например получение кол-ва подписчиков
3. После перехода на ссылку: например domain.com/catalog, загружается требуемая страница, все динамические значения вставлены туда средствами PHP, далее при переходе по страницам сайт просто подгружает необходимый контент в блок, так со всеми ссылками.
Наконец-то, сам вопрос
Собственно, было бы все на 1-м сервере, т.е и BackEnd и FrontEnd - я бы мог в файле catalog.php просто подключить файл API сайта require("api.php"). Но я же такой, хочу на разных серверах ForntEnd и BackEnd. Окей, из положения можно выйти: написать весь API код в ForntEnd, но какой это тогда ForntEnd если он подтягивает данные с базы)) Из за этого я усомнился, верно ли я разделяю два этих компонента.
Знаю, что фронт - это грубо говоря то, что обрабатывается на клиенте. Я могу сделать все на JS, но тогда как сделать редиректы без перезагрузки страницы? при этом, чтобы оставалась еще и динамическая ссылка на ресурс
Алексей Николаев, это точно. Просто сама по себе интересна мне эта структура, на сколько я знаю так крупные проекты работают, а традиционно - все на одном сервер это я уже делал)
У вас большая каша, два раза пробовал че-нибудь вам написать, не смог...
Если вы генерируете HTML на сервере, то ваш фротенд — это только верстка и всякий мусор на JQuery (скорее всего — слайдеры, аякс, вкладки и попапы)...
Если вы имеете в виду SPA (одностраничные приложения), то бекенд не отдает верстку, он отдает все в JSON (как правило), а на фронте загружено полноценное приложение, которое знает какой роут бекенда дернуть при переходе на нужный урл, знает как перерисовать контент, знает как хранить состояния... При этом на фронте нет никакого PHP, так как по определению — это не фронт, это бекенд, тк серверный язык
Замечу — бекенд у вас тоже как-то коряво сделан сам по себе
Максим Федоров, да, именно по этому я и усомнился в правильности моей структуры. Смотрите, опять же, возьму за пример сайт на котором мы находимся.. Покликайте по Левому Меню, видите, переход без перезагрузки страницы, эту задачу выполняет фронтэнд? А теперь смотрите, я копирую ссылку с одного из табов левого меню, перехожу по ней, контент так-же появляется, как отрисовывается эта страница?
Марат Линберг, у меня этот сайт загружается обычным способом, но допустим, я понимаю о чем вы
К пример можно этот сайт взять — у него то поведение, которое вы хотите https://vc.ru/
видите, переход без перезагрузки страницы, эту задачу выполняет фронтэнд?
Да, приложение знает, что при переходе на какой-то урл нужно тянуть определеный роут из бекенда и тянет его, потом ответ заворачивает в шаблон и перерисовывает ддерево, бекенд при этом отдает JSON с данными
А теперь смотрите, я копирую ссылку с одного из табов левого меню, перехожу по ней, контент так-же появляется, как отрисовывается эта страница?
Работает также— приложение определяет url и тянет соответствующий дял него роут из бекенда в виде JSON и прорисовывает страницу
Максим Федоров, есть пример такого приложения? Только в небольшом масштабе, все никак не могу понять, как это работает, на бумаге вроде все понятно, слишком много аспектов создается при разработке. Могу ли я обратится к вам ВКонтакте? Чтобы на каких то сложностях разработки такого сайта, я мог поставить вопрос вам более конкретнее
У вас проблема с определениями:
frontend - все что работает на стороне клиента, то есть разметка html, стили css, скрипты javascript.
backend - серверная часть отвечающая за получение/обработку/возврат данных, в том числе за генерацию html при необходимости.
Конкретно в вашем случае все что написано на php это backend, какие бы задачи в нем не выполнялись.
Что же касается разделения серверов, то тут все просто: на одном реализуете api(сразу почитайте про REST) в котором реализуете обработку данных(модели и бизнес логику), на втором реализуете роутинг и генерацию frontend части(представления), которая уже будет работать с api. Но я бы отказался от динамической генерации на php, в пользу статического фронта работающего с api напрямую через js.
Марат Линберг, не совсем, попробую перефразировать ответ. Вам нужно понять что разделение серверов на фронт/бек это чистая условность для простоты администрирования. То есть сервер который отдает клиенту статику и/или выполняет балансировку/роутинг вы можете назвать фронтом для простоты, но по факту все сервера являются бекендом.
А в программировании фронт/бек это вариант архитектуры программного обеспечения и термины имеют вполне конкретные значения:
фронт - пользовательский интерфейс сервиса выполняющийся у клиента,
бек - программно-аппаратная часть сервиса.
Например, ваш пхп скрипт генерирующий страницу для пользователя является частью бекенда, а вот сама html-страница уже фронтенд.
т.е на серверах фронта мне нужно хранить клиентское приложение (js, html ...), а на серверах бэка API, так?
Вам не нужно, но вы можете при необходимости. Разделение на разные сервера в основном используется для распределения нагрузки в высоконагруженых проектах и не является обязательным. Учитывая ваш вопрос я сильно сомневаюсь что у вас есть такая необходимость. Ответьте себе: какую задачу вы пытаетесь решить разделением сервиса по разным серверам? Если конкретного ответа нет, то и делать этого пока не стоит.
FeNUMe, в том то и дело, я хочу понять, как устроены такие высоконагруженные проекты. Я понимаю, что это не обязательно, у меня множество мелких сайтов, которые расположены на одном сервере, включая их статику. Но меня берет сам интерес разделения бэкэнда и фронтэнда по серверам, т.е на фрот отдается только html, js и так далее, а дальше это все просто подтягивает информацию с помощью API на серверах backend. Честно говоря, не отказался бы посмотреть на код такого проекта
Одного подхода нет, есть у вас конкретные задачи, под них подбераете решение (архитектуру), можно постоянно подготавливать фронтэнд на бэкенде, можно отдавать заранее подготовленный фронтэнд (в виде ХТМЛ или ЖС файлов пользователю) который потом будет собирать у себя в браузере более сложный вид продукта.
==
Вам просто нужно определится как бы обмениваетесь данными между фронтэндом и бэкендом, обычно используют формат JSON (не обязательно).
Сейчас часто распространена схема при которой - JS скрипты в браузере клиента грузят с бэкенда только JSON с данными и отображают эти данные в более сложных формах непосредственно в браузере.
П. С.
логику редиректов и всякого такого роутинга можно написать на самом фронтэнде, перехватывая запросы пользователя и специфичным образом их обрабатывая, запрашивая нужные данные с бэкенда через апи.
Смотрите. Сайт на котором мы сейчас - toster.ru. Пощелкайте по его левому меню, видите? Страница как бы обновляет контент в себе без перезагрузки. Вопрос - как это реализовано, сейчас я делаю примерно так: https://habrahabr.ru/post/128552/
При этом, мне важно, чтобы API и сам сайт хранились на разных серверах, т.е на сервере фронтэнда файлы js, php(вообще html, просто с приемом параметров), стили и картинки, а на сервере API - один такой жирный файл, обращаясь к которому мы на выходе получаем JSON.
Нужно это для масштабируемости. За предидущий ответ спасибо.
Знаю, что фронт - это грубо говоря то, что обрабатывается на клиенте. Я могу сделать все на JS, но тогда как сделать редиректы без перезагрузки страницы? при этом, чтобы оставалась еще и динамическая ссылка на ресурс
Вот с этого надо было и начинать, и этим же и закончить свой вопрос! Всё остальное - бессмысленно.
HTML5 history API: статейка по тому, как это можно сделать.
Простой
Средний
