Odin MaxCode zamiast dziesiątek kluczy: jak PushMeld dodaje powiadomienia tam, gdzie ich nie było

Przedstawmy komputer domowy, który każdej nocy tworzy kopię zapasową ważnych plików. Wynik jest zapisywany w dzienniku systemowym: operacja zakończyła się pomyślnie lub wystąpił błąd.

Technicznie wszystko działa. Uciążliwość pojawia się rano: użytkownik musi samodzielnie otworzyć dziennik i sprawdzić wynik. Program nie ma aplikacji mobilnej, wysyłka powiadomień nie jest przewidziana przez deweloperów, a tworzenie osobnej infrastruktury dla jednej funkcji byłoby nieopłacalne.

Za pomocą PushMeld można dodać do takiego procesu prostą zapytanie. Po zakończeniu kopii zapasowej na telefon przyjdzie wiadomość: kopia utworzona lub operacja zakończyła się błędem. W razie potrzeby można otrzymać to samo powiadomienie email.

Podstawą tej koncepcji jest MaxCode — jednolity, zabezpieczony kod, przez który PushMeld otrzymuje wszystkie informacje niezbędne do dalszej dostawy powiadomienia.

Kiedy poznałem ten projekt, to właśnie MaxCode wydał mi się jego najciekawszą częścią. Powiadomienia push i email od dawna nie są nowością. Znacznie ważniejsze jest to, że oryginalny program przestaje zarządzać ich dostarczaniem. On jedynie informuje PushMeld o zdarzeniu, a reszta odbywa się już poza nim.

Na początku zaznaczę kontekst: PushMeld należy do systemu MELD®, a DigiMeld UG — firma rozwijająca ten system.

Źródło zna tylko o zdarzeniu

Zwykła integracja powiadomień szybko sprowadza się do kwestii technicznych. Trzeba zdefiniować projekt, ustalić dostęp, przechowywać klucze, obsługiwać tokeny urządzeń, konfigurować wysyłkę emaili i dostosować do wymagań różnych platform mobilnych.

PushMeld przenosi to wszystko z systemu źródłowego do oddzielnego, zarządzalnego kanału.

Program tworzący kopię zapasową zna tylko jedno: czy operacja zakończyła się sukcesem, czy błędem. Przekazuje MaxCode, tytuł i tekst powiadomienia.

Nie jest mu potrzebne, aby wiedzieć:

• Ile urządzeń jest podłączonych do projektu;

• Który telefon jest aktywny;

• Przez jakiego dostawcę ma przejść push;

• Czy dostawa email jest włączona;

• Czy użytkownik ma nowy smartfon;

• Czy wyłączono stare urządzenie;

• Kto powinien otrzymać konkretne powiadomienie.

Wszystko to jest już ustalane wewnątrz PushMeld.

Według mnie, właśnie tutaj znajduje się główna idea architektoniczna projektu: MaxCode przenosi zarządzanie powiadomieniami z programu, w którym wydarzenie miało miejsce, do systemu, który zajmuje się ich dostawą.

Jeden MaxCode zamiast wielu kluczy

Zazwyczaj przy podłączaniu zewnętrznego serwisu trzeba pracować osobno z kilkoma elementami. Osobno identyfikator projektu, osobno klucz dostępu, czasami potrzeba sekretów, tokenów urządzeń i ustawień danego dostawcy.

MaxCode łączy wszystko, co jest potrzebne do wysyłki, w jednym zabezpieczonym kodzie.

Dla każdego projektu tworzony jest własny MaxCode. Zawiera identyfikację projektu, uprawnienia do wysyłania oraz dane umożliwiające PushMeld zastosować aktualną konfigurację dostawy.

System wysyłający nie musi osobno przechowywać:

• identyfikatora projektu;

• klucza API i dodatkowego sekretu;

• tokenów połączonych urządzeń;

• parametrów każdego odbiorcy;

• kluczy różnych dostawców push;

• osobnych ustawień dla push i email.

Do programu, strony lub skryptu dodaje się jeden MaxCode. Otrzymując go wraz z wiadomością, PushMeld samodzielnie rozpoznaje projekt, weryfikuje żądanie, znajdzie podłączone urządzenia i wybierze dostępne kanały.

Dlatego MaxCode nie należy traktować jak kolejnego klucza dodawanego do reszty. Jego zadaniem jest zastąpienie całości typowego zestawu rozłącznych kluczy, tokenów i identyfikatorów jednym kodem.

Powiadomienie skąd, gdzie nie przewidziano

MaxCode można wykorzystać w dowolnym systemie, który potrafi wykonać żądanie HTTP samodzielnie lub za pomocą niewielkiego skryptu wsadowego.

Na przykład, PushMeld może informować, kiedy:

• domowy serwer przestał odpowiadać;

• zakończyło się lub zakończyło błędem tworzenie kopii zapasowej;

