Как связать фронтенд и бэкенд

Connecting Front-End and Back-End Applications

Create a back-end and front-end application in two separate repositories and allow them to talk to each other — even on production.

Introduction

A common application architecture is to host a front-end (user-interfacing) application and back-end (data-serving) application separately from each other. The goal is separation of concerns and therefore an increased ease in continuous integration between separate teams. There are some local development and production environment issues that must be addressed for this to happen smoothly.

You might have done this before — an Express server and create-react-app application in one repository. We won’t be doing that because it’s against the architecture we’re looking for.

We’re also not going to deal with proxies today, and we certainly won’t be using any Chrome extensions for CORS (if it’s on now, turn it off).

Step 1: Create a Back-End (10 minutes)

To start, you will create a basic Express application. Your application should:

1. Utilize app.locals to serve A JSON object of arbitrary data (perhaps an array of objects)
2. Include 1 GET: should return all the resources
3. Include gitignore file

Test your endpoint with Postman

• What is gitignore and why would we want this in such a basic application?

Step 2: Create a Front-End (10 minutes)

Now that our backend endpoint is working, we are going to build a small frontend application in React.

If you have not done so recently, update your create-react-app npm package using the command: npm i -g create-react-app . Create a new create-react-app React front-end application — name it whatever you’d like.

Your frontend should:

1. Be initialized with create-react-app. Name it whatever you would like
2. Fetch all of the resources from your backend application. Note:
   — State should hold the data from the fetch call
   — There should be some default state of the fetched data (the default state should be rendered on the page)
   — Once the fetch is complete, the state should be updated and rendered on the page.

• What port does create-react-app define for us automatically?
• Can you run your BE and FE on the same port?
• Why isn’t your fetch working?

Step 3: Research CORS

You’ve heard of it before — Cross-Origin Resource Sharing. What even is an origin? And why do we want to share resources?

On your own, look through this MDN page about what an origin is.

• What is an origin?
• What is Cross Origin Resource Sharing?
• Why can’t our frontend and backend applications talk to each other?

Read through this MDN page about CORS — specifically:

1. “Introduction”
2. “What requests use CORS?”
3. “Functional Overview”,
4. Simple requests portion of “Examples of access control scenarios”
5. “The HTTP response headers”

Now in each group at your tables on a piece of chart paper:

• Diagram the “conversation” between the back-end and front-end that caused the CORS issue in the first place
• What is the protocol? Port? Host? Draw it out.
• How do you fix the CORS issues? What needs to change? Diagram a new conversation where the frontend is able to request a resource from the backend, which has a different origin.

Step 4: Implement CORS

Let’s fix the CORS issue.

For this, we can install a node package that allows us to enable CORS with various options.

Using the docs found here, let’s install an extension designed to address enable CORS with Express apps:

1. Install this package as a dependency by using —save
2. Using the documentation as a guide, require the CORS package and utilize the simple usage to enable all CORS requests

Now that the CORS situation is fixed, and even though it works, note that you SHOULD NOT use the default CORS settings to allow all origins! In your back-end application, you need to change the default settings in the server to allow only specific origins that apply to your application (for development and production).

You can read up on how to configure the CORS middleware in the documentation here.

Step 5: Environmental Variables

In the fetch call of our FE application, we hardcoded the URL we are querying. But localhost won’t work when we get to our production application. How can we make the URL dynamic?

Go to create-react-app docs for the section on environment variables.

Take a few minutes to read through that section.

From here, let’s update the following in our application:

1. Add this code block (shown above) within the return of the render in your frontend app
2. In the root of your react app, create a dot-prefixed env file called .env.development (This will be used to store variables that are utilized when we are development )
3. Declare a custom React environment variable to store our backed URL for the fetch call. This variable should be save in the .env.development file you created. Now, replace the hard-coded URL in your App fetch call with the environment variable, and see if it works!

Now, in our FE application, let’s update the hardcoded URL in our fetch to use the new environment variable.

*NOTE:* You will have to kill your FE server and restart it. This is because, as you read in the documentation, environment variables are embedded into the code during the BUILD of the app, not during the run time. So now that we’ve added a new variable for our development environment, we must start a new build. In the development environment, a new build is run every time we run $ npm start , so let’s do that now. Make sure your BE server is already running.

Check your React app in the browser. Hopefully we will still be successfully making our fetch call using the environment variable!

• How do you add a custom environment variable to a create-react-app?
• Are there any caveats to know about them?
• What is NODE_ENV and what should we know about it?

Step 6: Deployment

Backend

So we’re set up locally, and everything seems to be working correctly! So far we’ve taken care of our development environment. What about production and deploying our application? Let’s deploy the back-end application to Heroku first. Go ahead! (Reference the lesson we’ve already had about deploying a back-end app to Heroku.)

Test it with Postman to make sure the API is working.

Frontend

Next we need to deploy the front-end. This is a little different from deploying the back-end. To deploy something to Heroku, we need a server. Our React app has a development server (this is what is used when you say npm start in your terminal), but we can’t use it in production.

