Из своего опыта в веб-разработке я знаю, что такие языки, как PHP, Java, Python и т. Д., Используются для бэкэнд-разработки (программное обеспечение, работающее на сервере), а для интерфейсных языков используются JS / HTML / CSS.
Но я вижу, что многие компании говорят, что они используют, например, PHP для фронт-энда и Python для бэк-энда.
Означает ли это, что PHP является внешним интерфейсом для вызова других сервисов, написанных на других языках через REST, RPC ..etc?
Ответы:
Вы перепутали термины «интерфейс» и «фон» с «серверной» и «клиентской». «Back-end» обычно относится к системам, которые непосредственно не предоставляются пользователю (серверы баз данных, промежуточное программное обеспечение и т. Д.), В то время как «front-end» обычно относится к приложению (в случае с Web это обычно означает статический и динамические веб-страницы), к которым непосредственно обращается клиент.
В веб-приложении клиент (браузер пользователя) получает доступ к веб-страницам, которые хранятся или динамически генерируются «на стороне сервера» с помощью «интерфейсных» технологий. Эти внешние компоненты могут, в свою очередь, извлекать данные или другую информацию из «внутренних» компонентов. Таким образом, веб-приложение, написанное на PHP, будет "front-end", но "server-side". Однако, если веб-страницы содержат какой-либо javascript, который должен выполняться браузером пользователя, этот код javascript будет выполняться «на стороне клиента».
Надеюсь, я устранил некоторую путаницу, но теперь я рискну создать еще немного.
Во-первых, у нас есть AJAX , который является кодом (обычно JavaScript), выполняемым на клиенте (т.е. на стороне клиента), для создания веб-страниц, которые вы видите, извлекая информацию из интернет-сервисов, которые сами не генерируют веб-страницы. Службы генерируют свою информацию на стороне сервера на внешнем интерфейсе (так как они общедоступны, и вы можете указать свой браузер прямо на них, если знаете URL).
Во-вторых, JavaScript, конечно, не ограничивается использованием на стороне клиента. Он становится все более популярным в качестве языка «на стороне сервера» (см. Node.js для одного примера). Как таковое, его наиболее распространенное использование предназначено только для тех интернет-сервисов, которые я описал в предыдущем абзаце.
До Web 2.0 все было намного проще . В то время в контексте веб-приложений во внешнем интерфейсе создавались веб-страницы, а JavaScript запускался только на стороне клиента и создавал незначительные косметические элементы для веб-страниц, такие как яркие изображения, когда вы наводили на них мышь. Однако эта простота заставляла людей лениться в своих определениях. Сейчас ситуация более сложная, поэтому важно быть точным в отношении этих терминов.
(О, и если вам нужно использовать PHP, пожалуйста, оставьте его на переднем крае. Это решительно не очень хорошая серверная технология. И если вы когда-нибудь найдете кого-нибудь создающего браузер, который выполняет PHP на стороне клиента, снимайте их.)
источник
Я думаю, что ваш вопрос может быть довольно специфичным для PHP, так как я не вижу ни одной другой упомянутой вами серверной технологии, используемой таким образом.
PHP - забавный пример, поскольку его можно (довольно уродливым образом добавить) рассматривать как язык «все в одном» в отношении многих веб-проектов. Вы можете выполнять свои традиционные « фоновые » задачи - такие как операции с файлами и базами данных, а также создавать разметку « front-end ».
Это может явно привести к беспорядку спагетти, где нет реального разделения беспокойства, таким образом, это должно действительно быть осуждено в моем разуме. Например, если вы просматриваете источник WordPress, вы часто можете потеряться - и это один проект, в котором я виню язык, организация кодовой базы на самом деле очень хорошая.
В некоторой степени это можно исправить, используя « шаблонизатор » (такой как Smarty ) - но это все еще PHP, который создает « front-end» и одновременно предоставляет «back-end» функциональность. Это было намеренное решение, лежащее в основе дизайна PHP, однако, это ведь « процессор гипертекста »!
Таким образом, PHP может легко приспособиться как к « внешнему », так и к « внутреннему », что должно прояснить ваш пример. Следовательно, вы, скорее всего, правы в том, что PHP будет обрабатывать и создавать всю разметку для внешнего интерфейса, но он будет делать запросы где-то еще для сбора необходимых данных - скорее всего, сервис написан на одном из вышеупомянутых языков. ,
Лично я чувствую, что вся терминология "back-end" и "front-end" немного ... устарела, возможно. Я бы предпочел, чтобы вещи были просто переданы на стороне клиента и на стороне сервера; тогда нет никакой реальной двусмысленности. *
Совсем недавно я увидел спецификацию клиента, которая требовала, чтобы серверная система писала в node.js и связанных с ней инструментах, но хотела, чтобы клиентская сборка использовала среду PHP (Laravel). Это сопряжено со многими сопутствующими расходами, и, на мой взгляд, не является элегантным решением и может вызвать немало проблем в будущем.
Говоря лично, такого рода конфигурации кажутся такими, будто кто-то излишне включил PHP в другой стек - это означает, что требуется больше ресурсов, чем фактически требуется, персоналу технического обслуживания требуется более широкий спектр технологий и больше точек сбоя.
Кроме того, я также думаю, что есть очень немного сценариев, которые гарантируют такой вид промежуточного стека; большинство фоновых языков / фреймворков вполне способны генерировать разметку, необходимую для внешнего интерфейса. Хотя я стою исправляться там.
* Хотя, чтобы перевести ваш вопрос с ног на голову ... А как насчет серверных систем, созданных с использованием Javascript? (node.js;))
Редактировать:
Прочитав комментарий @itsbruce, я решил уточнить, что я имею в виду под неоднозначностью моей терминологии «front-end» / «back-end».
Традиционно эта терминология была бы хорошей, архитектурно-веб-приложения были намного проще - и, смею сказать, намного тупее. На мой взгляд, гораздо понятнее говорить «на стороне сервера» и «на стороне клиента», и это становится яснее по мере того, как становится распространенной текущая тенденция предоставления большей части обработки и логики клиенту.
Становится приемлемым делать достаточное количество обработки данных на стороне клиента (просто взгляните на некоторые из фреймворков javascript, которые в настоящее время находятся в тренде), но действительно ли это фронт-энд? Пользователь не видит его, он видит результаты этого - и по традиционным критериям, которые обычно рассматриваются как «back-end»; но это происходит в браузере сейчас ..
Точно так же, и невероятно актуально для этого вопроса, действительно ли создание разметки в PHP - это задача переднего плана? Я сомневаюсь в этом, быстрый просмотр рабочих мест показывает, что немногие внешние разработчики ожидают опыта или знаний PHP; тем не менее, интуиция предполагает, что разметка для интерфейса по своей сути является интерфейсной.
Сам факт того, что этот вопрос существует, служит примером того, как « передний конец » и « задний план » по своей сути неоднозначны и будут оставаться таковыми.
Обращаясь к задачам как «серверная» или «клиентская», что неоднозначность теряется, вы знаете, где выполняется код и какие языки будут использоваться. Если бы вы сказали « front-end » в примере, который предоставил OP, я сомневаюсь, что многие скажут: « О, так что, PHP на сервере, верно? ».
источник