Először is szeretném felhívni a figyelmet, hogy a címben jelzett versus idézőjelben van. A cikk pont arról szól, hogy az miért is van úgy írva.
Egy kedves ismerősömmel éppen a szegedi Networkshop 2017 konferenciáról visszafelé tartottunk Budapestre. Valamiről beszélgetni kellett, és igencsak jó téma került elő. A Symfony keretrendszerről kezdtünk beszélgetni, nem ismerte, de lelkes érdeklődő volt, sok-sok kérdéssel. Elmondtam neki mindent töviről hegyire. Elmondtam, hogy ez egy keretrendszer, ami azt jelenti, hogy telepítés után nem tud még semmit, magunknak kell megírni amit szeretnénk. Szóba került a Drupal is, tudja, hogy abban is otthon vagyok. Azt is elmondtam, hogy az meg egy tartalomkezelő, tehát már telepítés után is bőven van hova kattintgatni.
… És akkor feltette a nagy kérdést:
Hogyan lehet a Drupalt és a Symfonyt együtt használni, lehet-e egyáltalán keverni ezeket?
Már majdnem mondtam a standard választ, hogy hát az egyiket lehet telepíteni a másik alkönyvtárába, és akkor bizonyos URL-eket az egyik, a többit meg a másik fogja kiszolgálni. Persze ez nagyon messze van attól, hogy igazán egyszerre használjuk a kettőt. Ezt a fajta egymás mellett élést bármelyik két webes rendszerrel meg lehet tenni, teszem azt akár egy Rails-es alkalmazás és egy java SpringBoot-os alkalmazással is.
De …
… a Symfony és a Drupal ennél sokkal mélyebb integrációja is lehetséges, legalábbis akkor, ha Drupal alatt D8-at értünk. Kedves olvasó, van már ötleted, hogy mire akarok kilyukadni? Ha nincs, akkor mutatom a következő elképzelt „beszélgetést”:
– Hé, Te Symfony! Van ötleted, hogy a felhasználó milyen tartalmat kér most éppen rajtunk számon? Nesze, itt egy Request objektum, benne van az URL, a sütik, a böngésző típusa, és még vagy 28 millió másik dolog.
– Nekem aztán fogalmam sincs, itt egy 404-es Response objektum. Csak most, csak neked, nagy szeretettel.
– Hé, Te Drupal8! Neked csak van valami ötleted, hogy mit akarhat a user, ugye? Itt a Request objektum, tessék.
– Passz, fogalmam sincs. Tőlem is kapsz egy friss – ropogós, 404 Response-t.
– Na, te házilag barkácsolt FityfirityCMS, te már biztosan tudni fogod, hogy mit kér a user.
– Háááát biza`, ötletem az nekem sincs.
– Na jó, Laravel, utoljára téged még megkérdezlek! Neked már tényleg tudnod kéne, mi a fenét akarhat a user.
– Nekem van egy tippem, tessék itt egy Response. Van benne minden, HTTP fejlécek, tartalom, és még sok egyéb jóság. A változatosság kedvéért ez pont nem 404.
PSR-7
Amire utalni próbálok az a PSR-7 ereje. Arról van szó ugyanis, hogy okos emberek kitalálták, hogy legyen egy standard interfész, ami leír egy HTTP kérést és egy HTTP választ. És bármelyik rendszer, ami ezeket az interfészeket implementálja, az tud egymással érdemben kommunikálni, és el tudják dönteni egymás között például azt is, hogy egy adott kérést kinek kellene kiszolgálni. Erre volt egy példa, a fenti kis szösszenet.
Symfony HttpFoundation
A PSR-7 csak egy interface. A Symfony HttpFoundation pedig egy implementációja. Bár nem muszáj ezt használni, bárki újraimplementálhatja a PSR-7-et, csak éppen túl sok értelme nincs. Aki a saját kis keretrendszerét, tartalomkezelőjét, vagy akármilyen egyéb kis szkriptecskéjét úgy építi fel, hogy az a Symfony HttpFoundation-t használja a HTTP kérések és válaszok kezelésére, az alkalmas lesz becsatlakozni és együtt dolgozni minden olyan rendszerrel, ami hasonlóan tesz.
Nincs vége
A beszélgetésünk előtt is ismertem a PSR-7-et és a Symfony HttpFoundation-t, de ez a beszélgetés döbbentett rá ezek igazi erejére és hasznosságára. Ugyanis a történet nem áll meg ott, hogy URL alapján eldöntjük, hogy kinek kell kiszolgálni a kérést. A kooperáció ennél sokkal-sokkal komplexebb is lehet. El tudok képzelni például olyat, hogy a tartalmat a Drupal állítja elő, de az autentikációt a Symfony végzi. Majd az elkészült végleges Response válaszhoz, a saját kis fityfirity alkalmazásunk még hozzá tesz egy extra HTTP fejlécet, amiben a teljes tartalmat egy titkos kulccsal még aláírja. Mi is hallottunk már a HTTPS-ről, de tegyük most fel, hogy az nem elég, annál többet akarunk. És az egész elé még bedobunk egy gyors user sapce reverse proxy-t, amivel gyönyörűen felturbózzuk az alkalmazásunk sebességét. És mindezt okosan, tartalom és user függő módon, nem vagyunk kénytelenek kizárólag az URL-re és az időre hagyatkozni a gyorstárazható-e vagy sem kérdés eldöntésekor.
Összegezve tehát a PSR-7 szabvány és annak implementációja, a HttpFoundation segítségével képesek vagyunk arra, hogy egymástól független, akár egymásról nem is tudó alkalmazások összedolgozzanak azon, hogy a felhasználó által indított HTTP kérésre megszülessen egy válasz. A lehetőségek tárháza ezzel igencsak kitárul. Annak oka, hogy ez nincsen széles körben kihasználva, véleményem szerint mindössze azért van, mert a keretrendszerek és tartalomkezelő rendszerek önmagukban is elég eszközkészletet adnak ahhoz, az átlagos igényeket kielégítsék. De biztosan van olyan eset, amikor erre szükség lehet. Nekem például eszembe is jutott egy alkalmazási lehetőség, amire a Sztakiban biztosan lenne igény. De ez már egy másik mese.
További olvasnivaló:
Pontosan 1 évvel ezelőtt, 2013. április 22.-én kezdtem dolgozni az MTA Sztaki-ban. Magam sem gondoltam volna, hogy eddig húzom egy helyen :) De maradtam, mert jól érzem magam. Az elmúlt egy év sok különböző érdekes feladatot és számomra még ismeretlen technológiát tartogatott, így bőven volt kihívás és szakmai előrelépés is. Egyszóval mozgalmas év volt. 
Nem tudom Ti hogy vagytok vele, de nekem bizony majd minden napra jut valamilyen használt eszköznek a verzió frissítése. Ez legtöbbször Drupal-t jelent, de van amikor Awstats-ot, phpMyAdmin-t, valami webmail scriptet, stb … 
