Kompresja na azure?

Intro

Poprzednio (tutaj) było o gzipe w odpowiedziach z aplikacji, tym razem o jeszcze jednym gzipie.


Problem

Ściągam dużo danych (nie big data, ale sam za to płacę), trzymam to w wersji surowej na przyszłość, bo gdy będę chciał wyświetlić więcej informacji, to mogę przejechać od początku wszystkie dane, tak mam plan :). Część surówki zostaje przeparsowana i zamieniona na jsona. Jeszcze jedna część z tych danych będzie zwracana do klienta, a klient (frontend) ten obsługuje gzipa – także combo profit; mniej miejsca, mniejszy transfer.

Mięso

Aby bogowie testów i abstrakcji byli zadowoleni byli zadowoleni wydzieliłem taki oto interface

Kod będzie mi ogarniać zapis, odczyt i usunięcie danych z bloba. Jak widać, nie przewiduje aktualizacji danych na blobkach.

Ciało (tłuste jak na bloga, wybaczcie) wygląda tak:

O wstrzykiwaniu zależności w Azure functions pisałem wcześniej (tutaj), o tym, że mogą być nulle także, aby czuć się bezpieczenie w kontruktorze dodałem sprawdzenie.

Gdy podejrzymy jakiegoś blobka w jego naturalnym habitacie będzie wyglądać tak:

Sama klasa jest jeszcze przed refaktoryzacją (wiecie terminy wpisów na bloga gonią 😉), poza tym sam nie wiem gdzie jeszcze, dojdę dalej. Ważne natomiast jest to, że dzięki takiej abstrakcji mogę robić CRD na i z chmurkę i trzymać tam zakompleksione skompresowane dane, oraz serwować jest do klienta także zakom skompresowane, tak ostatnia operacja jest już za darmo.

No to tyle na dziś, zdrowia!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.