Является ли термин «интерфейс» синонимом «клиентский»? Если так, то всегда ли это так?

Как относительно новый (самоучки) веб - разработчик, я слышал термины переднего плана , на стороне клиента , фонами , и на стороне сервера довольно часто. Для меня внешний и внутренний интерфейсы всегда были синонимами клиентской и серверной сторон соответственно.

Однако, когда я начал работать с инфраструктурами MVC, такими как CodeIgniter, я натолкнулся на несколько примеров внешнего интерфейса, ссылающегося в основном на все, что видит конечный пользователь (включая код на стороне сервера), в то время как внутренний компонент ссылался на что-либо конечный пользователь не видит (включая CMS). Клиентская и серверная части, на мой взгляд, гораздо более конкретны в своих значениях; у них очень четкая линия, разделяющая их. Front-end и back-end, с другой стороны, нет.

В разговоре, который я помню с другим веб-разработчиком, он упомянул CodeIgniter (полностью) как интерфейс, и это заставило меня задуматься. Я не был уверен, исправить ли его и сказать, что CodeIgniter был моим бэкэндом, или мои определения двух терминов были полностью неверными.

Поиск определений front- и back-end меня немного смутил, хотя они кое-что прояснили. Я просто хотел бы знать, где проводятся черты между этими четырьмя терминами и как они соединяются вместе в контексте веб-разработки (особенно в стеке LAMP).

Я не верю, что есть формальное определение для этих терминов, и, как вы заметили, в некоторых случаях они частично совпадают.

front-endи client-sideперекрываются.
server-sideа back-endтакже перекрытия.

Если бы мне пришлось подстричься, я бы предложил эти грубые границы:

• client-sideэто приложение, которое работает на компьютере пользователя. Это может быть автономное приложение (чаще) или ссылка на интерфейс на основе веб-браузера (менее вероятно).
• front-endтакже сталкивается с конечным пользователем и обычно работает в интерфейсе на основе веб-браузера. Я не слышал о толстых клиентах, упоминаемых как front-end.
• back-endотносится к процессам и службам, которые выполняются либо на другом сервере, либо в фоновом режиме на компьютере пользователя. Чаще всего это относится к процессам, которые не находятся на компьютере конечного пользователя. Но ключ, как вы упомянули, заключается в том, что конечный пользователь не обязательно знает о запущенных процессах.
• server-sideявляется расширением, back-endно явно усиливает тот факт, что процессы выполняются где-то еще, а не на компьютерах конечных пользователей.

В качестве примера, и чтобы подчеркнуть путаницу между терминами, я буду использовать Minecraft в качестве примера.

Minecraft имеет

• client-side приложение, когда вы запускаете файлы JAR локально с вашей собственной JVM.
• front-end если вы решите запустить клиентское приложение в вашем веб-браузере
• back-end процесс, который может выполняться локально на вашем компьютере, если вы находитесь в автономном режиме
• server-side процесс, если вы решите войти на сервер, на котором размещено приложение сервера Minecraft.

Если покопаться в некоторые статистических данных Minecraft, вы увидите , что они просто обозначают clientи serverкомпонент к игре; они не обязательно заботятся о том, где эти компоненты работают.

Является ли термин «интерфейс» синонимом «клиентский»?

Вроде, но не совсем. Между терминами есть нюанс, если вы обсуждаете вещи за пределами веб-мира. Если вы строго находитесь в мире Интернета, то да, они функционально синонимичны.

Если так, то всегда ли это так?

В мире Интернета, я бы сказал, да. В других сферах я бы сказал «нет», как объяснено в грубых определениях, которые я предложил.

Серверная часть работает на сервере. Клиентская сторона работает на клиенте. Бэкэнд хрустит данными. Фронт-энд показывает это.

Посмотрите на эту веб-страницу. Извлечение всех комментариев из базы данных является серверной, серверной работой. Размещение этих данных в шаблоне - это работа на стороне сервера. Виджеты голосования AJAX и причудливое поле ввода текста находятся на стороне клиента.

