Pokusim se pridat z vlastni zkusenosti o co vlastne jde, jeste nez se asyn modely zacaly implementovat primo na urovni jazyka, asynchronni/event driven architektury uz existovali materializovane na urovni celych kup systemu, asi nejcenejsim zdrojem,ktery mi cele roky slouzil jako zdroj jak stavet asyn architektury mi byly tzv messaging patterns:
https://www.enterpriseintegrationpatterns.com/Prave tyto principy zde definovane, resp. pouze nektere z nich se zacaly integrovat primo do ruznych jazyku, tj. to, co se bezne pouzivalo na urovni integrace sluzeb/systemu, se zacalo pouzivat primo jako mechanismus vyvoje jednotlive sluzby, resp. jejich subkomponent. Skoda, ze kazdy jazyk si vytvoril ruzna jmena, ale principy jsou stale stejne, jen skocily o nejaky rad "dolu", coz je super. Co podle me je painful, protoze pouzivam ruzne jazyky je, ze kazdy jazyk si pouziva jen urcity subset z pattern a sklada z nich svoji cestu jak delat async programovani (Java, Angluar, NodeJs, haskell, etc.), ale neni to jeste na takove urovni, jako se to zvlada na urovni asyn sluzeb(jejich architektur), neni to dost genericke a prave enterprise integration patterns (messaging pattern) jsou krasnou sbirkou toho, co vsechno je mozne a jak by (podle me) mela async implementace vypadat, plnou adopci techto pattern, tj. vyberu si sam vhodny model.
Tak to jen takovy maly hit do zajimaveho tematu po ranu...
Zobrazit příspěvky
