Как да създадете уебсайтове, които работят без интернет, използвайки Angular & сервизни работници

Въведение

В тази статия ще научите теорията за това как работят сервизните работници. Предоставям кратък урок за прилагане на тази теория, за да направите уебсайт, който работи без интернет. Накрая ще обсъдя какво означава това за вас и бъдещето на интернет.

Вълнувам се, когато говоря за сервизни работници. Ще отида на бърз рейтинг на проблема, който решава и защо това е страхотно. Тогава се потопя в теорията за това как работят сервизните работници и защо е страхотно. Ако искате да преминете направо към теорията или урока, отидете на секциите, започвайки от заглавия Теория и приложение за кода.

Тази публикация в блога е достъпна и като:

  • Youtube Video
  • Плъзгаща се палуба
  • Подкаст

Съдържание

  • Уебсайтовете са странни
  • Теория: Как работят работниците на сервизите
  • Приложение: Урок за това как да изградите офлайн уебсайтове
  • Предварителни
  • Инсталиране на сервизния работник
  • Част 1а: Изградете работника по обслужването
  • Резултат от сервизен работник
  • Част 1б: Тестване на сервизния работник (# 2001441)
  • Създаване на мини сървър
  • Проверка на заявките на сървъра
  • Къде се съхраняват файловете?
  • Част 2: Запазване на външни данни (Част 1 Git Tag: pwa-tutorial-0.1)
  • Записване на външни обаждания по API: # 8593ada
  • Част 3: Уведомяване на потребителите на нови актуализации (Част 2 Git Tag: pwa-tutorial-0.2)
  • Част 4: Разгръщане (Част 3 Git Tag: pwa-tutorial-0.3)
  • заключение
  • Кой се нуждае от мобилни приложения
  • Бъдещето на уебсайтовете
  • Допълнителна информация

Уебсайтовете са странни

Наскоро разбрах нещо, което ме накара наистина да осъзная колко мощни могат да бъдат работниците в сервиза. Когато имам интернет, имам чувството, че за моето внимание се състезават безкрайно много неща.

Но когато съм в самолет например и няма интернет връзка, конкуренцията за вниманието ми е много по-малко ожесточена. Трите неща, които обикновено мога да направя, е да прегледам снимките си, да гледам свален филм или да прочета електронна книга.

С обслужващите работници, ако сте в състояние да осигурите офлайн уеб преживяване за вашите потребители, можете да привлечете вниманието им в един от онези няколко моменти, когато конкуренцията за него е най-малко ожесточена.

Да започнем с проста диаграма. Какво представляват двата кръга в тази диаграма на Venn?

Нека ви намекна. Amazon, Alibaba и Facebook са едни от най-големите уебсайтове в света, обслужващи милиони потребители всеки ден. Ето някои статистически данни, за да поставите нещата в контекст за вас:

  • Alibaba 25 милиарда долара продажби за един ден (ден на сингъл)
  • 40% от облачните компютърни клиенти използват уеб услуги на Amazon, включително Apple, Netflix и CIA
  • 2.2 милиарда души използват Facebook всеки месец, 700 милиона в Instagram

Всичко това е добре и добре, но има само един малък проблем. Без wifi, техните цели уебсайтове са напълно неизползваеми. Дори ако просто искате да вършите прости задачи, като например да погледнете прегледите на продукти за артикули, които вече са в количката ви, не можете да направите нищо.

Сега сравнете това със сайтове като Google Drive или Atila.ca. Atila.ca няма милион потребители, но дори когато нямате интернет връзка, все още можете да използвате сайта. Google Drive е друг уебсайт, който прави това добре. Всъщност можете да използвате Google Drive дори без интернет. Харесвайте как бихте използвали настолно приложение като Microsoft Word. Научете нещо ново всеки ден нали?

В миналото почти изглеждаше като тройство, че уебсайтовете няма да работят без интернет. След като осъзнаете потенциала на обслужващите работници, вие напълно променяте своята гледна точка за това как мислите за уебсайтовете. Започвате да си представяте значителните подобрения на потребителското изживяване, които можем да имаме в любимите ни сайтове.

Представете си, ако сте в метрото да пътувате до работа без интернет. Вие дори нямате никаква услуга за мобилен телефон. Но все пак бихте могли да прегледате прегледите на продуктите на артикулите във вашата количка за пазаруване на Amazon. Или сте на дълго пътуване със самолет Докато телефонът ви е в самолетен режим, можете да четете най-популярните статии от The New York Times. Или любимите ви статии в списък, който сте избрали да запазите за по-късно.

Можете да видите, че потенциалът е голям и е лесно да започнете да мечтаете. Да се ​​върнем към реалността и да се впуснем в теорията за това как е всичко възможно.

Теория: Как работят работниците на сервизите

Служителят е прокси или пратеник между вашия браузър и интернет. Когато вашето уеб приложение поиска ресурси (изображения, html файлове, API на json и т.н.), сервизният работник го получава вместо вас, без да е необходимо да питате в интернет. В буквален смисъл това е Javascript файл, който се доставя заедно с останалата част от приложението ви. Този файл има код, който казва на приложението ви как да прихваща мрежовите заявки и да го извлича от мрежовия кеш.

Обикновено, когато даден уебсайт е зареден за първи път, уеб браузърът отправя набор от заявки към мрежата за активите, които вашият уебсайт трябва да стартира. Обикновено включва:

  • html файлове за показване на съдържание
  • CSS файлове за стайлинг
  • Js файлове за логика на приложението
  • Изображения и други активи

Когато вашият интернет не работи, няма начин браузърът да се свърже с мрежата, за да извлече файловете, необходими за показване на уебсайта. Така че се проваля и получавате скандалния „скачащ динозавър“ в Google Chrome.

Със сервизни работници. Първият път, когато посетите даден сайт, в допълнение към обичайния набор от файлове index.html, styles.css, main.js и др., Които получавате искане, браузърът също така изисква JavaScript файл на вашия служител от вашия уебсайт. След това този файл се изтегля и записва в кеша на вашия браузър. След това файлът на сервизния работник изтегля, версиите и кешира всички файлове в приложението ви, за да го служи за по-късно.

Това има две много важни предимства. Както е споменато в заглавието, това означава, че дори когато вашата интернет връзка е прекъсната, уебсайтът ще продължи да работи. Всъщност никога не трябва да иска от интернет нещо. Сервизният работник разполага с всички файлове, от които се нуждаете.

И обратно, това също означава, че дори и да имате интернет, приложението също ще работи по-бързо. При бъдещи зареждания на уебсайтове, вместо да се извърши пълно пътуване до мрежата, за да получите файловете на приложението. Той просто извлича файловете от кеш паметта на браузъра и го обслужва на потребителя.

Приложение: Как да изградите офлайн уебсайтове

Предварителни

Преди да започнете, уверете се, че имате инсталирано следното

  • Node.js® и npm
  • Уверете се, че имате възел 8.X или по-голям (възел -v) и npm 5.x или по-голям (npm -v)
  • Глобално инсталирайте Angular CLI:
  • npm инсталирайте -g @ angular / cli
  • Google Chrome браузър (незадължително, но се препоръчва)
  • Профил в Google (незадължително, само ако искате да внедрите в Firebase)

Стартирайте проекта

  • Отворете https://github.com/atilatech/atila-web-app
  • Клонирайте уеб приложението demo.atila.ca от Github: atila-web-app
  • Вижте клона за pwa-урок: git checkout pwa-tutorial
  • Вижте ръководството за стартиране на урока: git checkout pwa-tutorial-0.0
  • Инсталирайте npm модули: npm install
  • Стартирайте приложението !: ng serve -o

Ако получите грешка No NgModule, отидете на всеки .ts файл и поставете интервал. Това е наистина странна грешка, но можете да прочетете този брой на Github за повече информация.

Инсталиране на сервизния работник

За да инсталираме Service Worker и да получим достъп до различните обекти на Service Worker в нашето приложение, трябва да направим следното.

  1. Инсталирайте модула @ angular / serviceworker: npm install @ angular / serviceworker
  2. Това инсталира npm пакет, който включва различни Javascript обекти на сервизен работник, които ще използваме в бъдещите стъпки
  3. Кажете на angular-cli за изграждане на проект със сервизен работник: ng set apps.0.serviceWorker = true
  4. Кажете на ъгловата CLI да произвежда автоматично Javascript файл, който съдържа кода за сервизния работник, когато изгражда проект, обяснен в следващата стъпка.
  5. Конфигурирайте вашия сервизен работник в ngsw-config.json
  6. Това казва на вашия сервизен работник, какви точно файлове трябва да се записват и как трябва да ги запазва
  7. assetGroups: файлове, които са включени като част от приложението
  8. Когато приложението се актуализира, тези ресурси също се актуализират
  9. dataGroups: външни ресурси, които не са съобразени с приложението
  10. Режим на инсталиране: Каква стратегия за кеширане да се използва при първо виждане на този файл
  11. UpdateMode: Каква стратегия за кеширане да се използва при актуализиране на файла, след като вече сме го инсталирали
  12. Стратегия за кеширане
  13. Предварителен избор: Запазете тези файлове, преди дори да го поискаме
  14. Мързелив: Запазете тези файлове само след като са били поискани поне веднъж
  15. Добавете файл manifest.json и го посочете в index.html

Конфигурация на сервизен работник

  • Това казва на вашия сервизен работник точно кои файлове трябва да се записват и как трябва да ги запазва:
  • assetGroups: файлове, включени като част от приложението
  • Когато приложението се актуализира, тези ресурси също се актуализират
  • dataGroups: външни ресурси, които не са съобразени с приложението
  • Режим на инсталиране: Каква стратегия за кеширане да се използва при първо виждане на този файл
  • UpdateMode: Каква стратегия за кеширане да се използва при актуализиране на файла, след като вече сме го инсталирали
  • Стратегия за кеширане
  • Предварителен избор: Запазете тези файлове, преди дори да го поискаме
  • Мързелив: Запазете тези файлове само след като са били поискани поне веднъж
  • Можете да проверите официалната ъглова документация за конфигурацията на сервизния работник за повече подробности

manifest.json

{
"име": "Atila",
"short_name": "Atila",
"start_url": "index.html",
"display": "самостоятелен",
"икони": [{
"src": "активи / img / favicon-bg.png",
"размери": "512x512",
"type": "image / png"
}],
"background_color": "# 194f87",
"topic_color": "# 194f87"
}

Това превръща приложението ви от уеб приложение в прогресивно уеб приложение. Тя позволява на уеб приложението ви да бъде подобно на родния мобилен телефон. Тя позволява на потребителите да инсталират приложението ви на началния си екран.

Регистрирайте сервизния работник (# d2b186f)

Сега всъщност трябва да кажем на нашето приложение, че съществува сервизен работник. Така че ние регистрираме модула на сервизния работник в нашия модул за приложения.

// src / app.module.ts
import {ServiceWorkerModule} от '@ angular / service-worker';
...
Внос: [
...,
ServiceWorkerModule.register ('/ ngsw-worker.js', {активирано: среда.производство}),]

След това регистрираме файла на работния служител, ако браузърът ни има поддръжка на сервизен работник и сме в производствен режим.

// src / main.ts
if („serviceWorker“ в навигатор && Environment.production) {
console.log ("Сервисен работник в main.ts");
window.addEventListener ('load', () => {
console.log ("на страница Load Service Worker в main.ts");
navigator.serviceWorker.register ('/ ngsw-worker.js', {
обхват: '/',
})
.then (регистрация => {
console.log ("Регистрацията на сервизен работник приключи main.ts", регистрация);
});
});

Част 1а: Изградете работника по обслужването

Резултат от сервизен работник

След това ще изградим проекта: ng build --prod

Нека разгледаме dist / папката, за да видим как изглежда изграждането на приложение със сервизен работник.

Изход на сервизния работник: ngsw.json

Спомнете си, че в предишната стъпка създадохме файл, наречен ngsw-config.json. Този файл уточнява какви типове файлове искахме от нашия сервизен работник да кешира и как искаме да го кешираме. Когато проектът бъде изграден, правилата в ngsw-config.json се разширяват, за да включват точно какви файлове ще кешираме. Файлът ngsw.json също включва хеш таблица за индексиране и извличане на кешираните файлове. Хеш таблицата също ни позволява да версия на нашите файлове. Можем да следим какви версии на нашия файл се изпълняват и дали трябва да получим нова версия.

Резултат от сервизен работник: ngsw-worker.js

Този файл е буквално обслужващият работник. Регистрирахме го по-рано в нашия main.ts файл. Това е обикновен javascript файл. Той съдържа кода и логиката за това как вашият сервизен работник регистрира и кешира данни в база данни. Ако сте готови за предизвикателство, опитайте да погледнете кода и да видите дали можете да разберете какво се случва.

Част 1б: Тестване на сервизния работник (# 2001441)

Създаване на мини сървър

  • Служителите се използват в офлайн контекст. Нуждаем се от сървър, който може да симулира офлайн среди
  • Инсталиране на npm http сървър
  • Npm инсталирайте http-server@0.11.1 --save-dev
  • Изграждане и стартиране на сървъра:
  • ng build --prod (незадължително)
  • http-сървър -p 8080 -c-1 dist

Проверка на заявките на сървъра

  • Посетете раздела Мрежа на Chrome в devtools
  • Направете това преди да отидете в localhost!
  • Отворете нов раздел
  • Щракнете с десния бутон някъде празно на екрана
  • Проверете> отидете на раздела Мрежа
  • Отваряне на http: // localhost: 8080 /

Обърнете внимание, че няма горе wi-fi горе вдясно. Проверете конзолата на devtools: Външните мрежови ресурси се провалят с 504, но нашите файлове са успешни (200).

Къде се съхраняват файловете?

Отворете раздела за приложения в Devtools и ще видите секцията за локален кеш. Това е „базата данни“, в която сервизните работници запазват вашите файлове. Че има 2 таблици. Този, който съдържа действителните ресурси, от които се нуждае нашето приложение. Друга хеш-таблица с хеш-ключове, които сочат към всяко име на файл, както видяхме в нашия ngsw.json файл. Това е! Вече имате просто, но функционално офлайн първо уеб приложение. Продължете към част 2 за добавяне на по-готини функции.

Част 2: Запазване на външни данни (Част 1 Git Tag: pwa-tutorial-0.1)

Защо никой от моите API не работи?

Когато се опитате да навигирате кликнете върху връзка, ще забележите грешка в сървъра. Вашият сервизен работник няма тези API в вашата база данни, но можем да го добавим. Поп викторина! Ако искаме да кажем на нашия сервизен работник да кешира нов тип файл, къде трябва да поставим кода:

  1. manifest.json
  2. Ngsw-config.json
  3. App.module.ts

Можете да видите мрежовите заявки да се провалят в раздела за мрежата на инструменти за разработчици.

Записване на външни обаждания в API: Конфигурация (Github Diff)

Сега ще конфигурираме нашия ngsw-config.json да кешира и външни URL адреси на API. Две опции за кеширане:

  1. Свежест: Първо отидете в мрежата, ако липсва, отидете на
  2. Производителност: Отидете първо на кеша, след това отидете на мрежа

Записване на външни обаждания по API: # 8593ada

Може да се наложи да използвате отделен URL, който позволява на приложението ви да получава достъп до него чрез CORS. Ще използваме специална услуга JSON, за да симулираме („подиграваме“) нашия блог API. Нямаме разрешение да използваме официалните API на Atila API

  • Промяна на ScholarshipService.getPaginatedScholarships:
  • Отидете на src / app / _service / academhip.service.ts # L47
  • Промяна: this.http.post ($ {this.scholarshipsPreviewUrl}? Page = $ {page} /, form_data) в: this.http.get (https://api.myjson.com/bins/dx1dc)
  • Промяна на BlogPostService.getBySlug:
  • Отидете на src / app / _service / blog-post.service.ts # L25
  • Промяна: this.http.get (блог $ {this.blogUrl} / $ {потребителско име} / $ {slug} /) в: this.http.get (https://api.myjson.com/bins/v5ow0)

Част 3: Уведомяване на потребителите на нови актуализации (Част 2 Git Tag: pwa-tutorial-0.2))

Когато се появи нова версия от мрежата, сервизният работник все още обслужва старата версия в кеша, за да спести време

  • Добавете вашия профил към страницата на отбора: src / app / team / team.component.ts
  • Добавете вашето изображение и малко информация в масива от данни за екипа
  • Ако възстановите проекта и рестартирате сървъра, ще забележите, че вашият профил все още не се показва.
  • Можем да добавим снек бар, за да известяваме потребителя за нови актуализации
  • npm install @ angular / material @ 5.1.1 - запишете (може би вече имате това)
  • След това създаваме swUpdate, за да слушаме актуализации от SW и актуализираме, ако е налична нова версия.Github Diff
// src / app / app.component.ts
    
import {SwUpdate} от "@ angular / service-worker";
...
    Конструктор (..., обществено swUpdate SWUpdate,)
...
ngOnInit () {
ако е вярно) {
// проверете сервизния служител, за да проверите дали е налична нова версия на приложението
ако (this.swUpdate.isEnabled) {
this.swUpdate.available.subscribe (() => {
const snackBarRef = this.snackBar.open („Нова версия е налична“, „Зареждане на нова версия“);
snackBarRef.onAction (). абонирате (
() => {
location.reload ();
});
});
}
}
}

Възстановете и резервирайте приложението си

Част 4: Разгръщане (Част 3 Git Tag: pwa-tutorial-0.3)

Разгръщане към хостинг на Firebase

За да видим ефекта на сервизния работник, трябва да го разгърнем на истински уебсайт. Харесвам Firebase хостинг. Можете да вземете уеб приложение от вашия localhost до уебсайт на живо за по-малко от 5 минути с няколко прости стъпки. Правя това вече почти 2 години и все още съм впечатлен от това колко лесен е процесът. Напоследък също играя с хостинг на уебсайтове на AWS S3 Static. Това е друга добра алтернатива, която можете да разгледате:

Предпоставки за разполагане:

  1. Създайте акаунт в google
  2. Създайте акаунт в firebase и проект в firebase
  3. инсталирайте firebase инструменти в световен мащаб: npm инсталирайте -g firebase-tools@4.2.0
  4. Влезте в firebase: вход в firebase
  5. Инициализирайте Firebase Repo: firebase init
  6. Изберете следните настройки:
  7. Изберете хостинг като тип проект
  8. Промяна на публичната папка на dist /
  9. Конфигурирайте като приложение за една страница
  10. Да презапишете idnex.html? НЕ
  11. Внедряване! Разгръщане на Firebase
  12. Посетете URL адреса в изхода на командния ред, за да видите приложението си

Това е! Поздравления, че сега имате уебсайт, който може да работи без интернет.

заключение

Кой се нуждае от мобилни приложения

По-рано писах за това, защо силно вярвам, че стартъпите и компаниите трябва да проектират своите технологични продукти като прогресивни уеб приложения вместо мобилни приложения. Основните ми аргументи са:

  1. Трябва да поддържате 2 отделни бази кодове за Android и IOS е болка: 2 групи потребители, 2 комплекта разработчици, 2 комплекта проблеми. (Неща като Flutter и Ionic са готини, но не вярвам, че те се занимават с основния проблем на 2 отделни кодови бази.)
  2. Повечето хора използват само едни и същи 5 приложения на ден, така че да ги убедите да изтеглят друго приложение ще бъде много трудно.
  3. Одобряването и разпространението чрез пазачите на Apple App Store и Google Play Store не са забавно.

Някои от основните аргументи срещу уеб приложения включват неща като:

  1. Офлайн достъпност
  2. По-добра ангажираност на потребителите поради известия чрез натискане
  3. Достъп до Native хардуерни функции като камери

С функции като сервизните работници току-що показах как можем да дадем възможност на уебсайтовете да работят офлайн. Прогресивните уеб приложения също позволяват push известия.

Характеристиките на родния хардуер все още са едно предимство, което имат мобилните приложения, въпреки че това се променя. Освен ако не е критично важно приложението ви да притежава тези естествени функции, силно насърчавам стартиращите компании и компаниите да обмислят да направят своето следващо приложение прогресивно уеб приложение.

Мисля, че бъдещето на интернет ще види повече приложения, разпространявани чрез браузъри и URL адреси, отколкото родните приложения и магазина за приложения. В ироничен случай на историята, която се повтаря, това всъщност е връщане към появата на интернет през 90-те години, когато компании като Netscape и различни „.com стартиращи компании“ много добре разпространяват своя софтуер през мрежата.

Бъдещето на уебсайтовете

Не би ли било страхотно, ако други сайтове прилагат същата философия? Представете си, ако сте като мен и имате час плюс пътуване, за да работите всеки ден. Забравете за wifi, те дори нямат клетъчна услуга в метрото.

Сега да предположим, че искам да купя Bluetooth слушалки и искам да прочета някои рецензии на Amazon, преди да взема решението си. Не би ли било страхотно, ако мога да кеширам подробности за продукта за артикулите в кошницата си и да прочета отзивите за начина ми на работа? Тогава до момента, в който се захващам за работа, мога просто да купя желания от мен предмет.

Или си представете, че сте в самолета за бърз полет от Торонто до Отава. Зареждате NY Times, за да наваксате сутрешните новини, но сайтът дава известния „Google динозавър“. В идеален свят NY Times трябва да кешира топ 5 на най-популярните статии. Това позволява на потребителите да четат статиите и да оставят коментари офлайн. Коментарите могат да бъдат синхронизирани, когато се свържат обратно към интернет.

Google Docs прави това най-добре. Google Документи са Microsoft Word, Powerpoint и Excel, но по-добри и създадени за Chrome. Не е необходим интернет, за да използвате Microsoft Word. Тъй като Google Документи работи в уеб браузър, трябва да можете да използвате Google Документи за достъп и редактиране на последните ви елементи. Което е точно това, което Google Docs прави добре.

Чувствам се леко горд от факта, че на страхотните уебсайтове на Amazon и NY Times се нуждае интернет. Скромна съм, че малката Atila.ca работи отлично с и без интернет. ;) Когато интернет не работи, все още можете да видите подбрани стипендии, публикации в блогове и други части от съдържанието.

Добре, това са предимно #FirstWorldProblems. Но още нещо, което ме вълнува наистина от тази технология, е изграждането на интернет за следващите милиарди потребители. За хора, които имат много бавна или непостоянна интернет връзка.

Например HospitalRun е първо офлайн приложение. Той управлява болниците в развиващия се свят. Това са места, където периодичната свързаност е факт от живота. Той позволява да се пренасят записи в отдалечени клиники, където може да няма интернет. След това синхронизира тези записи, когато има. (з / т jonbellah.com)

В Атила един от нашите проекти е увеличаване на достъпа до стипендии за студенти от развиващите се страни. Така че би било страхотно, ако те могат безпроблемно да прочетат примерни есета и да работят върху своите заявления за стипендии, дори ако живеят на места с лоша интернет връзка.

Аз лично намирам идеята за обслужващите работници и офлайн първите уеб приложения за много увлекателна. Простите технологии с възможност за фундаментална промяна на ежедневните навици на милиарди хора са защо избрах да уча софтуерно инженерство и защо обичам тази област. Наистина съм развълнуван не само да видя как ще се разгърне бъдещето на интернет, но и ще спомогна за изграждането на бъдещето на интернет и как ще го взаимодействаме. Бъдещето вече е тук, хора. Благодаря за четенето.

Допълнителна информация

  • Ъглова документация за официален сервизен работник
  • Angular University: Служители по ъглови услуги
  • Добавете Service Worker към съществуващото ъглово приложение
  • Angular Firebase - Разгръщане на ъглово приложение към Firebase