• własny skrypt wykonał długotrwałe zadanie;

• drukarka 3D zakończyła drukować;

• czujnik zarejestrował wyciek;

• otwarto drzwi lub uruchomiono alarm;

• pojawiły się nowe informacje na stronie;

• zmieniła się cena produktu;

• zwolniło się miejsce do zapisu;

• stary program zakończył przetwarzanie dużego pliku;
• mały sklep internetowy otrzymał nowe zamówienie.

Każde z tych źródeł może nie mieć własnej aplikacji. Niektóre urządzenia mogą tylko odwołać się do wybranego adresu, inne umożliwiają uruchomienie własnej komendy, a jeszcze inne można dopełnić krótkim skryptem automatyzacyjnym.

To wystarczy, aby przekazać wydarzenie do PushMeld.

Źródło przy tym nie zamienia się w samodzielną usługę powiadomień. Ono jedynie rejestruje zdarzenie i wysyła wiadomość z MaxCode. Cała reszta — odbiorcy, urządzenia, kanały i trasa techniczna — pozostaje po stronie PushMeld.

Nie tylko push, ale też email

Nazwa PushMeld kojarzy się głównie z powiadomieniami na telefonie, ale możliwości projektu na tym się nie kończą.

Do dostarczania można używać push, email albo oba kanały — w zależności od ustawień projektu i dostępnych opcji.

Na przykład, wiadomość o pomyślnym utworzeniu kopii zapasowej można wyświetlić na telefonie. Poważny błąd można dodać jako powiadomienie email.

Oryginalny program w obu przypadkach wykonuje jedno i to samo zapytanie z MaxCode. Nie musi osobno konfigurować serwera pocztowego, przechowywać ustawień ani tworzyć drugiego, odrębnego skryptu.

Decyzję o kanałach dostawy podejmuje wewnątrz PushMeld. Jeśli później użytkownik doda email do istniejącego projektu, nie trzeba modyfikować programu kopii zapasowej.

Przy tym email nie służy tutaj do masowej wysyłki, lecz jako dodatkowa metoda informowania o zdarzeniu zgłoszonym z podłączonego projektu.

Jeden projekt — jedno źródło zdarzeń

Projekty pozwalają dzielić powiadomienia według ich przeznaczenia.

Zwykły użytkownik może utworzyć na przykład:

• HomeServer — stan serwera domowego;

• Backups — wyniki kopii zapasowych;

• SmartHome — czujniki i automatyka domowa;

• PriceMonitor — zmiany cen;

• Website — nowe zgłoszenia ze strony internetowej.

Każdy projekt otrzymuje własny MaxCode. Dzięki temu automatyka domowa nie korzysta z kodu strony, a monitorowanie cen nie miesza się z kopiami zapasowymi.

W aplikacji od razu widać, skąd pochodzi wiadomość i do jakiego zadania się odnosi.

Takie rozdzielenie jest szczególnie przydatne, gdy liczba źródeł rośnie. Zamiast jednej wspólnej ścieżki, użytkownik otrzymuje kilka niezależnych kanałów, z własnymi ustawieniami dostawy.

Nowy telefon nie wymaga zmiany programu

Zwykły token push jest powiązany z konkretną instalacją aplikacji na określonym urządzeniu.

Jeśli użytkownik ma dwa telefony i tablet, to już kilka tokenów. Po reinstalacji lub wymianie urządzenia, token może się zmienić lub przestać działać.

MaxCode działa na wyższym poziomie. Jest powiązany z projektem, a nie z jednym urządzeniem.

Użytkownik sam decyduje, które urządzenia są powiązane z projektem i mają otrzymywać jego powiadomienia. Na przykład, powiadomienia o stanie serwera domowego można kierować na telefon i tablet użytkownika, a o zdarzeniach na stronie firmowej — tylko na służbowy smartfon.

Jeśli użytkownik kupi nowy telefon lub wyłączy stare urządzenie, skrypt źródłowy nadal będzie używał tego samego MaxCode. Aktualna lista odbiorców jest aktualizowana wewnątrz PushMeld.

To samo dotyczy dodawania email lub zmiany innych parametrów dostawy.

Dlatego MaxCode to nie tylko sposób na ograniczenie ilości kluczy. Tworzy granicę między zdarzeniem a jego dalszym przekazem. Wszystko po tej granicy można zmieniać bez ingerencji w program źródłowy.

Za darmo dla codziennych zadań

Produkty infrastrukturalne często są opisywane przez systemy korporacyjne, polecenia serwerowe i duże ilości danych. Z tego powodu można odnieść wrażenie, że PushMeld jest przeznaczony wyłącznie dla profesjonalnych deweloperów i firm.

W praktyce można zacząć od prostego zadania domowego.

Sam program jest darmowy. Podstawowe funkcje MaxCode również działają bez opłat, w granicach dostępnych darmowych limitów. Użytkownik może utworzyć projekt, podłączyć urządzenie i otrzymywać powiadomienia z serwera, strony, skryptu lub automatyki domowej.

