category: backend

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 »

06Feb

Laravel dockerben

A korábbiakban már láthattuk, hogy is tudunk apache alapú webszervert futtatni, azonban akadnak esetek, főleg ha a Laravel eszközkészletét vesszük figyelembe, mikor egy szimpla webszervernél több kell, vegyük csak a workereket, scheduled jobokat. A docker alapvetően egy process-t (és azokat, amiket az spawnolt) tud futtatni és addig tart egy konténer futása, amíg a process tart, ennélfogva fontos, hogy az úgymond foreground fusson, tehát ne daemonként. Most nézzük meg, hogy is hívhatjuk segítségül a supervisord-t és indítsunk konténert cronnal workerekkel és futó apache-al! 

Tovább »

23Jan

SOAP, avagy 'Run you fools!'

Az eddigi cikkekben főleg a RESTful irányába mentünk el, ami mostanában elterjedőben van, viszont óhatatlan, hogy az ember belefusson a jó öreg SOAP-ba. Már volt róla szó, hogy hogy is néz ki mindez, viszont az még nem derült ki, hogy is tudunk ilyet létrehozni, valamint egy kliens se ártana, mert "jó" esetben mi inkább használni fogjuk ezeket, nem pedig szervert írni rá PHP-ben. Mindenesetre mindkét opcióról szót ejtünk majd. Na de zuhanjunk is neki, mert semmi se lesz belőle!

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 »

26Aug

Konstruáljunk Web API-t!

Amikor a legtöbben meghallják azt a rövidítést, hogy API, rendkívül különféle dolgokra asszociálnak. Van akinek a Java Persistence API jut eszébe, van akinek a Facebook API, míg másoknak valami teljesen más...api

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 »

17Dec

Scooter - Back it up

A biztonsági mentés és visszaállítás létfontosságú aki azt mondja, hogy nem, az fütyül és/vagy hazudik. A legtöbben saját kárukon tanulják meg mindezt, mikor is végleg oda lesz valamennyi adatuk.  Cikkünkben a backup módszereit tárgyaljuk ki és végignézünk pár eszközt is a területen.Coloradobrandtapedrive

Tovább »

13Oct

Martin papa színrelép - Az adataink

Az bizonyára köztudott, hogy manapság már nem weboldalakat, hanem webalkalmazásokat készítünk, azok mérete és komplexitása miatt. Ezzel a mérettel és komplexitással szinte egyenes arányban egyre bonyolultabb és hatalmasabb adatbázisok csücsülnek a háttérben. A módszer, hogy ezeket az adatokat hogy is érjük el, igen sokféle lehet. Régen, amikor még nem figyeltünk a kód struktúrájára, egy mysql függvény figyelt egy lekéréssel az index.php közepén, később már ezeket feldaraboltuk, netán kiszerveztük különféle fájlokba. Amikor viszont szóba jön az MVC, már mindenhol objektumokkal dobálózunk, akkor sokan eltévednek a nagy útvesztőben, hogy mégis mit és hova? pq2vg

Tovább »

25Aug

Controller és middleware a két jóbarát

Most, hogy a routingot tisztába tettük, nézzünk egy kicsit bele abba, hogy azokat a route-okat, amiket belőttünk miféle controllerekbe tudjuk belevezetni? Hiszen nem gondolhatjuk komolyan, hogy a kérések kezelésének logikáját a routes.php-ban írjuk meg, nemde? Főleg, hogy az MVC-ben ez lenne a controllerek dolga. Ezek általánosan az app/Http/Controllers mappába kerülnek.Xbox-360-S-Controller

Tovább »

02Aug

ZENDülés 1. rész - Skeleton application

Amikor az ember belekezd a webfejlesztésbe és már némileg túllépett a "Hello world!" szinten, akkor ahogy sorra ontja ki magásoap_client_zend_frameworkból a webalkalmazásokat, amiket autentikusan nulláról húz fel, akkor előbb - utóbb felfedez bizonyos ismétlődő részeket. Problémák/feladatok, melyekben szinte minden weboldala érintett. Ilyen lehet a jogosultság kezelés, a különböző támadások elleni védekezés, formok összeállítása, stb. A felismeréssel jó esetben rájövünk, hogy programjaink egyes részeit átemelhetnénk a következőbe, amit egy újabb probléma követ. Ugyanis ha az ember nem a modularitást szem előtt tartva fejleszt, akkor hajlamos "beledrótozni" mindent az adott metódusba/osztályba. Ekkor fejvakargatva refaktorálunk és a végén büszkén tekintünk a saját library-nk első komponensére. Ahogy telnek múlnak a hetek, egyre több és több modult emelünk át, míg végül egész szép kis gyüjtemény áll majd rendelkezésünkre, ami eszköztárat már-már keretrendszerként emlegethetünk. Azonban van ezzel egy kis baj... Ha valaki más be akar segíteni, akkor nincs egyszerű dolgunk, ugyanis mi nem dokumentáltuk a dolgot, nem teszteltük le az egyes komponenseket, így bizony el kell neki magyarázni hogy is épül fel a rendszer. Az ilyen problémákat képesek áthágni az ismert/jól dokumentált/tesztelt keretrendszerek. Ezeket emberek százai tesztelik/írják és a több szem többet lát elvet figyelembe véve, több hibát ki is purgáltak belőlük. Másrészt sokan használják öket, így az elsajátításukba feccölt idő sem elpazarolt, hiszen nem csak egy cégnél jelenthet ismeretük előnyt, a dokumentációról és a stackoverflow kérdés/válasz gyűjteményekről nem is beszélve. Ezért a következő lépés, hogy valamelyik ismert keretrendszert elsajátítsuk: Ebben segíthet ez a cikksorozat, ami a Zend Framwork 2 köré épül, ahol apránként végigvesszük a rendszer lényeges alkotóelemeit/lehetőségeit. Ezzel párhuzamosan fogok indítani egy Laravel 5-ös sorozatot is, mivel a Zend kevésbé elterjedt (habár mi azt használjuk).

Tovább »

01May

Húsvéti különkiadás - AMQP

Mivel vége lett az elmúlt hetek epikus hajtásának, ezért most fogom elkezdeni bepótolni a finomságokat, úgyhogy a napokban visszatér a már megszokott 2-3 poszt/hét tempó.rabbitmq

Ha már az egyik korábbi cikkemben kitárgyaltuk a vérnyulak szaporodási ciklusát, akkor most azünnepek alkalmából egy újabb nyulas cikket tálalnék. A hálózati kommunikáció különböző szabályokat, úgynevezett protokollokat követ. Ilyen protokoll a TCP, HTTP, SMTP, hogy soroljak pár ismertebbet. Mai témánk egy kevésbé ismert protokoll lesz, mégpedig az AMQP, azaz az advanced message queueing protocol.

Tovább »

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