We have to use what is called a buildpack. It essentially wraps our React app in a server (like an Express server) for us, which Heroku can use to serve our front-end application.This is a buildpack for create-react-app that is suggested.

To set it up and create a Heroku application, run the command: heroku create your-app-name —buildpack mars/create-react-app Push up your FE app and watch it build. Does it run? Does the fetch call go through successfully? What happened?

You will probably see your default state information being rendered, but nothing from your fetch call. Why?

Read this Heroku doc page for what you might need to add.

In the settings, under ‘CONFIG VARIABLES’, add your REACT_APP_BACKEND_URL variable with a value of your deployed BE’s URL.

Did it fix the issue?

Probably not! According to the docs, when are environment variables embedded? What will you have to do to get the newly created production environment variable into your codebase?

Summarize What We Have Done

Take a few minutes now to write down, in your own words, exactly the steps you had to take to get your BE and FE to talk to one another. What caused bugs? How did you address those bugs?

Write down what remaining questions you have. Use those question as starting places for digging into the documentation.

Как соединить front-end и back-end?

Всем привет, меня зовут Григорий и вот уже полгода я никак не могу понять как правильно готовить Web! Очень нужна помощь знающих людей.

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

1. Есть фронт-энд, который выполняется на стороне клиента
2. Есть бэк-энд, который выполняется на стороне сервера

Для того чтобы готовить фронт-энд есть огромная куча инструментов: Grunt и RequireJS, Gulp и Browserify, Webpack.
Давайте пока не будем трогать MVC фреймворки типа Backbone, ReactJS, AngularJS, я хочу разобраться с основами.

Предположим в данный момент я использую 2 инструмента для фронт-энда: Gulp и Webpack.
Мне нужно сверстать 2 страницы, полностью идентичные, но на которых в меню были бы выделены 2 разных пункта, в зависимости от того, какая страница открыта. И так же присутствует динамическая информация — кнопка, если пользователь залогинен то показывается надпись «профиль», если нет то «вход».

Во первых, я хочу оптимизировать процесс верстки HTML страниц, то есть я не хочу верстать одинаковые элементы по нескольку раз, и было бы не плохо такие повторяющиеся элементы вынести в модули. Но казалось бы такую элементарную операцию сделать крайне трудно. Есть огромное количество JS шаблонизаторов типа Handlebars, Mustache, Underscore. но все они работают через JavaScript, а я хочу собрать нормальную HTML страницу, которая будет готова сразу без необходимости грузить скрипты. Еле-еле нашел такой инструмент для Gulp’a как «gulp-file-include». Но это явно какие-то костыли, и писать серьезное web-приложение на его основе стремно, должен быть какой-то другой путь, вопрос какой?

Во вторых, предположим я сверстал такие страницы, все ок, но как мне проверить залогинен пользователь или нет? На помощь к нам приходит бэк-энд. Каким образом нам получить данные? Мы можем собирать страницы на сервере и возвращать уже готовые либо с кнопкой «профиль» или с кнопкой «вход». На мой взгляд это не совсем верный путь, потому что, во первых, зачем нам Gulp и Webpack если сборка будет происходить на сервере, во вторых, сервер по-хорошему не должен заниматься такими задачами как сборка страниц для пользователя. На мой взгляд сервер должен возвращать мою сверстанную страницу из прошлого пункта и что-то типа JSON’а с данными, которые я при рендеринге смогу вставить в нужные места, например проверю залогин ли пользователь и покажу правильную кнопку. Но как это сделать я тоже не понимаю, этого можно добиться только если после загрузки страницы в скрипте посылать AJAX запрос на необходимые данные и потом уже изменять страницу, но это тоже явно не верный путь, потому что нам требуется дополнительный запрос к серверу, что плохо, и в то время пока мы будем ждать ответа нам не известно что показывать на странице.
На мой взгляд бэк-энд вообще не должен заниматься компановкой HTML, он должен работать с данными в базе, роутингом, и выдавать на клиент данные в виде JSON.
Так каким образом мне получить страницу с правильными данными?

Моя голова скоро лопнет от отсутствия решения этих вопросов, люди добрые, срочно нужна помощь.

Взаимодействие backend и frontend

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

Мы уже рассказывали о том, что frontend- и backend-разработкой часто занимаются разные специалисты. Тем не менее каждому из них желательно знать принципы, по которым работают их коллеги. Здесь нельзя не упомянуть и про Full-stack developer’а (фулстек-разработчика), который знает весь стек технологий, используемых в проекте как в части backend, так и в части frontend. Как говорится, эксперт и мастер на все руки. Впрочем, никто не мешает и вам стать таким)). Но не будем отвлекаться и перейдём к основной теме нашей статьи — взаимодействию между front-end и back-end.

Как взаимодействуют backend и frontend?

Если говорить простым языком, то взаимодействие между backend и frontend происходит по кругу: 1) фронтенд отправляет пользовательскую информацию в бэкенд; 2) там информация обрабатывается; 3) информация возвращается обратно, принимая понятную для пользователя форму.

