Lista zakupów

1. 01

   Działa bez internetu, zawsze

   Nie ma osobnego „trybu offline", który da się włączyć albo zapomnieć włączyć. Aplikacja zawsze zapisuje najpierw na telefonie, a z siecią rozmawia w tle. Tryb samolotowy, zamknięcie aplikacji, otwarcie jej trzy dni później — nic nie ginie.

2. 02

   Mówi wprost, czego jeszcze nie wysłała

   Kiedy coś czeka na wysłanie, na ekranie jest napisane „3 czekają na synchronizację". Żadnego udawania, że zapisano, i żadnej ciszy, po której trzeba zgadywać.

3. 03

   Obsługa jedną ręką, bo w drugiej jest koszyk

   Wszystko, co się naciska, mieści się w dolnej części ekranu. Lista rośnie do góry, więc nic nie przeskakuje pod palcem, kiedy dopisujesz kolejną rzecz.

4. 04

   Nie da się odhaczyć czegoś przypadkiem

   Odhaczenie to przeciągnięcie klocka w bok, nie kliknięcie. Kliknięcie było gotowe i zostało wyrzucone: klocek zajmuje cały wiersz, więc przy przewijaniu co chwilę coś odhaczało się samo.

2

osobytyle jej używa i taka jest cała skala

3 lata

historii zakupówprzeniesione ze starej listy

10 000+

pozycjiprzewija się bez zacinania

0 zł

miesięczniemieści się na darmowych planach

1. 01

   Silnik synchronizacji jest napisany ręcznie i to jest właśnie sedno

   Około 400 linii: pobieranie różnicowe prowadzone kursorem czasu serwera, outbox będący zbiorem brudnych rekordów, a nie logiem tylko-do-dopisywania, i rozwiązywanie konfliktów przez „ostatni zapis wygrywa" na całym wierszu. PowerSync, ElectricSQL i RxDB były rozważone i odrzucone; dla jednej tabeli, dwóch piszących klientów i dziesięciu tysięcy wierszy usługa synchronizacji dodaje drugiego dostawcę i własny język reguł, żeby uniknąć dokładnie tego kodu, który warto pokazać.

2. 02

   Offline nie jest trybem, jest jedyną ścieżką

   Interfejs czyta i zapisuje do IndexedDB i do niczego więcej. Tryb samolotowy, wymuszone zamknięcie, otwarcie trzy dni później: kolejka nadal tam jest i opróżnia się przy następnym uruchomieniu. iOS nie ma API Background Sync, więc aplikacja mówi wprost „3 czekają na synchronizację", zamiast udawać, że zapisała.

3. 03

   Przeszła zderzenie z rzeczywistością, a błędy są najlepszą częścią

   upsert w PostgREST kompiluje się do INSERT … ON CONFLICT DO UPDATE, więc sprawdza politykę INSERT nawet dla wierszy, które już istnieją. Edycja pozycji dodanej przez drugą osobę trwale nie przechodziła RLS i zatykała kolejkę. Poprawka rozdziela ścieżkę zapisu według autorstwa.

   Testy przechodziły, bo każdy z nich działał jako jeden i ten sam użytkownik. To był prawdziwy błąd w konstrukcji zestawu testów, nie w kodzie.

4. 04

   Obsługa jedną ręką jest ograniczeniem, a nie elementem wykończenia

   Używa się tego na stojąco w sklepie, z koszykiem w drugiej ręce, więc wszystko interaktywne mieszka w dolnych 40% ekranu. Lista jest wieżą zakotwiczoną u dołu, która rośnie górną krawędzią, dzięki temu nic, co jest już na ekranie, nie przeskakuje przy dodaniu pozycji, a najstarsze i najbardziej zaległe rzeczy leżą prosto pod kciukiem.

5. 05

   Ruch jest łańcuchem sprężyn, a nie silnikiem fizyki

   Każdy klocek wyprowadza swoje przechylenie z wartości ruchu przeciąganego klocka, przez własną sprężynę, ze sztywnością i tłumieniem malejącymi wraz z odległością od luki. Ten gradient sam z siebie daje opóźnienie, wybieg i osiadanie, bez integratora i bez detekcji kolizji. Prawdziwy solver odrzuciłem z powodu determinizmu, nie wydajności: nie potrafi zagwarantować, że klocki wrócą dokładnie na swoje pozycje.

~400

linii silnika synchronizacji

10 000+

pozycji w historiilista wirtualizowana

~30

asercji na żywym backendzie

0

usług synchronizacjisilnik napisany od zera

1. UUID-y generowane po stronie klienta

   Wstawienie offline potrzebuje stabilnej tożsamości natychmiast, inaczej nie da się go do niczego odnieść przed dotarciem do serwera. To również jest to, co pozwala echu realtime z własnego zapisu rozpoznać się jako duplikat lokalnego wiersza.

   Czekanie na identyfikator z serwera czyni wstawienia offline nieadresowalnymi i duplikuje każde echo realtime.

