category: architecture

28Oct

Inversion of layered architecture

Hosszú ideje nem volt már technikai jellegű bejegyzés a blogon, épp itt az ideje kicsit változtatni ezen. A cikket az egyik stackoverflow kérdésre adott válaszom ihlette, ahol megkaptam, hogy a kedvenc UML-emről igazán írhatnék valami cikket, ezt pedig megfogadom :) A legtöbben ismerjük az úgynevezett layered architektúrát, aminek a lényege az, hogy alkalmazásunkat több különböző rétegre bontjuk. Ezek a rétegek egymásra épülnek és a felhasználó, legyen az egy tényleges felhasználó vagy valami egyéb kliens, mindig a tetejével lép kapcsolatba. Na most a dependency inversion elve nem csak osztályokra értelmezhető, hanem ilyen modulokra is. Na de mégis hogyan?

Tovább »

18Feb

Circuit breaker, avagy mi van akkor, ha nem megy?

Amikor szoftvert írunk, akkor törekszünk arra, hogy bolondbiztos legyen. Amikor webre fejlesztünk sem történik ez másként. Minden tőlünk telhetőt megteszünk annak érdekében, hogy bizony a felhasználó mindig megkapja, amit akar, hiszen nekünk közvetve belőlük van pénzünk. Azonban akadnak olyan esetek, mikor külső tényezők is befolyásolhatják a szolgáltatást, amit nyújtunk? Akkor bizony tudni kell esni. Ahogy manapság egyre nő a microservice hype, egyre gyakrabban fogunk találkozni azzal, hogy bizony, ki kell hívni egy külső service felé, ami nem mindig végződik egy boldog 200-as válasszal. Cikkünkben a Circuit breaker patternről lesz szó és arról, hogy is segíthet ez nekünk, ha külső szolgáltatásokra épül az oldalunk.

Tovább »

19Dec

Konstruáljunk web API-t - 2. felvonás

Amikor az ember webről beszél, a legtöbb esetben színes weboldalakat képzel el, ezerféle közösségi platform belépéssel, ahol az ember minden mozzanatát lépésen tudják követni különböző módszerekkel, hogy a leginkább testreszabott élményt kapja. Ha bejelentkezünk egy oldalra, akkor a következő oldalbetöltéskor már az üdvözlő képernyő fogad, azt a hamis érzést keltve, hogy a weboldal tudja, hogy pontosan kik is vagyunk. Ez persze közel sem igaz, csupán a böngészőnk által küldött sütiben szerepel egy session ID, amivel azonosítanak bennünket és ezáltal hozzánk igazíthatják az oldal tartalmát. Ehhez viszont az kell, hogy a böngésző süti ide-oda közlekedjen a kérésekben/válaszokban. Azt már tudjuk régről, hogy a HTTP az egy ún. stateless protokoll, vagyis a két egymást követő lekérés közt nincs semmiféle kapcsolat, állapotváltozás. Ezt hivatott áthidalni az imént említett sütis megoldás. Azonban amikor REST webservicekről beszélünk, ott ez a sütis módszer nincs jelen. A korábbi példákban ez nem is okozott gondot, hiszen még nem volt szó arról, hogy ki mit is csinálhat az adott REST erőforrásokkal. Viszont mi a helyzet akkor, ha bizonyos műveleteket csak adott jogosultság mellett szeretnénk megengedni? Valamilyen formában tudtára kell adjuk a szervernek, hogy mégis kik vagyunk, ami alapján ő vagy végrehajtja az említett műveletet, vagy egy jól irányzott 401-es válasszal finoman elutasít bennünket. Ilyen műveletek lehetnek pl. azok, amikor törölni akarunk egy elemet, hozzá akarunk adni, módosítani, netán valakinek a privát dolgaiba akarunk kutakodni. Cikkünkben belepillantást nyerünk abba, hogy mi is az OAuth2.0 protokoll és hogy segíthet nekünk a fentiekben, third party vagy épp a saját API-nk használatakor.

