Всем привет, меня зовут Григорий и вот уже полгода я никак не могу понять как правильно готовить Web! Очень нужна помощь знающих людей.
Гуглить я умею довольно не плохо, занимался этим долго и упорно, прочитал огромную кучу разнообразных статей, на себе попробовал различные инструменты, но мозаика в моей голове все никак не сложится, и мозг уже кипит из-за всей этой информации, которую я никак не могу структурировать.
1. Есть фронт-энд, который выполняется на стороне клиента
2. Есть бэк-энд, который выполняется на стороне сервера
Для того чтобы готовить фронт-энд есть огромная куча инструментов: Grunt и RequireJS, Gulp и Browserify, Webpack...
Давайте пока не будем трогать MVC фреймворки типа Backbone, ReactJS, AngularJS, я хочу разобраться с основами.
Предположим в данный момент я использую 2 инструмента для фронт-энда: Gulp и Webpack.
Мне нужно сверстать 2 страницы, полностью идентичные, но на которых в меню были бы выделены 2 разных пункта, в зависимости от того, какая страница открыта. И так же присутствует динамическая информация - кнопка, если пользователь залогинен то показывается надпись "профиль", если нет то "вход".
Во первых, я хочу оптимизировать процесс верстки HTML страниц, то есть я не хочу верстать одинаковые элементы по нескольку раз, и было бы не плохо такие повторяющиеся элементы вынести в модули. Но казалось бы такую элементарную операцию сделать крайне трудно. Есть огромное количество JS шаблонизаторов типа Handlebars, Mustache, Underscore... но все они работают через JavaScript, а я хочу собрать нормальную HTML страницу, которая будет готова сразу без необходимости грузить скрипты. Еле-еле нашел такой инструмент для Gulp'a как "gulp-file-include". Но это явно какие-то костыли, и писать серьезное web-приложение на его основе стремно, должен быть какой-то другой путь, вопрос какой?
Во вторых, предположим я сверстал такие страницы, все ок, но как мне проверить залогинен пользователь или нет? На помощь к нам приходит бэк-энд. Каким образом нам получить данные? Мы можем собирать страницы на сервере и возвращать уже готовые либо с кнопкой "профиль" или с кнопкой "вход". На мой взгляд это не совсем верный путь, потому что, во первых, зачем нам Gulp и Webpack если сборка будет происходить на сервере, во вторых, сервер по-хорошему не должен заниматься такими задачами как сборка страниц для пользователя. На мой взгляд сервер должен возвращать мою сверстанную страницу из прошлого пункта и что-то типа JSON'а с данными, которые я при рендеринге смогу вставить в нужные места, например проверю залогин ли пользователь и покажу правильную кнопку. Но как это сделать я тоже не понимаю, этого можно добиться только если после загрузки страницы в скрипте посылать AJAX запрос на необходимые данные и потом уже изменять страницу, но это тоже явно не верный путь, потому что нам требуется дополнительный запрос к серверу, что плохо, и в то время пока мы будем ждать ответа нам не известно что показывать на странице.
На мой взгляд бэк-энд вообще не должен заниматься компановкой HTML, он должен работать с данными в базе, роутингом, и выдавать на клиент данные в виде JSON.
Так каким образом мне получить страницу с правильными данными?
Моя голова скоро лопнет от отсутствия решения этих вопросов, люди добрые, срочно нужна помощь!!!
Шаблонизаторы? Почти все они могут выполняться на сервере и прекомпилироваться или вообще собираться в html. Отдельно рекомендую посмотреть в сторону jade.
Каким образом нам получить данные?
Видно что вы гуглили, написали много букв и до таких вещей как "клиент-серверная архитектура", REST, и тд. вы не добрались...
На мой взгляд сервер должен возвращать мою сверстанную страницу
Это одна точка зрения. Если брать каноническую клиент-серверную архитектуру, фронтэнд и бэкэнд (по сути клиент и сервер) - это два независимых приложения (ну как независимые... им плевать на реализацию друг друга). Далее мы можем просто частично переносить какие-то слои туда сюда. Причем это обычно связано с какими-либо оптимизациями, будь то производительность или уменьшение другой головной боли (например гуглы научились нормально индексировать single page application-ы относительно недавно, и прекомпиляцию на сервере организовывать приходилось отдельно).
На мой взгляд бэк-энд вообще не должен заниматься компановкой HTML
Это другая точка зрения, и я ее в принципе поддерживаю и придерживаюсь последние пару лет. Опять же - гуглите в сторону REST Api. Инфы валом, есть масса лекций, докладов и презенташек...
<< до таких вещей как "клиент-серверная архитектура", REST, и т.д. вы не добрались... >>
REST Api это же просто GET и POST запросы, то что мы посылаем запросы на сервер это как бы очевидно, или вы имели ввиду что-то другое?
P.S.: раньше работал iOS разработчиком и за спиной не одно клиент-серверное приложение. Думал что более-менее имею представление о REST.
Под словами << Каким образом нам получить данные? >> имелось ввиду не "что нам нужно сделать для этого", а "в каком виде, формате"?
<< Шаблонизаторы? Почти все они могут выполняться на сервере и прекомпилироваться или вообще собираться в html. Отдельно рекомендую посмотреть в сторону jade. >>
Первая часть моего вопроса не относится к бэк-энду, мне интересно как можно собрать из шаблонов HTML страницу локально. А все шаблоны про которые я читал, в том числе и Jade, являются JavaScript шаблонизаторами , то есть они выполняются уже после загрузки страницы, во время выполнения скрипта. А я хочу иметь готовую собранную страницу, которую просто буду возвращать с сервера на клиент.
Григорий: javascript нынче можно запускать хоть на клиенте хоть на сервере. Тот же jade можно компилить в js, а можно сразу в html, и тогда все будет происходить на сервере.
что до REST - это целая архитектура, идеология. Representational State Transfer. И это далеко не только POST/GET. Это еще куча всего, больше чем просто "применение HTTP". Мобильщики к слову редко в этом разбираются что плохо. Как формат вы используете для передачи "состояни" уже ваше личное дело. Хотите - json, хотите, xml, хотите - вообще protobuf. Это только формат данных. Рекомендую в этом ключе посмотресть спецификацию jsonapi.org
При первом запросе к серверу — он возвращает вам SPA приложение целиком. Потом это приложение уже общается с сервером как с API, работая только с данными.
То есть при первом запросе сервер в любом случае должен заниматься сборкой HTML страницы, которая будет показана пользователю. А следовательно, если у нас много страниц, сервер должен быть в состоянии собрать любую из них. Получается что полностью освободить сервер от данных обязательств не возможно и логика сборки HTML шаблонов должна присутствовать обязательно?
Если я хочу работать с сервером только как с данными, во первых, нужно будет реализовать обычное поведение сервера в том плане, что настроить рендер HTML страниц, а потом уже поверх накладывать еще дополнительную логику на большинство action'ов, что они должны делать в случаях если я запрашиваю HTML или JSON. Получается так?
Григорий: сервер собирает каркасную страницу и отдает ее вместе с клиентской логикой самому клиенту. На клиенте логика заполняет эту каркасную страницу данными, в зависимости от запроса. Таким образом серверу не надо уметь генерировать прям любую страницу, а хватит одной-нескольких каркасных в зависимости от сложности приложения.
Например в ASP.NET генерированием этих каркасных страниц занимается MVC контроллер. А отдачей данных занимаются Web API контроллеры. К каждому идет обращение через определенный маршрут. Вместе они как раз и сочетаются в полноценный сервер.
Простой
