Когда я впервые начал изучать код, я натолкнулся на термины интерфейс и бэкэнд. Хотя я уже создал калькулятор и погодное приложение, эти термины все еще были мне непонятны. Путем некоторого исследования я нашел эту статью и эту, и обе мне понравились вначале.
Фронтенд и бэкэнд
Интерфейс, часто называемый «клиентской», относится к той части веб-сайта, которую вы можете видеть и с которой можно взаимодействовать через веб-браузер. Во время навигации в Интернете все, что вы видите, включая шрифты, цвета и раскрывающиеся меню, представляет собой комбинацию HTML, CSS и JavaScript, управляемую браузером вашего компьютера.
Бэкэнд, часто называемый «серверной», обычно состоит из сервера, приложения и базы данных, а также обычно обрабатывает бизнес-логику и хранилище данных для веб-сайта.
Чтобы забронировать отель онлайн, вы открываете веб-сайт и взаимодействуете с внешним интерфейсом. Приложение обрабатывает и хранит вашу информацию в базе данных, созданной на сервере, и эта информация остается там, так что при следующем входе в приложение она все еще будет в вашей учетной записи.
Это было ясно. Тем не мение …
Javascript больше не ограничивается концепцией браузера.
Язык JavaScript (или JS), созданный в 1995 году, изначально предназначался для добавления небольших эффектов на веб-страницу. Исторически он использовался в основном для создания сценариев на стороне клиента, в которых сценарии, написанные на JS, встраиваются в HTML веб-страницы для запуска на стороне клиента механизмом JS в веб-браузере пользователя. Это означает, что веб-браузер посетителя запускает код JS и выполняет действия на веб-странице.
Node.js, представленный в 2009 году, представляет собой платформу с открытым исходным кодом, которая позволяет JS запускать в серверной части, вдали от браузера, для создания динамического содержимого веб-страницы до того, как страница будет отправлена в веб-браузер пользователя. . Это означает, что вы можете разрабатывать серверные веб-приложения.
Следовательно, Node стал одним из основополагающих элементов парадигмы «JavaScript повсюду», позволяя унифицировать разработку веб-приложений вокруг единого языка программирования, а не полагаться на другой язык для написания сценариев на стороне сервера.
Но если JavaScript может работать где угодно, использовал ли я его во фронтенде или бэкэнде? Я обратился за помощью к каналам IRC (Internet Relay Chat) и спросил: «Если у меня есть программа, которая запрашивает у пользователя два числа, затем вычисляет сумму и отображает результат, мой код считается внешним или внутренним?»
JavaScript практически везде одинаков. Пока вы не используете команды браузера или узла, ваш JS может работать в любом месте.
В Node есть команды, которых нет в браузере, и наоборот, поэтому, если вы не используете ни одну из этих команд, ваш код можно запускать где угодно. Например, вы не можете прочитать файл со своего компьютера с помощью браузера, но вы можете с помощью Node, используя fileOpen, fileRead, fileWrite. Этого нет в браузере. Точно так же window.location и document.body не существуют в node.
Если он работает в браузере, это интерфейс. Если он работает на вашем сервере, это бэкэнд. Один и тот же код может быть выполнен на обоих
Это вызвало еще больше вопросов. Как заставить JavaScript работать в браузере или на сервере, если он может выполняться на обоих? Что именно означает «запускать или может выполняться на обоих»? Каковы причины выбрать запуск JS-кода на любом из них?
Сначала определите свои требования и предпочтения к проекту.
Что касается моего примера с суммой IRC, я узнал, что вы можете сгенерировать сумму на стороне клиента или отправить ввод на сервер, чтобы он обработал и вернул сумму. Одна из причин сделать последнее - защитить способ получения этой суммы, учитывая, что клиентский JavaScript может быть прочитан конечным пользователем. Другой причиной может быть необходимость отслеживания всех сумм, генерируемых пользовательским вводом, что предполагает сохранение данных в базе данных.
Однако вы должны спросить себя, нужно ли делать это серверной частью. Нужно ли защищать производящую сумму, хранить или что-то еще? Вы хотите, чтобы сервер работал на неопределенный срок, чтобы приложение-калькулятор работало? Если вы хотите, чтобы Google нашел этот веб-сайт, вам, вероятно, нужно как-то обслуживать эту HTML-страницу. Если вы создаете форум, где пользователи могут создавать новые темы после заполнения формы, вам нужно где-то, чтобы они могли сохранить эту тему, чтобы ее могли видеть другие люди. И вы не можете добиться этого с помощью только клиентского JavaScript. Другой пример - сам пользовательский ввод. Вы можете выполнить дезинфекцию и логическую проверку во внешнем интерфейсе, но вы также захотите выполнить ту же или аналогичную рутинную сторону сервера при получении входных данных. Все, что работает на стороне клиента, можно увидеть, прочитать и разобрать, поэтому определенно работайте в предположении, что что-либо в браузере открыто для кого-либо, и в конечном итоге конечному пользователю нельзя доверять.
Ваш код запускается там, где вы его запускаете
Все дело в том, где выполняется код. Сценарий JS может работать как на внешнем, так и на внутреннем интерфейсе.
- Если вы сохраните его как server.js, а затем запустите «node server.js» на своем сервере, он будет работать на сервере (бэкэнд).
- Если вы включаете его в HTML-страницу, которую отправляете в браузер, он выполняется в клиенте (веб-интерфейсе).
Наконец, мне стало ясно, что интерфейс и бэкэнд относятся к тому, где вы что-то выполняете, а не к тому, что выполняете. Что-то «не является» серверной частью, это «используется» на стороне сервера и «предназначено» для работы в качестве сервера. Точно так же он может быть разработан и должен выполняться в браузере.
Не существует таких понятий, как "интерфейс" или "серверная часть".
Фронтенд и бэкэнд относятся к разным частям вашего приложения и к системе, в которой они работают. Frontend означает «все, что работает в системе пользователя», тогда как backend означает «все, что работает на удаленном сервере». В некоторых проектах бэкэнд выполняет большую часть работы, а в других - фронтенд, но нет выбора между «иметь бэкэнд» и «иметь фронтенд», у вас всегда есть и то, и другое. Вопрос только в том, какая логика и где существует. Например, части HTML и CSS выполняются во внешнем интерфейсе, а ваш код проверки может выполняться во внешнем и внутреннем интерфейсе. Итак, если часть вашего приложения запускается в браузере, это интерфейс, а если он выполняется на вашем сервере, это серверная часть.
Если я развертываю свой калькулятор на сервере и открываю его через HTTP, тогда код по-прежнему остается только интерфейсом, но у меня есть бэкэнд, сервер, который я использую для его отправки пользователю. У моего бэкэнда была только одна задача - отправлять файлы пользователям, когда они их запрашивали. В случае моего погодного приложения (которое хранит данные в БД) бэкэнд будет отвечать за логику, а интерфейс только отображает / стилизует данные (с использованием HTML / CSS). Это было бы приложение, в котором логика находится в бэкэнде.
По возможности всегда старайтесь, чтобы как можно больше логики работало в бэкэнд-системе, а не во внешнем интерфейсе.
Причины, по которым это предпочтительнее:
- это предсказуемая среда. Вы точно знаете, сколько вычислительной мощности у вас есть. Например, у сервера нет разряженной батареи, у него нет плохого процессора в бюджетном телефоне, он не разделяет свою среду с несколькими другими приложениями, которые все пытаются делать что-то одновременно.
- это контролируемая среда. Пользователь не может получить доступ ни к чему, кроме того, что вы явно отправляете им или принимаете от них.
- это среда, которую вы можете контролировать. Если ошибка возникает на стороне сервера, вы можете надежно зарегистрировать эту ошибку и что-то с ней сделать, тогда как если ошибка возникает на стороне клиента, нет никакой гарантии, что вы когда-либо ее увидите или сможете исследовать.
Одним из ограничений бэкэнд-приложения является то, что для значимого изменения страницы необходимо перейти на другую страницу или перезагрузить страницу.
Это нецелесообразно, например, с приложением чата, потому что страница должна изменяться по мере поступления сообщений. Таким образом, причина, по которой приложение чата не может быть в основном серверным приложением, заключается в том, что модель «пользователь взаимодействует с чем-то а затем загружается новая страница »не работает. Сообщения все равно приходят, даже если пользователь ничего не делает.
Однако для моего приложения погоды страница должна изменяться только в том случае, если пользователь взаимодействует с ней, и это не зависит от времени. Пользователь может выбрать другую единицу измерения температуры или другой город, и страница перезагрузится. Я мог бы ускорить процесс с помощью клиентского JS, но он может работать только с бэкэнд-логикой.
Рассматривайте интерфейс и серверную часть как два совершенно разных приложения, написанных на одном языке. Между ними нет никаких внутренних отношений или связи.
Интерфейс JS не знает, что на сервере работает Node, точно так же, как сервер не знает, что браузер запускает JS. Между ними нет прямой связи, все идет по HTTP. Если вы хотите общаться между клиентом и сервером, вы используете HTTP. Клиент никогда не видит код сервера, он не может вызывать код сервера, и сервер также не может напрямую вызывать код клиента.
HTTP (протокол передачи гипертекста) - это базовый протокол, используемый во всемирной паутине. Он определяет, как сообщения форматируются и передаются, и какие действия веб-серверы (компьютер, на котором размещен веб-сайт) и браузеры (клиент) должны выполнять в ответ на различные команды. Например, когда вы вводите URL-адрес в своем браузере, браузер превращает URL-адрес в сообщение HTTP-запроса и отправляет его на сервер. Сервер интерпретирует сообщение запроса и возвращает вам соответствующее ответное сообщение, которое является либо запрошенным вами ресурсом, либо сообщением об ошибке. Затем браузер интерпретирует ответное сообщение и отображает содержимое.
Здесь мы надеемся, что это поможет пролить свет на термины внешнего и внутреннего интерфейса, а также на то, где работает JavaScript. 😉