2. Kursor różnicowy to czas serwera minus bezpieczny zakład

   updated_at jest stemplowane w momencie wykonania instrukcji, ale wiersz staje się widoczny dopiero, gdy jego transakcja się zatwierdzi, więc wiersz ostemplowany na T może pojawić się po tym, jak kursor minął T, i nigdy nie zostałby pobrany.

   Każde pobranie cofa zapisany kursor o około 5 sekund. Ponowne pobranie kilku sekund nic nie kosztuje, bo upsert jest idempotentny; zgubienie wiersza jest ciche i trwałe.

3. Usuwanie miękkie wszędzie, a baza w ogóle odbiera prawo do DELETE

   Trzy lata i ponad 2000 zrealizowanych pozycji musiało przejść migrację, a usunięcie miękkie propaguje się przez pobieranie różnicowe jako zwyczajna aktualizacja, bez żadnej tabeli nagrobków.

4. RLS z funkcją pomocniczą security definer

   Polityka na list_members, która sama czyta z list_members, rekurencyjnie zapętla się w nieskończoność. Dołączenie do listy po kodzie też nie może być zwykłym wstawieniem, bo RLS nie pozwoli klientowi odnaleźć listy, której nie jest jeszcze członkiem, więc idzie to przez RPC.

   Postgres domyślnie nadaje też EXECUTE roli PUBLIC, co do momentu wyraźnego odebrania zostawiało każdą funkcję security definer osiągalną dla anon.

5. iOS zostawia kanały realtime, które kłamią

   Kanał dalej raportuje stan joined po tym, jak jego gniazdo zostało przeładowane, i po cichu nie dostarcza niczego. Nie da się tego sprawdzić z zewnątrz, więc po każdej nieobecności dłuższej niż kilka sekund kanał jest wymieniany, a nie badany.

6. Silnik jest weryfikowany przeciwko żywemu backendowi

   Około 30 asercji na fake-indexeddb: opróżnianie kolejki, zachowanie kursora, idempotentność scalania, seria zmian offline przetrwająca wymuszone zamknięcie, ochrona wierszy oczekujących, pełne pobranie na zimnym urządzeniu i druga osoba edytująca pozycję dodaną przez pierwszą.

   Ten ostatni przypadek jest regresją, która wyłapałaby błąd RLS za pierwszym razem.

1. Sklepy są markami, nie oddziałami

   W zasięgu spaceru są trzy Żabki, a Rossmann jest w dwóch różnych miastach. Przypisanie współrzędnych do sklepu jest decyzją, która czyni filtr błędnym, a nie mądrym, użyteczną osią jest „w którym sklepie to kupuję", a to jest marka.

2. Filtry wynikają z aktywnych pozycji, a nie z listy wszystkich sklepów

   Nie ma nieodhaczonych rzeczy z Lidla, nie ma filtra. Rząd zostaje krótki, a każdy filtr jest gwarantowanie niepustym wynikiem.

3. Odhaczanie kliknięciem zostało zbudowane, a potem świadomie usunięte

   Klocek zajmuje cały wiersz, więc każde muśnięcie przy przewijaniu trafiało w któryś i oznaczało go jako zrobiony. Przypadkowa zmiana stanu kosztuje znacznie więcej niż pół sekundy, które kosztuje celowe przeciągnięcie więc odhaczaniem jest przeciągnięcie, a kliknięcie otwiera panel szczegółów.

4. Emoji pochodzą z ręcznie zrobionego dwujęzycznego słownika rdzeni, nie z biblioteki

   Dwie osoby korzystające z listy celowo przekręcają nazwy w ramach wewnętrznego żartu, więc dopasowanie rozmyte walczyłoby z nimi. Istniejące indeksy słów kluczowych nie mapują polskiego, a cokolwiek semantycznego jest albo zdecydowanie za ciężkie dla PWA działającej offline, albo wywołaniem API.

   Brak wyniku jest poprawnym wynikiem, żadne emoji jest lepsze niż złe emoji.

5. Cały interfejs wyprowadzony jest z jednego koloru akcentu

   Powierzchnie, tekst i linie to ten akcent domieszany w kilku procentach do prawie białego albo prawie czarnego, przez color-mix w oklab. Wybór akcentu przebarwia całą aplikację, a nie jeden przycisk.

6. Słoje drewna są fotografią

   Dwie próby proceduralne wypadły wcześniej: powtarzalne gradienty są z definicji równomierne i czyta się je jako sztruks, a feTurbulence daje szum, a nie długie, nierówne, miejscami sękate linie, jakie drewno naprawdę ma.

26 s · 780×1688