Hejto.pl
Hejto
/Wpisy
/Batch processing zasobów - analiza problemu - devszczepaniak.pl
Batch processing zasobów - analiza problemu - devszczepaniak.pl
Programowanie

Batch processing zasobów - analiza problemu - devszczepaniak.pl

devszczepaniak.pl
elszczepano2
W najnowszym artykule na blogu przygotowałem analizę praktycznego zadania programistycznego. Zadanie polega na pobraniu z systemu A zestawu danych i na ich podstawie wykonanie akcji w systemie np. dodanie ich do systemu B. Zadanie wydaje się proste jednak wraz z pojawianiem się kolejnych wymagań i składowych liczba miejsc, gdzie może coś pójść nie tak, będzie rosła.

W artykule zaproponowałem dwa podejścia - jedno proste i jedno, które wielu pewnie uznałoby za przekombinowane. Zachęcam do przeanalizowania problemu i przedstawionych problemów samodzielnie i do podzielenia się swoimi wnioskami i propozycjami.

#programowanie
#informatyka
#programista15k
#frontend
#naukaprogramowania
#backend
2

Komentarze (2)

Dzemik_Skrytozerca

Zaciekawiony przeglądnołem artykuł. A że akurat ocieram się o tematykę związaną z information brokers, to dorzucę do przykładu kilka dodatkowych zagadnień.


Oczywiście, to tylko kilka drobiazgów. To bardzo złożona tematyka.


W mojej skromnej opinii realizacja czynności powinna uwzględniać jeszcze takie sprawy:


- granulacja danych - podział danych na minimalne, nierozbieralne dalej czastki

- transakcyjnosc na poziomie czastek

- asynchroniczność - możliwość pobierania cząstek w różnej kolejnosci

- wersjonowanie api - by zapewnić spójność API restowego

- wersjonowanie danych - by aktualizacja danych klienta była możliwa, by aktualizacja danych klienta w trakcie pobierania danych nie destabilizowala synchronizacji

- priorytetyzacja i kolejkowanie - zarówno interfejs restowy i system B mają ograniczone zasoby. Zatem dane mają priorytety, i są kolejkowane.

- sesyjnosc - zwalnianie zasobów spoza sesji.

elszczepano

@Dzemik_Skrytozerca


Co do transakcyjności to też kiedyś się nad tym zastanawiałem. Jakby w przykładzie z artykułu każdy zasób trzeba tworzyć w API docelowym osobno to co jeśli np. ostatni request się wysypie? Jakby zrobić rollbacka rodem z SQL to trzeba by usunąć zasób i za chwilę stworzyć go od nowa. To robi się problematyczne, jeśli dodanie zasobu ma jakieś side effecty np. gdy dodanie usera powoduje wysłanie mu powiadomienia na maila. Zrobimy rollbacka, pójdzie powiadomienie a konta nie ma


Dzięki za uzupełnienie!

Zaloguj się aby komentować