#node.js #google-cloud-platform #google-cloud-storage #e-commerce
#node.js #google-облачная платформа #google-облачное хранилище #электронная коммерция
Вопрос:
У меня есть простой html-файл, который включает в себя css, подобный этому:
<link rel="stylesheet" href="./css/style.css" />
Я загрузил этот html-файл и css-файл в облачное хранилище Google и установил права доступа к общедоступным.
В моем приложении, написанном на node js, я хочу обслуживать этот HTML-файл, когда пользователь обращается к моей корневой странице.
В моем приложении у меня есть следующий код:
public async getPublicFile(opts: IGetFileOpts): Promise<File> {
const bucket = this.storage.bucket(opts.bucket);
return bucket.file(path.join(opts.type, opts.fileName));
}
@Get()
public async serveFile(@Res() response: Response) {
const file = await this.storageService.getPublicFile({
organization: organization,
fileName: 'index.html',
type: 'resources',
});
file.createReadStream().pipe(response);
}
Это работает так, как и ожидалось. Это будет сервер index.html из корзины. Однако, поскольку этот html-файл имеет относительную ссылку на css-файл, он не будет загружать css-файл, поскольку не может его найти.
Как я могу это исправить, чтобы также обслуживался файл css? В настоящее время я запускаю это на локальном компьютере, но оно будет развернуто в Google Compute Engine.
Я нашел эту ссылку для AppEngine https://cloud.google.com/appengine/docs/standard/go/serving-static-files
Здесь, в AppEngine, я могу определить некоторые обработчики следующим образом:
handlers:
- url: /favicon.ico
static_files: favicon.ico
upload: favicon.ico
- url: /static
static_dir: public
- url: /.*
secure: always
redirect_http_response_code: 301
script: auto
но, насколько я понимаю, это не будет работать на локальном компьютере.
Кроме того, как компании электронной коммерции решают эти проблемы? Например, у каждого магазина может быть своя тема, которую можно настраивать. Итак, я понимаю, что у каждого арендатора есть собственное ведро, и в ведре арендатора эта настраиваемая тема сохраняется правильно? Итак, как я предполагаю, что у вас должна быть такая же проблема, как у меня. Как справиться с этой ситуацией и как с ней справиться?
Комментарии:
1. На самом деле, если вы измените ссылку на документацию, которой вы поделились для Node.js примеры, есть целый раздел о том, как обслуживать файлы для локальной разработки, с
.cssпримеромexpress.staticего применения, вот ссылка на конкретный раздел, так что это возможно как для производства, так и для локальной разработки. Конечно, это для AppEngine, а не для Compute Engine, но это возможная альтернатива, будет ли этого достаточно?2. Если ваш каталог css доступен через http или https, вы можете добавить новый
<base>тег на стороне сервера, возвращая ответ, чтобы изменить базовый URL страницы. Таким образом, HTML-код обрабатывается app Engine, а статические ресурсы извлекаются из облачного хранилища. Подробнее оbaseтеге читайте здесь .
Ответ №1:
В данный момент вы пытаетесь получить доступ к статическому css-файлу bucket из index.html отображается на вашем URL-адресе Google App Engine. Это просто не может работать «из коробки».
Есть много вариантов решения этой проблемы:
- Служите своему index.html из того же общедоступного ведра, где находятся другие ваши статические файлы, такие как css. Это также имеет то преимущество, что оно подается как CDN, что более эффективно. (это способ, который я рекомендую, если это возможно, единственный случай, когда вы не можете этого сделать, может быть, когда вы хотите вычислить серверные HTML-элементы в index.html файл перед отправкой его обратно клиенту, но есть большие шансы, что это может быть сделано на стороне клиента)
- Создайте абсолютные пути к вашим ресурсам css в index.html «на лету» или «статически», поэтому тег ссылки может выглядеть следующим образом :
<link rel="stylesheet" href="https://bucketurl.com/css/style.css" />
- Обслуживайте весь ваш контент в вашем приложении программно с помощью специального маршрута, который будет обслуживать статический контент, считывая файлы из корзины, как вы делаете с вашим index.html . Это должно позволить вам сохранять относительные пути для других статических файлов.
Комментарии:
1. Не могли бы вы, пожалуйста, подробнее остановиться на первом пункте? Поэтому, если я хочу разместить на сервере какие-то данные из базы данных, мне нужно будет обслуживать index.html а потом это index.html следует вызвать серверную часть onPageLoad или что-то в этом роде. Правильно?
2. Да, именно так, в этом случае вам нужно выполнить некоторые интерфейсные http-вызовы для некоторого api (ajax-запросы) для взаимодействия с серверными приложениями. Выполнение таких запросов может возвращать любые данные, которые вы хотите, например json. в этом случае исходные данные поступают из API, а не из html, который генерируется из серверной части и отправляется обратно клиенту. Вскоре вам захочется использовать фреймворк внешнего интерфейса для обработки обычных вещей, таких как увлажняющий шаблон из внутренних данных json. Я бы порекомендовал vue js, но react, angular … будет делать все, что нужно. Это может привести к созданию SPA (одностраничного приложения) со всеми его преимуществами и недостатками.
3. Возможно, вам также захочется придерживаться минимального внешнего интерфейса и загружать html-чанки из своего бэкэнда, если вы идете в этом направлении. но в 2020 году это довольно грязно (в 2000 году это было нормально ‘ ^^). Это также во многом зависит от того, какова ваша целевая цель «клиент». Вам нужно расширенное взаимодействие с интерфейсом? достаточно ли какой-либо необработанной HTML-формы? Также обратите внимание, что погружение в интерфейсные приложения — довольно бесконечная, захватывающая и полезная тема (для меня). Я ответил на ваши вопросы ?
4. Да, вы это сделали, и я приму ваш ответ, за исключением того, что у меня есть дополнительный вопрос относительно этого комментария. Я задал свой вопрос, как платформы электронной коммерции решают эту проблему? Например… У меня есть многопользовательское приложение, и у каждого клиента будет своя тема веб-страницы. Как обслуживать разные темы веб-страниц в зависимости от клиента? Кроме того, если это было нормально в 2000 году, а не сейчас, есть ли у вас какие-либо предложения, как сделать это лучше в 2020 году? 🙂
5. Я не уверен, что правильно понял ваш вопрос, но создание многопользовательского приложения сложнее. Это во многом зависит от того, как вы разделите своего арендатора. допустим, у вас есть арендатор для каждого поддомена: 1) сложнее обслуживать их все из статической корзины, и я думаю, вы захотите справиться с этим, поставив обратный прокси перед вашим cdn для обработки поддоменов или что-то в этом роде, но это выходит за рамки этой темы. У вас также может быть более простая целевая страница для входа в систему, которая загружается при входе пользователя в контекст клиента, и данные темы будут загружаться соответствующим образом либо при рендеринге страницы SPA, либо на стороне сервера.