Jak dodać powiadomienia do aplikacji: w aplikacji, e-mail i push

Aby dodać powiadomienia do aplikacji webowej, zacznij od powiadomień w aplikacji: tabeli powiadomień w bazie danych i ikony dzwonka, która pokazuje nieprzeczytane pozycje. Dodaj e-mail dla rzeczy, o których ludzie muszą wiedzieć, gdy ich nie ma, korzystając z dostawcy poczty, a web push wprowadź dopiero wtedy, gdy liczą się szybkie alerty, bo wymaga on service workera, zgody użytkownika i — na iPhone’ie — zapisania aplikacji na ekranie głównym. Niezależnie od wybranych kanałów twórz każde powiadomienie w jednym miejscu, po stronie serwera, i pozwól użytkownikom decydować, co chcą otrzymywać.

Ten poradnik porównuje kanały, pokazuje prostą architekturę i podaje prompty, których możesz użyć z asystentem do budowania aplikacji.

Główne kanały w porównaniu

Większość aplikacji potrzebuje powiadomień w aplikacji i e-maila. Push i SMS warto dodać tam, gdzie timing naprawdę ma znaczenie, np. przypomnienie o rezerwacji lub zamówienie gotowe do odbioru.

Jak działa system powiadomień

Trzymaj go prosto i centralnie:

1. Coś się dzieje. Ktoś dodaje komentarz, płatność się nie udaje, rezerwacja jest jutro.
2. Twój serwer wywołuje jedną funkcję, np. notify(user, type, data).
3. Funkcja sprawdza ustawienia użytkownika i zapisuje wiersz w tabeli notifications (dla dzwonka).
4. Następnie wysyła na inne kanały, które użytkownik włączył dla danego typu: e-mail przez dostawcę, push przez Push API.
5. Frontend pokazuje nieprzeczytane powiadomienia i oznacza je jako przeczytane po otwarciu.

Jeden punkt wejścia oznacza, że możesz dodać kanał, zmienić treść lub uwzględnić ustawienia bez szukania po całym kodzie.

Co zapisywać

Tabela powiadomień zwykle potrzebuje: ID użytkownika, typu (na przykład comment_reply), krótkiego tytułu i treści, linku do odpowiedniej strony, czasu utworzenia i czasu przeczytania. Osobna tabela ustawień przechowuje, jakich kanałów każdy użytkownik chce dla każdego typu.

Pokazywanie nowych powiadomień

• Ładowanie przy wejściu na stronę i odpytywanie co 30–60 sekund. Proste i niezawodne.
• Aktualizacje w czasie rzeczywistym przez WebSockets lub server-sent events działają natychmiast, ale dodają ruchome części. Zacznij od odpytywania, chyba że natychmiastowość ma kluczowe znaczenie.

Powiadomienia e-mail

E-mail wymaga dostawcy wysyłki i zweryfikowanej domeny; szczegóły znajdziesz w artykule jak wysyłać e-maile z aplikacji. Dla samych powiadomień:

• Wysyłaj z serwera, nigdy z kluczem dostawcy w przeglądarce.
• Grupuj gadatliwe zdarzenia. Jeden e-mail „3 nowe komentarze” jest lepszy niż trzy e-maile.
• Oferuj dzienne lub tygodniowe zestawienie dla mało ważnej aktywności.
• Dodaj link do rezygnacji lub ustawień w e-mailach niekonieczne. Zasady dotyczące e-maili marketingowych różnią się w zależności od kraju; sprawdź, co dotyczy Ciebie.

Powiadomienia web push

Web push pozwala stronie wysyłać alerty, które wyglądają jak powiadomienia z aplikacji. Zgodnie z dokumentacją MDN dla Push API działa to tak:

1. Twoja strona rejestruje service workera, czyli skrypt, który przeglądarka może uruchamiać w tle.
2. Po zgodzie użytkownika service worker subskrybuje przez PushManager.subscribe(). Przeglądarka zwraca subskrypcję z endpointem i kluczami szyfrowania.
3. Twój serwer zapisuje tę subskrypcję i gdy coś się dzieje, wysyła wiadomość na endpoint, zwykle podpisaną kluczami VAPID (parą kluczy identyfikującą Twój serwer).
4. Przeglądarka uruchamia Twojego service workera, który wyświetla powiadomienie, nawet gdy strona nie jest otwarta.

MDN zwraca też uwagę, że endpoint trzeba trzymać w tajemnicy, bo sama jego znajomość wystarcza do wysyłania wiadomości do tego użytkownika.

iPhone i iPad

WebKit dodał Web Push dla aplikacji webowych w iOS i iPadOS 16.4, z dwoma warunkami podanymi w ogłoszeniu: strona musi być dodana na ekran główny, a zgoda musi być prośbą w odpowiedzi na działanie użytkownika, np. kliknięcie przycisku Subskrybuj. Dlatego na iPhone’ie push dociera tylko do użytkowników, którzy zainstalowali Twoją aplikację webową. Co oznacza instalacja aplikacji webowej, wyjaśnia artykuł natywne aplikacje a progresywne aplikacje webowe.

Jak dobrze prosić o zgodę

