Jak to działa

Plik o nazwie report.pdf niekoniecznie jest PDF-em, a plik zupełnie bez rozszerzenia zwykle i tak da się rozpoznać. Dlatego najpierw czytamy początkowe bajty przesyłki i porównujemy je ze znanymi sygnaturami formatów.

To ważniejsze, niż brzmi. Zaufanie rozszerzeniu sprawia, że przemianowany plik albo kończy się niezrozumiałym błędem, albo — co gorsza — trafia do niewłaściwego narzędzia. Czytanie bajtów sprawia, że źle podpisany plik i tak konwertuje się poprawnie, a plik, który naprawdę nie jest tym, za co się podaje, zostaje jasno odrzucony.

Każda obsługiwana konwersja to krawędź między dwoma formatami, a każda krawędź zapisuje, jak wierna jest, ile mniej więcej kosztuje i jak duże wejście przyjmuje. Z tego grafu generowane są strony formatów i jest on publikowany w całości przez API.

Jeśli między wskazanymi formatami nie ma krawędzi, dowiadujesz się o tym od razu, a nie po przesłaniu pliku. Nic nie jest po cichu prowadzone przez stratny format pośredni, żeby konwersja sprawiała wrażenie działającej.

Przeskalowanie obrazu trwa znacznie krócej niż sekundę, więc wykonuje się wewnątrz żądania, a odpowiedź zawiera już wynik. Złożenie długiego dokumentu albo transkodowanie wideo nie, więc takie zadania trafiają do kolejki i podejmuje je osobna pula procesów.

Nigdy nie musisz zgadywać, co dostałeś. Zakończone zadanie wraca z wynikiem; zakolejkowane wraca z identyfikatorem, pozycją w kolejce i szacunkiem — a Ty je odpytujesz albo czekasz na e-mail.

Strona, API i konwersja przez e-mail to trzy drzwi do jednego potoku. Różnią się wyłącznie tym, jak rozpoznawany jest wywołujący — ciasteczko sesji, token bearer albo nadawca wiadomości — a potem wykonują dokładnie ten sam kod.

To celowe ograniczenie, a nie szczegół implementacyjny. Dwie implementacje „sprawdź limit, zbadaj bajty, zabezpiecz archiwum” to sposób, w jaki jedna z nich w końcu pomija krok akurat dla tych, którzy najmniej prawdopodobnie to zauważą.