Как все-таки правильно разделять back-end от front-end?

Question

[Toopie]

Привет.
Всегда писал на PHP, потом перешел на менее известный язык, тоже для серверной разработки, ну да ладно.
Сейчас я тренируюсь писать и фронт и бек.
Теперь к проблемам:
Почти везде показано, что если, к примеру, брать PHP, то его можно встраивать сразу в HTML, но мне кажется, что такой подход не совсем корректный. Написал тестовый блог таким образом, что jQuery отправлял запрос к PHP, а PHP в свою очередь отдавал JSON, и даже JS сам ставил юзеру cookie.
Так вот, собственно, какой все таки метод правильный - писать PHP прям в HTML, или же, все таки, использовать PHP как API сайта, и посылать к нему запрос от JS?
Хотелось-бы сразу научиться правильно совмещать. Спасибо за внимание =)

Answer 1

[stul5tul]

Почти везде показано, что если, к примеру, брать PHP, то его можно встраивать сразу в HTML

Мало ли что там "почти везде показано".
Почти все примеры кода в интернете - существенно упрощены для вящего понимания.
Эти примеры нужно использовать с умом.

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

Поэтому практически во всех примерах нет этих проверок на ошибки.
Но это не значит, что в реальности эти проверки делать не нужно.

Так вот, собственно, какой все таки метод правильный - писать PHP прям в HTML, или же, все таки, использовать PHP как API сайта, и посылать к нему запрос от JS?

Нет безусловно правильного метода.

Если вы будете писать полноценное API для мелкого проекта - вы существенно затяните сроки и стоимость своих работ. А это полноценное API и не нужно будет.

Ну и наоборот. Писать сложный проект, мешая в одном файле JS/PHP/HTML - будет просто неудобно поддерживать и развивать по мере разрастания проекта.

Выбор правильного решения в том или ином случае - как раз показатель вашей квалификации.

Освойте просто все методы.

Comments

[Toopie]

Большое спасибо)

Answer 2

[Матвей Правосудов]

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

1. Если вам нужен простенький сайтец с базой, то ПХП можно встраивать в ХТМЛ и отдавать это в браузер.
   
2. Если у вас какое-то более-менее сложно приложение с несколькими разделенными частями (ака клиент, сервер, еще что-то), то придется инкапсулировать: сделать какой-нибудь контракт по взаимодействию (ака АПИ) и общаться только по нему. Тогда получится универсально использовать сервер, который будет отдавать данные строго в определенном формате.
   

Answer 3

[обычный чел]

самый простая и эффективная архитектура:

клиент через ajax передает и получает json-данные по https
авторизационные пароли внутри json-данных
кросдоменные запросы

так можно и сайт и моб-приложение делать
для большинства задач этого хватит - начинающему самое то

то есть php-сервер это web-api
это проще и лучше чем rest

json-web-api

воспринимай сервер как объект твоего ооп

Comments

[Toopie]

Спасибо!

[Андрей К]

Зависит... Я бы совсем не сказал, что это всегда правильный подход.

Деление на дар приложения могут создать лишние проблемы для простых решений.

В общем, нужно понимать требования и не мыслить шаблонно.

Answer 4

[0x131315]

По возможности стоит следовать принципу MVC, разделяя код на слой данных, слой логики и слой отрисовки - это сгруппирует однотипный код, и сильно упростит его поддержку.
Специфичные вещи, например работу с внешним API, следует оформлять в отдельные классы, модули, хэлперы - это облегчит работу с такими вещами, упростит отладку (сам класс можно протестировать отдельно), сгруппирует код: код, отвечающий за конкретное API, весь в одном месте. И когда этот код понадобится вновь - всё уже готово и отлажено, подключи класс и пользуйся.
Сразу весь функционал реализовывать не нужно - по мере надобности недостающее допишется. В крайнем случае можно набросать заглушки (пустые методы) для чего-то, что должно быть, но пока не нужно.

Что касается конкретно отрисовки - да, активное использование ajax и реактивных фреймворков серьезно улучшает приложении: гораздо проще реализовывать странички со сложным поведением, не нужно перерисовывать куски страниц, думать как разбить и обновить контент, просто отдаёшь данные, шаблон, и фреймворк сам перерисовывает нужные части.
Но что-то простое гораздо быстрее отрендерить на сервере, просто вставив в нужные места верстки php-код. Плюс серверный рендеринг скрывает промежуточные данные - в страничку вшивается только результат вычислений, и у пользователя нет никаких способов получить промежуточные данные, или даже узнать о том, что они существуют.
Так что для простых или важных вещей стоит пользоваться php, для сложных - отдавать данные по ajax, отрисовывать их на клиенте, а для неответственных данных можно даже вычисления перенести на клиент, но стоит помнить, что js немного неожиданно работает с некоторыми вещами: приведение типов, время, математика, числа с плавающей точкой.
Как промежуточный вариант можно пользоваться шаблонизаторами - с ними в несколько раз быстрее раскидать данные по шаблону, чем на чистом php, и код получается чище, но для сложного поведения все равно лучше реактивный фреймворк.

Comments

[Toopie]

Спасибо за подробное объяснение)