To nie jest tymczasowy tryb demonstracyjny, który przestaje działać po poznaniu produktu. Dla codziennych scenariuszy darmowe możliwości mogą wystarczyć.

Plany abonamentowe są potrzebne, gdy rośnie liczba żądań, pojawiają się dodatkowe funkcje lub system zaczyna być wykorzystywany na większą skalę.

Jeden schemat dla użytkownika i firmy

Mechanika MaxCode nie zmienia się w zależności od rozmiaru zadania.

Użytkownik otrzymuje powiadomienie o zakończeniu kopii zapasowej. Mała firma dowiaduje się, że drukarka 3D zakończyła długotrwałe drukowanie. Sklep internetowy widzi nowe zamówienie. Zespół techniczny otrzymuje powiadomienie o błędzie na serwerze.

Różnią się objętości i liczba projektów, ale zasada pozostaje taka sama.

Wyobraźmy sobie organizację z trzema źródłami zdarzeń:

• Orders — nowe zamówienia;

• Payments — wpłaty i zwroty;

• ServerStatus — błędy techniczne.

Dla każdego tworzony jest odrębny MaxCode i konfigurowane własne urządzenia. Zamówienia trafiają do właściciela i menedżera, zdarzenia finansowe — do odpowiedzialnej osoby, a błędy techniczne — do obsługującego serwer specjalisty.

System firmy w każdym przypadku przekazuje zawartość zdarzenia i odpowiedni MaxCode.

Jeśli zmienią się pracownicy, urządzenia albo metody dostarczania, systemy źródłowe nie muszą być ponownie konfigurowane. Zarządzanie pozostaje po stronie PushMeld.

APNs, FCM i HMS pozostają poza programem

Do dostarczenia push na różnych urządzeniach mogą służyć APNs, FCM albo HMS. Każdy dostawca ma własne zasady, tokeny i specyfikę techniczną.

Zazwyczaj te różnice trzeba uwzględniać podczas opracowania systemu wysyłkowego. W przypadku PushMeld są one ukryte za granicą MaxCode.

Serwer domowy, strona czy skrypt nie decydują, które urządzenie korzysta odbiorca i przez którą infrastrukturę ma przejść wiadomość. Wykonują jedno żądanie, a PushMeld wybiera potrzebną ścieżkę.

MaxCode nie zastępuje infrastruktury Apple, Google czy Huawei. Tworzy jedną, wspólną bramę przed nią.

W ten sposób system źródłowy nie musi się zmieniać w miarę wymiany urządzeń użytkownika. Dziś wiadomość może być wysłana przez FCM, jutro — przez APNs, a w międzyczasie do projektu dołączony zostanie jeszcze jeden telefon albo email. Dla zdarzenia, które wystąpiło, nic się nie zmieni.

MaxCode i zwykły klucz API — to nie to samo

Zwykły klucz API zwykle tylko pozwala na dostęp do usługi. Po sprawdzeniu klucza, system musi osobno przekazać projekt, odbiorców i metodę dostawy.

MaxCode łączy te konteksty w jednym kodzie.

Umożliwia PushMeld rozpoznanie projektu, weryfikację żądania i zastosowanie odpowiednich ustawień. Zewnętrzny program przekazuje MaxCode i treść zdarzenia, nie zarządzając dalszym trasowaniem.

Praktyczna różnica można ująć krótko: klucz API otwiera dostęp do funkcji, a MaxCode jednocześnie określa, w jakim kontekście ta funkcja powinna zostać uruchomiona.

Powiadomienie jako funkcja do podłączenia

Po poznaniu PushMeld nie nazwałbym go tylko aplikacją do powiadomień push.

Bardziej precyzyjnie, to sposób dodania powiadomień tam, gdzie ich wcześniej nie było, a następnie zarządzania nimi niezależnie od programu źródłowego.

Źródłem mogą być domowy serwer, czujnik, stare oprogramowanie, sklep internetowy, własny skrypt lub wewnętrzny system firmy. Jeśli potrafi wykonać żądanie HTTP samodzielnie lub przez mały adapter, wydarzenie można przekazać do PushMeld.

Potem MaxCode tworzy granicę między zdarzeniem a jego dostawą. Po jednej stronie jest program, który zgłasza, co się wydarzyło. Po drugiej strony — PushMeld, który określa projekt, urządzenia, kanały i trasę techniczną.

Dlatego najważniejszą funkcją MaxCode jest nie tylko zamiana wielu kluczy jednym kodem. Przenosi zarządzanie powiadomieniami poza źródłowy system.

Telefon można zamienić, email — dodać, stare urządzenie — wyłączyć, a trasa dostawy — zmienić. Program nadal będzie tylko informować o zdarzeniu, o które chodzi.