Внешний интерфейс написан на языках, используемых для внутреннего интерфейса! [закрыто]

10

Из своего опыта в веб-разработке я знаю, что такие языки, как PHP, Java, Python и т. Д., Используются для бэкэнд-разработки (программное обеспечение, работающее на сервере), а для интерфейсных языков используются JS / HTML / CSS.

Но я вижу, что многие компании говорят, что они используют, например, PHP для фронт-энда и Python для бэк-энда.

Означает ли это, что PHP является внешним интерфейсом для вызова других сервисов, написанных на других языках через REST, RPC ..etc?

Shox
источник
3
этот пост довольно трудно читать (стена текста). Не могли бы вы изменить его в лучшую форму?
Комнат

Ответы:

36

Вы перепутали термины «интерфейс» и «фон» с «серверной» и «клиентской». «Back-end» обычно относится к системам, которые непосредственно не предоставляются пользователю (серверы баз данных, промежуточное программное обеспечение и т. Д.), В то время как «front-end» обычно относится к приложению (в случае с Web это обычно означает статический и динамические веб-страницы), к которым непосредственно обращается клиент.

В веб-приложении клиент (браузер пользователя) получает доступ к веб-страницам, которые хранятся или динамически генерируются «на стороне сервера» с помощью «интерфейсных» технологий. Эти внешние компоненты могут, в свою очередь, извлекать данные или другую информацию из «внутренних» компонентов. Таким образом, веб-приложение, написанное на PHP, будет "front-end", но "server-side". Однако, если веб-страницы содержат какой-либо javascript, который должен выполняться браузером пользователя, этот код javascript будет выполняться «на стороне клиента».

Надеюсь, я устранил некоторую путаницу, но теперь я рискну создать еще немного.

Во-первых, у нас есть AJAX , который является кодом (обычно JavaScript), выполняемым на клиенте (т.е. на стороне клиента), для создания веб-страниц, которые вы видите, извлекая информацию из интернет-сервисов, которые сами не генерируют веб-страницы. Службы генерируют свою информацию на стороне сервера на внешнем интерфейсе (так как они общедоступны, и вы можете указать свой браузер прямо на них, если знаете URL).

Во-вторых, JavaScript, конечно, не ограничивается использованием на стороне клиента. Он становится все более популярным в качестве языка «на стороне сервера» (см. Node.js для одного примера). Как таковое, его наиболее распространенное использование предназначено только для тех интернет-сервисов, которые я описал в предыдущем абзаце.

До Web 2.0 все было намного проще . В то время в контексте веб-приложений во внешнем интерфейсе создавались веб-страницы, а JavaScript запускался только на стороне клиента и создавал незначительные косметические элементы для веб-страниц, такие как яркие изображения, когда вы наводили на них мышь. Однако эта простота заставляла людей лениться в своих определениях. Сейчас ситуация более сложная, поэтому важно быть точным в отношении этих терминов.

(О, и если вам нужно использовать PHP, пожалуйста, оставьте его на переднем крае. Это решительно не очень хорошая серверная технология. И если вы когда-нибудь найдете кого-нибудь создающего браузер, который выполняет PHP на стороне клиента, снимайте их.)

itsbruce
источник
Учитывая ваше последнее предложение, вы можете наслаждаться code.google.com/p/php-to-js :-P
Андреа
если каждый язык может быть использован во внешнем интерфейсе, и каждый язык может быть использован во внутреннем интерфейсе, не является ли различие бесполезным в том виде, в котором оно задано? на него можно ответить только в контексте приложения.
Клавдиу Крянгэ
7

Я думаю, что ваш вопрос может быть довольно специфичным для 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 на сервере, верно? ».

Фергус в Лондоне
источник
3
Я не проголосовал за вас, но ваш ответ почти так же сложно прочитать, как и вопрос, и он действительно не решает путаницу в терминах (если что-нибудь, это делает его хуже). Что еще более важно, там просто нет никакой двусмысленности между «фронтального v фоновым.» И « на стороне клиента v на стороне сервера.»; они описывают разные и разные отношения. Вы могли бы также сказать: «Я бы предпочел, чтобы мы перестали понимать цвет и форму; неоднозначно, что вещи могут быть зелеными или синими, круглыми или квадратными, а некоторые - зелеными и квадратными».
Брюс
До, у меня не было достаточно времени, чтобы вычитать корректуры, так как мне пришлось вернуться к работе. Приветствия для комментария, хотя, это дало мне возможность редактировать. Я все же придерживаюсь своих мыслей относительно терминологии, но немного углублюсь в нее. Ta.
Фергус в Лондоне
не обязательно - я считаю, что язык веб-сервера является частью клиента (учитывая, как часто веб-серверы в настоящее время взламываются, его следует считать скомпрометированным со дня 1), поэтому необходимо различать языки на стороне сервера, которые являются частью презентации уровень от серверных языков, которые предоставляют сервисы уровня приложений. Таким образом, PHP можно считать «интерфейсным, серверным» языком.
gbjbaanb