Варианты взаимодействия backend и frontend:

• HTTP-запрос. Напрямую отправляется на сервер, сервер ищет данные, встраивает их в шаблон, а потом возвращает в виде HTML-страницы. Между получением запроса и ответом на него сервер обычно ищет по сформированному запросу информацию в БД. С помощью HTML определяется, что будет показано, а CSS — как всё будет выглядеть. JS необходим для особых взаимодействий; • использование инструментария AJAX (Asynchronous JavaScript and XML). Запрос отправляется посредством JavaScript, загруженным в браузер. Ответ приходит в формате JSON или XML; • одностраничные приложения. Они загружают данные без обновления веб-страницы. Это также осуществляется посредством AJAX либо с помощью фреймворков Ember и Angular; • Ember либо библиотека React. Они помогают использовать приложение и в клиенте, и на сервере. Backend и frontend взаимодействуют с помощью AJAX и HTML-кода, обрабатываемого на сервере.

Как подружить бэкенд- и фронтенд-разработчиков в вашей команде

На каком языке должны разговаривать бэкенд- и фронтенд-разработчики в команде? С чего начать разработку, когда дизайн вашего приложения готов? Кто должен проектировать API и модель данных: бэкенд или фронтенд?

Данная статья — это презентация идеи и прототипа решения для проектирования API — API Projector с элементами дискуссии — из серии, «а надо ли?», «очередной велосипед?» и т.д.

Дизайнер нарисовал макеты будущего продукта и сделал прототип. Заказчик сказал — погнали! Что происходит дальше? Самое лучшее — спросить у тех, кто профессионально занимается разработкой IT-систем.

Для первого «кастдева» я поехал к друзьям из студии Гарпикс.

В ходе обсуждения определили:

Боль 1: эффективно передать требования к API от фронтенд на бекенд.

Как фронтенд разработчикам сказать бекенд разработчикам, какие API и данные им нужны, чтобы реализовать дизайн интерфейса?

Боль 2: совместное проектирование API фронтенд и бекенд разработчиками с проверкой архитектором системы.

Фронтенд и бекенд разработчики могут ошибаться в наименованиях моделей, типах полей и REST методологии в целом.

Боль 3: узнавать об изменениях API на работающей системе.

Бывают проекты, где у клиента уже есть API, и задача написать только мобильный или WEB фронтенд. Клиент может менять API в любое время без уведомлений, как результат — приложение функционирует неправильно и фронтенд разработчики тратят много времени на поиски причины багов.

Боль 4: соединить существующий API с новым дизайном.

Бывают проекты, когда часть API уже написана и требуется обновить дизайн фронтенда или добавить мобильное приложение. Нужно провести аудит того, что уже есть, понять, что еще нужно добавить или отрефакторить.

Боль 5: управление изменениями в требованиях к API.

API уже реализовано, но пришли новые требования. Как понять что нужно добавить в API? И как потом это передать в виде задач на бекенд?

Как решаются эти проблемы сейчас?

Полностью — никак, лишь частично��

Фронтенд и бекенд разработчики садятся рядом и накидывают код API в блокноте, wiki или JIRA тикете в тексте или JSON → потом поддерживать это нереально.

Фронтенд разработчики пишут Swagger и передают его на бэкэнд → очень трудоемко и по мере того как разрастается API поддерживать его все сложнее.

Бекенд разработчики сами накидывают API как его видят → часть API и данных пропускается.

После обсуждений мы попробовали набросать интерфейс будущего решения. Логичнее всего было взять уже что-то знакомое и распространенное — Swagger и улучшить это.

В результате получилось решение под названием — API Projector.

Фронтенд разработчики загружают экраны дизайна из Figma

Далее для каждого экрана разработчики могут выделить области, которым требуется вызов API. Они понимают, какие данные им нужно отобразить в данной части интерфейса: из какой модели и какие поля.

И, собственно, далее можно либо выбрать уже готовые API из библиотеки или создать новые API в «swagger подобном» редакторе.

Основная киллер-фича �� нашего решения: связь дизайна и API. Мы всегда знаем, какие API и модели в каких частях интерфейса используются.

На выходе мы получаем всеми знакомый Swagger, на основе которого уже можем генерировать наброски кода на бекенд.

Какие еще фичи можно получить в итоге, если всё проектирование и будущая поддержка требований к API ведется в API Projector:

• Ревью API перед реализацией архитектором системы.
• Совместная работа над проектированием API множеством разработчиков.
• Версионность изменений: кто и когда что-то менял.
• Валидация API: забираем swagger с работающей системы и сравниваем со спецификацией. Бам ��: такого-то поля не хватает, оно не такого типа, и т.д.

Можно вас «покастдевить»? Что скажете? «Велосипед» или реально решающий боль продукт?

Мы быстро накидали лендинг и Figma-прототип. Будем очень признательны за Вашу обратную связь. Спасибо ��