Превьет!

В частях Ноль, Один и Два этой серии я с некоторым причитанием ворчал, что график разработки этого проекта таков, что мы не начнем работу над тем аспектом, который меня больше всего волнует — задней частью. конец .NET Core Web API — до тех пор, пока не закончу некоторую (менее захватывающую — по крайней мере для меня) работу над внешним интерфейсом.

Что ж, сегодня мы подошли к этой славной пропасти ожидания!

Мы будем использовать C# для создания контроллера веб-API, который позволит нам загружать изображение и позволит нашему внешнему приложению вызывать это изображение и отображать его для пользователя в нашем компоненте «Журнал выполнения».

🤓

В общем контексте платформы .NET Core сегодня мы широко обсудим две темы:

  1. Архитектура разработки ReactJS по отношению к .NET Core и ее отличия от того, что может быть знакомо разработчикам, привыкшим работать с Create-React-App в контексте сервера Node.js/ExpressJS;
  2. Работа с файлами изображений (включая их загрузку и сохранение на сервер, а также их получение с помощью вызова AJAX из нашего приложения ReactJS).

Дилли. Дилли.

Когда я думал о нашей внутренней архитектуре для этой функции, я начал бояться, что мы можем столкнуться с хваленой ошибкой CORS. Что такое ошибка CORS, спросите вы. Что ж:

Cross Origin Resource Sзаниматься.

КОРС.

Ладно, мы в порядке?

Просто шучу.

Тем не менее, CORS — это тема, которая может легко стать шаткой, так что ваши глаза быстро затуманятся. Итак, постараемся максимально лаконично проработать это понятие.

В качестве меры безопасности сервер по умолчанию скептически относится к запросам, исходящим от клиента, который существует в домене, отличном от домена сервера.

Гипотетический пример: если клиент с доменом bogoodski.com делает запрос с сервера notbogoodski.com, сервер notbogoodski.com заблокирует этот запрос в качестве меры безопасности. Однако он разрешил бы запросы от клиентов также на notbogoodski.com.

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

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

Причина, по которой ошибка CORS не возникает, связана со структурой ReactJS в среде разработки, когда она обслуживается платформой .NET MVC.

Иметь ввиду:

  • С точки зрения сервера адрес http://localhost:5000 — это домен, отличный от http://localhost:5001. Разница в номере порта — по крайней мере, на ваш сервер — значительна.
  • По умолчанию Create-React-App автоматически предоставляет сервер для размещения клиентского приложения в среде разработки.

И затем, давайте рассмотрим пример:

В нашей гипотетической ситуации проект использует Node.js и ExpressJS для обслуживания приложения в рабочей среде.

Когда разработчик создает и развертывает приложение React, сервер разработки на стороне клиента (автоматически созданный Create-React-App) исчезает, позволяя обслуживать приложение React производственным сервером Node/Express.

Однако в среде разработки на самом деле работают два сервера: один, предоставляемый Create-React-App, и сам фактический сервер Node/Express (который можно использовать, скажем, для размещения службы RESTful API).

Часто в системе, разработанной таким образом, сервер Node.js/ExpressJS размещается на одном порту на локальном хосте, а Create-React-App — на другом порту. Таким образом, RESTful API может находиться по адресу http://localhost:5000, а приложение React обслуживается по адресу http://localhost:5001. И, как вы помните, это разные домены.

Запрос из одного домена в другой домен пересекает происхождение (как в ресурсах перекрестного происхождения; «C», «O» и «R» в «CORS»). И это навлекает на себя гнев ошибки, о которой было написано все это письмо.

Вот хорошие новости:

.NET создает свою архитектуру приложения React таким образом, чтобы избежать конфликта CORS. Вкратце: даже в среде разработки наше приложение React фактически доступно по тому же номеру порта, что и наш контроллер веб-API .NET.

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

И это сработает.

Как магия.

Видеть?

Теперь давайте немного обсудим работу с файлами изображений.

При использовании в качестве статических ресурсов файлы изображений реализуются в приложениях React интуитивно понятным образом: вы можете просто импортировать изображение из папки через его путь к файлу, сохранить значение в переменной, а затем вызвать переменную с тегом img в вашем JSX. Более менее.

Но этот конкретный проект требует чего-то большего…( 🚨 ВНИМАНИЕ! 🚨)… изоморфен.

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

Таким образом, мы не можем жестко запрограммировать расположение файла изображения непосредственно в нашем клиентском приложении. Вместо этого наше приложение React отправит запрос на наш сервер .NET, и сервер отправит обратно клиенту текущую фотографию.

Что касается .NET, то эта задача не очень сложна. Мы используем Visual Studio для создания нового пустого контроллера веб-API .NET. В этом контроллере мы напишем два метода: запрос POST (который будет поддерживать загрузку нашего изображения) и запрос GET (который будет отправлять изображение нашему клиенту по запросу). Сегодня мы реализуем только запрос GET; мы будем работать над POST во время будущего обновления.

На стороне React все немного сложнее:

В моих глазах, в ваших и в глазах пользователей изображение кажется чем-то принципиально отличным от, скажем, текста на экране. Например, изображение кажется почти осязаемой вещью. По крайней мере, по сравнению с текстом.

Или, может быть, это только я.

Но на самом деле изображение, как и текст на экране, — это все-таки просто данные. И эти данные необходимо передавать в цифровом виде с сервера на клиент. Наш сервер не может взять наше изображение, упаковать все единицы и нули, из которых оно составлено, и отправить его клиенту Fed-Ex.

Вместо Fed-Ex, а точнее в коробке, наш сервер будет передавать изображение нашему клиенту в виде потока данных.

На принимающей стороне наше приложение React передает все эти данные. Которое в данном случае будет сохранено в состоянии компонента, а затем в переменной. Который затем, наконец, можно использовать в нашем JSX для отображения изображения.

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

Что в этот момент приводит нас сюда:

Пожалуйста, следуйте за мной, так как скоро должно появиться следующее обновление в этой серии!

Спасибо за чтение!

Нажмите ЗДЕСЬ, чтобы перейти к следующей части этой серии.

- БоГудСки.