Я обычно нахожу, что использование клиентской и серверной частей для описания разработки / разработчиков менее расплывчато. Та часть клиентской части, где мы выполняем жонглирование / форматирование данных, может рассматриваться как внутренний компонент. С другой стороны, есть все шаблоны, которые, как правило, происходят на заднем конце, которые, будучи «для внешнего интерфейса», приводят к тому, что люди говорят о них как о разработке на Java или C #. Это редко, но я видел это в должностных инструкциях.

Но, вообще говоря, интерфейс - это та часть, где происходит взаимодействие. Серверная часть - это та часть, где все это взаимодействие превращается во что-то полезное.

Этот вопрос несколько старше, но позвольте мне добавить мой 2c:

В своей собственной веб-разработке я использовал термин «интерфейс», означающий код - или другие ресурсы, - которые некоторое время обрабатываются в браузере. Теперь я использую термин «клиент», потому что это может сбить с толку esp. при выполнении веб-приложений. (Одностраничные приложения)

Просто потому, что на стороне бэкэнда также есть «внешний интерфейс», который означает в целом ту часть приложения, которая отвечает за вывод (в браузер). Таким образом, «внешний интерфейс» может означать две разные вещи. Термин «клиент», тем не менее, более четко описывает нечто, относящееся к реальному клиенту (в данном случае, к браузеру).

PS: Ну, может быть, я тоже должен сменить псевдоним на "client_dev";)

Сторона клиента в веб-приложении находится под контролем пользователя / клиента, а сторона сервера - под контролем разработчика. Это одна из причин, почему нужно проверять данные на сервере.

Термины « передний и задний» часто используются как синонимы для клиентской и серверной сторон, и во многих случаях это нормально. Однако есть и важные контрпримеры. Для меня интерфейс - это все, что показывает что-то пользователю.

На следующем рисунке вы можете увидеть типичные технологии / концепции и то, как они вписываются в квадранты (внешний, внутренний) / (клиентский, серверный).

Разработчики внешнего и внутреннего интерфейса

Frontend и Backend developer - две очень распространенные роли. Строка становится немного нечеткой, когда у вас есть такие вещи, как React, которые могут быть отображены на стороне сервера, и Flask, который включает в себя движок шаблонов jinja .

И хотя я бы поставил такие технологии, как база данных Web SQL и API индексированной базы данных, в «клиентский бэкэнд», роль, которая обычно знает об этом, - это роль разработчика переднего плана.

• Разработчики внешнего интерфейса должны знать о HTML, CSS, DOM и общих возможностях браузера (например, caniuse ). Как правило, они знают JQuery или React. Несмотря на то, что это бэкэнд в соответствии с моим определением, я бы ожидал, что внешние разработчики узнают о хранилище на стороне клиента
• Разработчики бэкэнда должны знать о веб-серверах, таких как nginx, gunicorn, Apache или node.js. Они должны знать хотя бы одну базу данных SQL (Postgres, MariaDB / MySQL, ...), хранилища значений ключей (Redis), разработку API (REST и GraphQL). LAMP был типичным стеком некоторое время назад. Я бы не ожидал, что бэкэнд-разработчик узнает что-нибудь о браузерах!

UI Designer vs Front End Developer

Две другие роли - это пользовательский интерфейс и разработчик внешнего интерфейса. Итак, одно отличие состоит в том, что один - дизайнер, а другой - разработчик.

Задача:

• Дизайнеры пользовательского интерфейса проектируют пользовательский опыт
• Front End Developer гарантирует, что он выглядит так, как и ожидалось (строит реальную вещь из черновика)

Инструменты:

• Дизайнеры пользовательского интерфейса в основном используют Adobe Photoshop / Illustrator / Sketch / Balsamiq / Invision.
• Разработчики Front End используют React, Vue, Angular

API: REST и GraphQL

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