Nie pytaj przy pierwszej wizycie. Najpierw wyjaśnij korzyść („Dostaniesz przypomnienie godzinę przed zajęciami”), a dopiero gdy użytkownik kliknie przycisk, pokaż okno przeglądarki. Jeśli ktoś odmówi, przeglądarka może nie pozwolić zapytać ponownie, więc przedwczesne pytanie może stracić go na zawsze.

Zaplanowane powiadomienia wymagają wyzwalacza

„Przypomnienie 24 godziny przed” albo „cotygodniowe podsumowanie w każdy poniedziałek” potrzebują czegoś, co uruchomi się zgodnie z harmonogramem. To problem zadań w tle, omówiony w artykule jak uruchamiać zadania w tle. Częsty wzorzec: zewnętrzny harmonogram wywołuje chroniony endpoint co kilka minut, a endpoint wysyła wszystko, co jest do wysłania.

Prompty dla asystenta do budowania

Zacznij od powiadomień w aplikacji:

Dodaj powiadomienia w aplikacji. Utwórz tabelę notifications (user, type, title, body, link, created_at, read_at). Dodaj funkcję serwerową notify(userId, type, data), z której korzysta każda funkcja. W nagłówku pokaż ikonę dzwonka z licznikiem nieprzeczytanych, rozwijaną listę 20 ostatnich i przycisk „Oznacz wszystkie jako przeczytane”. Odpytuj o nowe co 60 sekund.

Potem ustawienia i e-mail:

Dodaj ustawienia powiadomień: dla każdego typu (odpowiedzi na komentarze, wzmianki, rozliczenia) użytkownik wybiera: w aplikacji, e-mail, oba lub żadne. notify() ma to uwzględniać. Wysyłaj e-maile przez [DOSTAWCA], używając sekretu [NAZWA_ZMIENNEJ] wyłącznie po stronie serwera. Grupuj e-maile o komentarzach, tak aby jeden użytkownik dostawał najwyżej jeden e-mail co 15 minut.

Następnie push, jeśli go potrzebujesz:

Dodaj opcjonalne web push. Zarejestruj service workera, wygeneruj klucze VAPID i zapisz klucz prywatny jako sekret. Dodaj w ustawieniach przycisk „Włącz powiadomienia”, który prosi o zgodę dopiero po kliknięciu. Zapisuj każdą subskrypcję dla użytkownika i urządzenia, wysyłaj pushe z notify(), gdy użytkownik się na nie zgodził, i usuwaj subskrypcje, które usługa push zgłasza jako wygasłe.

Częste błędy

• Powiadomienia rozrzucone po kodzie. Każda funkcja wysyła własny e-mail na swój sposób, a ustawienia są ignorowane. Używaj jednej funkcji notify().
• Prośba o zgodę na push przy wczytaniu strony. Większość osób odmawia, a drugiej szansy może nie być.
• Brak ustawień. Użytkownicy, którzy nie mogą wyłączyć uciążliwych alertów, wyłączają wszystkie albo odchodzą.
• Wysyłanie z przeglądarki. Klucze do e-maila i push powinny być po stronie serwera.
• Brak sprzątania martwych subskrypcji push. Wygasłe subskrypcje się piętrzą i marnują wysyłki.
• Wrażliwe szczegóły w treści powiadomienia. Ekrany blokady je pokazują. „Masz nową wiadomość” jest bezpieczniejsze niż sama wiadomość.
• Brak zapisu tego, co wysłano. Gdy użytkownik mówi „nie dostałem e-maila”, logi z ID wiadomości u dostawcy pomagają ustalić przyczynę.

Lista kontrolna

• Jedna funkcja notify() po stronie serwera, używana wszędzie
• Tabela powiadomień ze stanem przeczytania oraz dzwonek z licznikiem nieprzeczytanych
• Ustawienia kanałów dla każdego typu, uwzględniane przez notify()
• E-mail wysyłany z serwera przez zweryfikowaną domenę; zestawienie lub grupowanie dla gadatliwych zdarzeń
• Zgoda na push proszona dopiero po działaniu użytkownika, z wyjaśnieniem
• Push przetestowany na komputerze i na iPhonie z aplikacją dodaną na ekran główny
• Wygasłe subskrypcje push usunięte
• Brak wrażliwych treści w podglądach push i e-maili
• Zaplanowane przypomnienia mają niezawodny wyzwalacz

Powiadomienia w Mythex

Mythex nie zawiera wbudowanej usługi e-mail ani push dla budowanych przez Ciebie aplikacji, więc przynosisz własnego dostawcę poczty i generujesz własne klucze push, zapisywane jako sekrety projektu. Część w aplikacji potrzebuje tylko bazy danych projektu, którą Mythex dodaje na Twoją prośbę. Buduj promptami podobnymi do powyższych, testuj dzwonek i e-maile w podglądzie, a push testuj na opublikowanym adresie URL, bo service workery i push wymagają prawdziwego adresu HTTPS. Przepis w dokumentacji Wysyłanie e-maili z aplikacji zawiera gotowy prompt startowy. Mythex nie dokumentuje zadań zaplanowanych, więc zaplanuj przypomnienia czasowe z zewnętrznym wyzwalaczem, jak opisano w artykule jak uruchamiać zadania w tle.

Pytania