Комментарии 27
Всё никак не освою Service Workers. Всё по старинке пользую cache manifest. Он не такой гибкий зато не требует JavaScript. Вижу преимущество Service Workers в кешировании по запросу. Возможно их можно совместить.
Будет ли Service Workers работать если выключить для сайта JavaScript через настройки браузера или через NoScript? Предполагаю что нет.
У Service Workers есть один фатальный недостаток: нормально работает только по HTTPS. С одной стороны безопасность это прекрасно, но когда ты не контролируешь эту опцию это порой приводит к боли и страданиям.
Пример кейса, когда SW при использовании приносит боль:
Маленький сервис для внутренних нужд компании, с большой frontend-логикой. Он неплохо защищён во внутренней сети, хотя в этом и нужды нет. Но SW не регистрируется, если фронт не через https, поэтому кеширование не работает, установить как PWA — не работает. Для локальных машин можно было бы установить свой корневой сертификат, но как быть с Android/iOS?
Может быть в том, что, как я уже написал, этому сервису не нужен https, а всё чему он нужен использует LE. Или вы предлагаете купить сертификат? Или нужно ставить проксю с wildcard-сертификатом, что тоже не всегда удобно и хорошо.
В общем о том и говорю: нет проблем, кроме боли с сертификатами.
Проблема больше наверное даже не в самом https, а в том, как делать те или иные сертификаты доверенными или получить их от доверенного.
А прикручивать certbot на каждый сервис то ещё удовольствие. У нас Кубик внутренний и dns-челлендж там не самый простой процесс (во всяком случае пока не нашёл ничего внятного, что завелось бы).
Итого:
- Всё строго в одном домене.
- Каждый новый сервис будет требовать
танцы с бубном и тревогу в сердцеподсервиса для обновления сертификата и мониторинга ("дьявольская ромашка" или любит/не любит — отработает/сломается). - Нужду в AWS Route53, даже если есть своё "облако".
А все потому, что SW работает только по HTTPS, хотя мог бы прекрасно работать и без него. Я может старомоден, но чем меньше узлов для поломки, тем лучше, но это ведёт к зоопарку зависимостей.
1. Не «все в одном домене», а «один домен — один пайплайн для обновления сертификата». Если пайплайн унифицировать и запустить в какой-нибудь ci — то проблем никаких, хоть тысяча доменов.
2. Зачем? Я что-то не понял. Заверните все ваши сервисы в один условный load balancer который владеет сертификатом и внутри уже роутит траффик на куда угодно.
3. Ну вы же где-то держите ns'ы своего company.com все равно? Добавьте туда один wildcard IN вида *.corp.company.com, который будет направлять на тот самый «лоад балансер/роутер» с одним сертификатом, либо даже проще, если есть нужда изолироваться от внешнего мира — на внутреннем dns сделайте эту запись безо всяких Route53.
Итого — один автоматизированный пайплайн для обновления wildcard сертификата (даже если там много доменов, надо только автоматизировать правильно), один lb (ну может горизонтально заскейленный), который этим сертификатом/сертификатами владеет + одна wildcard-запись в публичном или приватном NS.
И все для того чтобы все внутренние сервисы унифицировано работали по честному https потому что почему бы и нет.
Зачем мне менять всю инфраструктуру ради HTTPS, который мне не нужен внутри сети?
Зачем мне lb, если сервисы могут работать и без него?
Вы понимаете, что значит децентрализированная модульная инфраструктура? Мне на каждый сервис лезть в балансировщик? И только затем, чтобы использовать SW?
Сейчас куча независимых сервисов работают и легко разворачиваются и убиваются. Умрёт какой-то сервис — другие работают. Вы же предлагаете кучу сервисов засунуть за один-N балансировщиков, которые нафиг не нужны, кроме как принудительно загонять трафик в https? Это же ректальное удаление гланд автогеном костыль!
Ну и вообще — что у вас за мания везде руками лазить и что-то добавлять при каждом обновлении? Балансировщик (который на самом деле скорее роутер/реверс-прокси, а не балансировщик, бо нагрузки-то нет) тоже можно настроить так, чтобы он роутил в автоматическом режиме от запроса (где запросом является собственно поддомен), нужна только какая-то конвенция.
Оно же у сейчас как-то работает? Какие-то имена сервисам присваиваются так, чтобы они становились доступны внутри сети. Значит есть какой-то механизм, с которым можно дружиться.
Наверное потому что помимо того что нужно делать https скорее всего нужно еще и настраивать авторизацию и регистрацию в том или ином виде. Если внутри сети можно политиками разрулить какой доступ к отчетам есть у какого отдела то вот в случае публичного сервиса эти отчеты торчат наружу что в некоторых случаях — вариант не очень собобенно с точки зрения безопасности.
Сотрудники начнут смотреть эти отчеты из дома, с того же компа где из ребенок установил крякнутый launcher на minecraft с трояном. И вот отчеты уже доступны злоумышленнику. После чего часть из этих отчетов с личными данные клиентов (ФИО, Адреса, Номера банковских карт) сливаются и продаются по сети...
Если используется свои CA то и такой вариант можно провернуть, но тогда нужно через доменые политики их накатывать на каждый комп (windows) или создать скрипты их установки для *nix.
Что касается доверенных сертификатов то на сколько я знаю let's encrypt и прочие вендоры не будут вам их оформлять например на ip 10.x.x.x или на домен www.mybestcompany.local возможно есть решения для enterprice которые сие могут но и поцена они собственно будет enterprice
Т.е. mybestcompany.local конечно не выйдет так оформить, а вот *.local.mybestcompany.com — вполне. И резолвить эти адреса на внутренние IP потом, при желании — только с внутренних NS-ов (т.е. они снаружи вообще резолвится не будут). При этом сертификат будет «честный» — не надо будет пользователям вручную ничего накатывать.
А на someting.lan нельзя никак. А вот многие таким паттерном пользуются.
И, хотя некоторые выгоды от https, разумеется есть и внутри локалки, но вопрос почему всё больше вещей я должнен переводить на https, у которых объективной потребности в шифровании нет, а есть просто навязанное требование разработчиков браузеров.
Это… печально…
Спасибо, до этого не сталкивался с такой задачей. Но решение отличное! буду знать на будущее!
dns-плагины будут работать даже глубоко из-за ната, какой-нибудь *.subdomain.company.com нужно будет только на cloudflare делегировать (хотя можно и лапками на своих NS-ах записи создавать, но тогда с автопродлением проблемы).
В тему подскажу библиотеку от гугла: workbox. В простейшем случае ставится одной строчкой в вебпаке и одной в init.js, огромное количество возможностей. Из недостатков — не очень нравится документация, иногда сложно понять как заставить ее делать что тебе нужно
Очевидно — описанная в статье схема работы подойдет, если приложение простое, отсутствие коннекта кратковременное, не подразумевается разбиение на чанки со своей бизнес-логикой и если CI настроен на релизную схему, например раз в неделю или на схожий период.
В другом случае: то, что пользователь "накликал" может быть завязано на права доступа и конкретные ответы сервера, так что пайплайн событий будет сломан; редиректы и открытие новых страниц при разбиении на чанки не будет работать — если не загружать их всех к кэш, а тогда их смысл теряется наполовину; в подавляющем большинстве случаев "оптимистичное обновление" будет обманывать юзера, и он получит негатив, когда "делал-делал и вдруг все сломалось", т.к. возникнет реальный коннект; если приложение имеет несколько релизов в день например по Kanban CI, то количество поломанных действий возрастет, ошибки в логгер будут сыпаться тоннами, а причина одна — полный рассинхрон реальности и оффлайнового кэша, и в этой каше будет сложно разобраться.
При длительном дисконнекте данные будут приходить старые, например отсутствовать ответы техподдержки или не обновляться статус услуги, что повысит нагрузку на техсап, которые будут разводить руками — опять что-то с сайтом нахимичили разрабы. При перезагрузке страницы нужно будет восстанавливать "виртуальный" стейт, который разойдется с серверным, если используется server side rendering, что приведет к непредсказуемым последствиям.
Вывод: если чуть сложней todo листа — лучше выбирать стратегию показа нотификации "у вас отвалился инет" и проверять раз в секунду, не появился ли он, сохраняя по возможности стейт приложения, либо по лайтсу пытаясь его частично восстановить при долгом отсутствии коннекта.
Большинство людей согласятся с тем, что лучше предоставлять потенциально устаревший пользовательский интерфейс, чем пустую страницу.
Не соглашусь.
Может лучше честно показать, что нет интернета и не тратить время пользователя, и не обманывать его ожидания «оптимистическими» ui. Взамен можно получить большой негатив, особенно если в оффлайн режиме дёргаются важные бизнес процессы, а на самом деле это не так. Сам на таком обжигался — очень не понравилось.
Документация redux рекомендует не использовать сайд-эффекты в редьюсерах
Как заставить ваши веб-приложения работать в автономном режиме