Здесь важно понимать, что вам нужно понимать термины backend и frontend .
По определению веб-сайт может быть загружен с сервера по протоколу HTTP и сделан из HTML и, возможно, CSS и / или Javscript.
Теперь по определению каждый код, который выполняется на этом сервере, является backend . Весь код, который запускается в браузере пользователя, считается внешним . Если веб-сайт содержит только HTML и CSS, сгенерированные сервером, не имеет смысла делать это разделение. Это означает, что мы говорим только о внешнем и внутреннем интерфейсах, если у нас есть оба.
Это также означает, что код внешнего интерфейса, который запускается в браузере, должен быть доставлен бэкэндом. Внешний интерфейс без бэкэнда не может существовать .
Давайте рассмотрим небольшой пример. Если пользователь вводит example.com в браузере, браузер отправит запрос HTTP GET на example.com. Сервер (и, следовательно, серверная часть) ответит HTML-файлом. Этот файл теперь может включать файл JavaScript с <script src="/code.js">. Теперь браузер делает еще один HTTP GET - example.com/code.js, и сервер (и, следовательно, серверная часть) возвращает этот файл. В этом файле может быть некоторый код внешнего интерфейса, который выполняется в браузере.
Теперь, возможно, этот файл хочет загрузить некоторые данные из бэкэнда. Так что он делает fetch('/api/data) . The browser does another HTTP GET to example.com / api / data`, и бэкэнд должен ответить. Теперь, пока бэкэнд был относительно тупой до этого момента и только доставлял файлы, он теперь мог фактически выполнять некоторую логику. Может быть, загрузить данные из базы данных или тому подобное. Затем он отправляет данные во внешний интерфейс, который затем может использовать эти данные для выполнения каких-либо действий.
Это означает, что в производственном процессе ваш бэкэнд должен предоставить код внешнего интерфейса. В этом примере исходный файл HTML и файл code.js.
То, что вы хотите, по определению невозможно. Интерфейс работает в браузере и поэтому не может доставить код на локальный хост. Если бы он мог, он бы стал бэкэндом.
В настоящее время общепринято, что реальный бэкэнд поставляет интерфейсный код на производстве, но он не распространен для разработки. Очень распространено иметь отдельный минималистичный сервер, который используется только для разработки. python -m SimpleHTTPServer - это такой инструмент, и он будет делать эту работу.
Иногда это также делается в производстве. Тогда ваш бэкэнд, например, на example2.com, а ваш фронтенд - на example.com. Но это существенно означает, что существует второй бэкэнд только для доставки внешнего интерфейса. Обычно для производства это полноценный веб-сервер, такой как nginx, apache или IIS (вам потребуется CORS, см. Ниже). В отличие от них такие инструменты, как python -m SimpleHTTPServer, не должны использоваться для производства.
Теперь это означает, что в основном вы можете просто использовать любой бэкэнд для доставки своего интерфейса для разработки. Позже вы передадите свой код своему бэкэнд-разработчику, а затем он развернет его вместе со своим бэкэндом. Однако есть один открытый вопрос:
Как будут взаимодействовать ваш интерфейс и сервер?
В производственном процессе ваш веб-интерфейс может всего fetch что-то, и он будет работать, если ваш бэкэнд предоставит ваш веб-интерфейс. Но для разработки (и так для тестирования) вы, вероятно, уже хотите использовать бэкэнд, не запуская его на своем компьютере. Для этого в основном есть два способа.
Сначала ваш бэкэнд разработки мог бы передавать неизвестные запросы бэкенду.Это означает, что если ваш реальный бэкэнд работает на example.com и вы запускаете сервер разработки на localhost, то этот сервер будет проксировать все запросы, которые не являются существующими файлами, к example.com.Поэтому, если вы запрашиваете localhost/code.js и файл code.js существует, ваш сервер ответит этим файлом.Если вы запрашиваете localhost/data и у вас нет файла с именем data, ваш сервер должен выполнить запрос к example.com/data и вернуть этот ответ.Это очень распространено.В зависимости от инструментов, библиотек и инфраструктуры, которые вы используете для разработки веб-интерфейса, у них есть встроенный сервер разработки с этой возможностью.Например, если вы разрабатываете с ember.js, вы можете сделать ember server --proxy=http://example.com.И он будет запускать сервер на localhost:4200 именно с таким поведением.Другие инструменты, такие как create-react-app, позволяют то же самое.
Во-вторых, вы можете использовать CORS.Это должно быть реализовано бэкэндом и позволяет веб-интерфейсу с другого сервера получить доступ к бэкэнду.Это также необходимо, если вы запускаете свой веб-интерфейс и серверную часть с двух разных серверов, как я описал ранее.Если бэкэнд правильно внедрил CORS, вы можете просто fetch('example.com/data) получить ваши данные, и этот Javascript не должен доставляться example.com, и он будет просто работать.Однако CORS усложняет безопасность.