Каким образом взаимодействует сегодня Back-End и Front-End?

Question

[Alex Alex]

Доброго времени суток. Уже очень давно работал в веб-деве на фрилансе. Ранее все сайты писались по сути следующим образом: есть front и PHP. PHP с помощью функции echo отрисовывает html-элементы + свои данные из бд или еще где-то. По сути мы каждый раз перезагружаем страницу после такого запроса. Также для решения проблемы перезагрузки у нас был Ajax, который по сути давал возможности отправлять запросы через JS без перезагрузки.
Однако недавно решил попробовать вернуться в уже знакомую мне сферу, но встретил большие сложности с пониманием работы нынешних веб-приложений. По сути любое современное веб-приложение работает следующим образом: front и back общаются между собой HTTP запросами (фронт кидает request, получает response и обмениваются между собой JSON'om)??; то на JS с помощью условного React'a мы делаем HTTP запрос на сервер (где условно PHP), то PHP только лишь обрабатывает запрос, работает с БД и высылает готовые значения в JSON, которые уже отрисовывает на фронте React? По сути единственная задача бэка: направить JSON файл с необходимой инфой и все? В чем преимущество такого подхода? Не только ведь отсутствием перезагрузки...

Заранее спасибо за ответ и потраченное на него время :)

Comments

[Сергей delphinpro]

Каким образом взаимодействует сегодня Back-End и Front-End?

И сегодня, и 10 лет назад, и даже завтра одинаково – по http протоколу.

По сути любое современное веб-приложение работает следующим образом: front и back общаются между собой HTTP запросами (фронт кидает request, получает response и обмениваются между собой JSON'om)??; то на JS с помощью условного React'a мы делаем HTTP запрос на сервер (где условно PHP), то PHP только лишь обрабатывает запрос, работает с БД и высылает готовые значения в JSON, которые уже отрисовывает на фронте React? По сути единственная задача бэка: направить JSON файл с необходимой инфой и все?

Ну вот вы сами себе ответили. От нас-то чего хотите узнать?

[Alex Alex]

Сергей delphinpro, в тексте моего вопроса есть вопросительные знаки, которые, на удивление, означают вопросы. Я не отвечаю на свои собственные вопросы в тексте, а делаю предположения, каким образом это в теории может функционировать. Я задаю вопрос: React делает HTTP запрос на сервер и получает от него ТОЛЬКО response, содержащий JSON? Задаю второй вопрос: "По сути единственная задача бэка: направить JSON файл с необходимой инфой и все?" и задаю третий вопрос: современные приложения отличаются от тех, что были написаны на PHP, тем, что раньше PHP непосредственно выводил html-разметку, а сейчас эта функция перешла в руки js-фреймворков?

[Pavel Shvedov]

Alex Alex, ну например, тебе надо написать сервис, в качестве клиента которого будет и браузер, и мобильное приложение, и просто другие сервисы будут стучаться по твоему апи, зачем всем кроме браузера твои html выведенные через echo на php? Поэтому универсальнее отдать данные, а каждый из там вертит у себя как хочет, просто как одна из причин

[Сергей delphinpro]

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

[Сергей delphinpro]

Один нюанс - вы описываете схему взаимодействия SPA приложений. Но не всё в интернете сегодня SPA. Тостер, как видите работает по "старой схеме".

[Alex Alex]

Сергей delphinpro, если бы я четко знал, как все работает, не задавал бы вопрос. Я не хочу услышать, верно ли я предположил. Я хочу узнать, есть ли в моем понимании работы текущих веб-приложений пробелы или ошибочное представление. К сожалению, именно такого вопроса, который был задан, я не смог найти в гугле. Я спрашиваю по поводу того, как это работает в целом. Если я имею понятие как взаимодействует react PHP означает ли логически это то, что так же взаимодействуют vue, angular с каким-нибудь django, Ruby on Rails? Мне кажется нет, и поэтому я задаю вопрос как в целом работает взаимодействие фронта и бэка. Про toster - да, вижу. Огромное спасибо за ответ.

[Alex Alex]

Pavel Shvedov, спасибо, таким образом данное преимущество является одним из. Какие ещё такая модель даёт преимущества ?

[Сергей delphinpro]

Alex Alex,

Если я имею понятие как взаимодействует react PHP означает ли логически это то, что так же взаимодействуют vue, angular с каким-нибудь django, Ruby on Rails? Мне кажется нет

почему нет-то? какая фундаментальная разница между условными php и RoR или Vue и React, что вы сделали такие выводы?

[Сергей delphinpro]

Alex Alex, если речь идет о клиент-серверной архитектуре, совершенно не важно, как и на чём написаны клиент и сервер. На сервере может крутиться php, RoR да хоть на плюсах напишите, пофиг. Клиент тоже может быть любой, необязательно даже браузер, выше отметили, что это может быть и андроид приложение и все что угодно, хоть чайник.
Но они по-прежнему будут общаться между собой по схеме запрос-ответ.

Answer 1

[Alex Karo]

Нет, не все сайты работают так (с разделением на фронт/бэк) - некоторые по-старинке. И не всегда новый подход оправдан.
В основном имеет смысл там, где много интерактива - при старом подходе все равно приходится делать апи для всяких lazy-load/поиска/фильтрации, решать где/как будут хранится шаблоны, в каком формате передавать и пр. При новом подходе за все это отвечает фронт, бэк предоставляет только данные.

• Чаще всего используется http+json для взаимодействия фронт-бэк, но есть варианты.
  
• С помощью React мы запрос не делаем. React это что-то вроде продвинутого шаблонизатора. Запрос мы делаем через js (browser api). Бэк только отдает json.
  

Преимущества:

1. Можно разделить работу фронт и бэк команд
   
2. Можно переписать фронт/бэк, используя интерфейс API как контракт взаимодействия
   
3. Между фронтом и бэком бегают чисто данные, без шаблонов. Но см. п. 3 недостатков.
   
4. Перенос нагрузки с бэка на фронт (редко это оправдано, но все же).
   
5. Интерфейс становится более отзывчивым (если делать все хорошо)
   
6. Проще протестировать поотдельности
   

Недостатки:

1. Больше кода, больше компетенций, сложнее система
   
2. Проблемы с индексацией, задейсвуются смешанные варианты (SSR)
   
3. Размер кода на фронте, больше нагрузка на устройства
   

Наверняка не все перечислил - то, что быстро пришло на ум.