Tovább »

16Jul

She wants the DI

A SOLID sorozatunk utolsó része következik, ahol a Dependency Inversion Principle, röviden DIP lesz terítéken. Alkalmazásunk felépítését tekintve többszintű hierarchiát képez. Ha megvizsgáljuk az osztályainkat és azok függőségeit, akkor egy faszerkezetet rajzolnak ki, ahol a fa gyökere felé haladva egyre magasabb és magasabb szintű osztályok következnek. tree-451x320Amikor tervezzük az alkalmazásainkat, a gyakorlat az, hogy először azokkal az alacsonyszintű osztályokkal kezdjük, amik az egyszerű műveleteket végzik, mint a lemezelérés, hálózati protokollok, stb. (Ezek lesznek a levelek) Ezután fogjuk ezek működését egységbe zárni magasabb szintű osztályainkba, ahol a komplex logika található (üzleti folyamatok, stb.). Ahogy a sorrendből is lehet rá következtetni, ez utóbbiak függnek az alacsony szintű osztályoktól. Ebből kifolyólag az előbbi elgondolás, miszerint a low-level osztályoktól a high-levelek felé haladunk a megvalósítás során. A probléma itt a flexibilitás lesz, ugyanis ha az egyik alacsonyszintű osztályt le kell cserélni valahol, akkor meg vagyunk lőve, mert a magasabb szintű osztályainkat ennek implementációjára építettük.

Tovább »

03Jul

Betonozás 2. rész - OCP

Az előző cikkben elkezdtük tárgyalni a SOLID elveket. Az SRP-t ki is végeztük, így jöjjön a SOLID második pillére az OCP, azaz az open-closed principle, ami annyit tesz, hogy "open for extension, closed for modification", tehát a cél az lenne, hogy úgy tudjuk bővíteni az adott kódrészt (modul, osztály, csomag), hogy nem kell reflectionnel szétgányolnunk az egészet belenyúlnunk a forrásába. surgery in a operating room.

Tovább »

27Jun

A szilárd alapok

Sok minden szóbakerült már a blogon, viszont egy igen fontos részt kihagytam, vagy csak érintőlegesen volt szó róla. Nem is biztos, hogy valaha direktben megkérdezik azt valakitől, hogy pontosan mit is takar a S.O.L.I.D., vagy éppen mit jelentenek az egyes rövidítések, ellenben előbb-utóbb az ember maga is elkezdi alkalmazni a legtöbb szabályt, amiről a cikkben szó lesz.contentItem-3770797-22619864-m2hitxryp7wup-or

Tovább »

17Apr

Eureka!

Az elmúlt pár cikkben igyekeztem meglovagolni én is azt a hype-ot, ami a microservice architektúrával kapcsolatos, de eddig eléggé elméleti megközelítése volt a dolgoknak, így gondoltam most kicsit váltok és egy saját kis példát dobok össze, hogy szemléltessem a dolgot. Amire a cikkben lévő példához szükség lesz:

  • docker (erről itt olvashattok)
  • némi kakaó a gépben, amin csináljátok, mert pár szolgáltatást feldobunk rá (nem, most nem AWS példa lesz, de igény szerint majd csinálok azt is), név szerint egy Eureka fog futni, 3x3 darab egyszerűbb Node alkalmazás, 3 key-value store, meg 3 MySQL (sima, nem cluster).
  • Node és npm.
  • Egy shell, ahol fel tudod tolni a szükséges initial SQL szerkezetet és dummy tartalmat (vagy myadmin, ha az jobban tetszik :) )
  • Ha lusta vagy gépelni, akkor példakód letöltéséhez git :)
    microservices-aggregator-1024x528

    Forrás: http://blog.arungupta.me/microservice-design-patterns/

Tovább »

2014-2018 © Letscode.hu. Minden jog fenntartva. Build verzió: