Sziasztok!
Nem vagyok biztos benne, hogy el e meg a forum annyira, hogy egy ilyen jellegu kezdemenyezesnek legyen lathato eredmenye. De egy probat meger. Eleg regen jartam mar en is erre, de a mai nap folyaman raneztem a TrinityCore forumara es egy egesz erdekes projektre bukkantam:
https://github.com/ShinDarth/TC-JSON-API (kesobb reszletezem)
Mar regota gondolkozok azon, hogy mind az adatbazis muveleteknek kellene adni egy plussz reteget, mind a szerverek uzemeltetesere jo lenne egy alkalmazas, ami leegyszerusiti, plussz ellenorzeseket tesz es megkonnyiti a munkat a nagy mennyisegu adaton. Ezalatt konkretan egy feluletre gondolok, amin keresztul egyszeruen lehet rutin es nem rutin muveleteket vegezni.
Mar szuletett sok projekt, amelyek egy egy folyamat megkonnyiteset celoztak meg, valamilyen alkalmazassal - pl. NPC - k letrehozasara, ticketek olvasasa -, viszont ezek kulonbozo technologiakkal, mas mas minosegu munkaval ertek el ezt. En ezeket tartom erdemesnek egybeolvasztani egy webes alkalmazas kereten belul.
Ami nagyon hianyzott ebbol egy jol definialt API, amin keresztul elerhetok az adatbazisban tarolt adatok, autentikacio, egyeb funkcionalitas. A fenti link alapjan ugy tunik mar nincs olyan messze, sot, a szukseges funkcionalitasnak egy resze elerheto. Ez elegge jo alapot ad az olyan elkepzeleseknek, mint amilyenrol fentebb irtam.
A forumra azert irtam, hatha akadnak meg itt olyanok, akik adnanak a dologba, akar otletekkel, akar technologiai javaslatokkal, velemennyel. Magamtol meg azt sem sikerult felmernem, hogy van e igeny egy ilyen alkalmazasra. Azt latom, hogy sok kis apro program mar szuletett es pont emiatt ugy is hiszem, hogy ezek alkothatnanak egy egyseget, egy minoseget es feluletet.
A megvalositas kerdeset is nyitva hagyom, en szemely szerint a webre mint platformra szannam a cuccot, illetve single - page application - kent valositanam meg. Akar meg arra is vevo vagyok, hogy szetbontsuk az egeszet microservice - ekre, amelyek mint komponensek epulnek bele az alkalmazasba, de ez komplexitasfuggo. (Az API reven erre is lehetoseg van)
A fenti megvalositas mellett az ervem az az, hogy megerett mar a web arra a szintre (mar korabban is, viszont most open-source eszkozokre gondolok), amivel egy ilyen kaliberu projektet kivitelezni lehet.
Azt mindenkeppen nyomatekositani szeretnem, hogy webes alkalmazas alatt nem HTML kod faragasara gondolok, vannak mar hasznalhato keretrendszerek, fejlesztoi eszkozok, stb., amelyekkel egy komoly szoftvert lehet alkotni.
A single - page application mellett pedig az szol, hogy nem weboldalt szeretnek faragni, hanem egy alkalmazast. De ezekrol is tartom, hogy kerdesek, amelyeket a topic - ban megvitathatunk.
Varom a hozzaszolasokat,
Shyro
Nem sok értelmét látom a dolognak, mert:
1.
- Webes felületnek ott a PHPmyadmin tökéletes a feladatra, úgy ahogy secure is de ezt egy .htaccess-el el lehet intézni biztosra.
2.
- Aki tényleg komolyan neki kezd a DB foltozgatásának az inkább használjon valami DB kezelőt ahol el lehet menteni a scripteket. / Smart_AI editorból pedig nagyon jók vannak már most is.
@eztcsekk:
A phpMyAdmin teljesen mas feladatkor megoldasara alkalmas, bar en arra sem szivesen hasznalnam. Nem adatbazis, tablak karbantartasara, vagy lekerdezesek futtatasara szeretnek alkalmazast, ezekre megvannak a megfelelo eszkozok.
Azok az eszkozok amik mar megszulettek (pl. a smart_ai szerkeszto, amit emlitettel) egy egy feladatot oldanak meg. Akkor nekem, mint szerver uzemeltetonek ha szuksegem van mindre, akkor telepitsek/toltsek le/huzzak fel N darab programot, amik akar teljesen eltero technologiara epultek? Nekem ez nem tunik hatekony megoldasnak, foleg, hogy a jelenlegi eszkozok kozel sem fedik le azt a mennyisegu feladatot, amit erdemes lenne (szerintem) kiszervezi egy alkalmazasba. Pedig, mint Trinity Utilities mar jo par eszkoz letezik RBAC Manager - tol kezdve a Ticket Viewer - ig. Ezeket mind masok, maskepp tartjak karban, vannak amelyekre mar ra se neznek, nem kovetik a valtozasokat. Meg ha adott feladatot meg is oldanank, adott szerver uzemeltetonek nem nyujtanak egy kenyelmes, egyseges megoldast.
En siman el tudom kepzelni a kovetkezo forgatokonyvet is: Szeretnem elolvasni a felgyulelmett ticket - eket, lehet hogy tobb szaz van, szeretnek bennuk keresni, osztalyozni oket, szeretnem atruhazni vagy kiosztani masokra a ticket - ek kezeleset, akar a ticket - et kuldo jatekos adatait, vagy a rola keszult logot szeretnem megtekinteni. Mar egy ilyen egyszeru dolognal is a lehetosegek szama rengeteg, hogy mennyi funkcionalitasra lehet szukseg.
Jelenleg ezt vagy nem tudom megoldani, vagy a DB - ben kell turkalnom vagy bejelentkeznem a jatekba, amelyek kozel sem jo megoldasok, sot, nem is megoldasok, csak valami ad hoc reagalas.
Nem tudnam osszeirni az osszes forgatokonyvet, ami egy megfelelo eszkoz eseten kialakulhat, mert nincs ilyen eszkoz, de el tudnek kepzelni egy olyan projektet, ami megprobal ezekre egy egyseges megoldast nyujtani.
Itt egy osszefoglalo a TrinityCore - s Rest API - rol, ami az aktualis allapotot tukrozi:
http://community.trinitycore.org/topic/11350-trinitycore-json-restful-api/?do=findComment&comment=75903 (http://community.trinitycore.org/topic/11350-trinitycore-json-restful-api/?do=findComment&comment=75903)
Korrekt amiket terveznek, illetve ok is hasonlokeppen kepzelik felhasznalni az API - t.
Irtak nehany single - page application - t AngularJS - ben. Meg nem neztem meg oket, de jol peldak es kiindulopontok arra, amire en is gondolok.
Ha jól értelmezem akkor egy olyan API-t akarsz amin keresztül mindent lehet kezelni ami DB-n keresztül lehetséges vagy esetleg bizonyos dolgokat már az API kezelnél az emu helyet ? Amúgy egy jó ötlet csak nem hiszem, hogy itt Mo-n lesz elég támogatásod, meg lehet jó lenne ennek Shin-nek felvetni az ötletet és együtt vinnétek a dolgokat tovább.
@AximCore:
Igen, az API - n Shin dolgozik, annak fejlesztesehez is elkel a segitseg. Azt fejlesztgetni sem egy rossz dolog, viszont amire en gondolok az az API felhasznalasa. Ok elso sorban arra gondoltak, hogy az API altal sok kis alkalmazasnak biztosithatnak egyseges feluletet a DB - ben tarolt adatok lekerdezesere/szerkesztesere/torlesere es kiegeszitesere. Innentol kezdve, ha van egy ilyen reteged az adatbazis felett azt kezdesz vele amit akarsz.
A fenti peldara ("forgatokonyvre") visszaterve, a ticketeket lekerdezheted az API - n keresztul, de attol meg nyilvan nem fogod tudni oket konnyebben feldolgozni. Viszont irhatsz ra egy sajat alkalmazast, ami kepes a ticketeket osztalyozni (critical/minor/major/stb.), vagy egy egy GameMaster - nek kiosztani (ahogy egy issue - t is bitbucket - en), hogy o foglalkozzon vele. Meg sorolhatnam. A lenyeg, hogy ezek a plussz funkcionalitasok nem az emulator felelossegi kore, nem is az API - e, hanem ez egy alkalmazasae, amivel megkonnyitheted a munkad.
Raneztem az eddigi API - t hasznalo alkalmazasokra, es kiindulopontnak jok, de en egy kicsit tovabb mennek. Ugy gondolom, hogy ez nem egy kitaposott osveny, amire viszont megfelelo kinalat eseten lenne igeny.
Teny, hogy nem erkezett sok visszajelzes a temahoz, de en sem sietek. Ebbol meg nem lesz holnapra semmi, sot, jovohetre sem. En is meg csak emesztem a dolgot es figyelemmel kovetem az esemenyeket. Az API sem tart meg abban a fazisban. TC foruman is kerdezoskodok, gondoltam itt is, hatha lesz belole valami erdekes, de az is lehet, hogy nem. Viszont sem baj, mert nincs tetje a dolognak. :)
Belenéztetek ti egyáltalán ebbe a kódba?
Részlet:
Route::get('/dbc/areas_and_zones/{id}', function($id) {
if (isset($_GET['version']) && $_GET['version'] == 6)
$results = DB::connection('sqlite')->select("SELECT * FROM areas_and_zones_wod WHERE m_ID = ?", [$id]);
else
$results = DB::connection('sqlite')->select("SELECT * FROM areas_and_zones_wotlk WHERE m_ID = ?", [$id]);
return Response::json($results);
})
->where('id', '[0-9]+');
1-2000 sort írtak eddig ebből, és támogat 2 verziót, ha bejönne egy 3. verzió akkor jöhet hozzá még 1000 sor...
Lehet ilyet írogatni, de ez így gépiró gyakorlat és amennyi idő erre elment inkább a Core és a DB fejlesztésére kellet volna forditani. Ha meg tényleg ilyen API-t akkar az ember csinálni csinálja rendesen.
- Minden egyes sorban lekérdezi a (isset($_GET['version']) && $_GET['version'] == 6)-t? Miért? Nem elég egyszer, ha már API? És inkább a function-be rakom bele.
PL.: function($id,$version)
- Ez fáj nekem legjobban (areas_and_zones_wod / areas_and_zones_wotlk) és ha nekem cataclysm kell?
Akkor írjak bele egy elseif-et az egészbe? Erre van egy értelmes megoldás a DB szerkezeteket egyszer inicializálom egy ARRAY-be.
Pl.:
areas_and_zones_[$version]
- Meg hát úgy az egészet meg lehetne írni 1/3 ennyi sorból, és később felhasználható lehetne akár más projectekhez is. Ez most csak a TC-hez jó ott is 2 verzióhoz és csak addig amíg a TC nem változtat a DB szerkezeten mert utána kinszenvedés jön!
Egy szó mint száz, ha már ilyen szvsz felesleges dolgot csinál valaki, akkor a minőségre adjon legalább és akkor tanul is belőle valamit.
DB szerkesztésre pedig PHPmyadmin-t vagy mondjuk Navicat-ot esetleg SQL_YOG-ot ajánlok. Smart_AI-hoz pedig valamelyik Smart_AI editort.
Update:
- A LUA scriptes TC mod is ezért halt meg mert hiába a LUA ha csak azt tudja kezelni amihez megírták a szorgos kezek az implementációt, ezzel egy csomó fölösleges dolgot tudd csinálni, de a Spell System-et ahol lehetne hasznát venni azt pont nem.
@eztcsekk:
Megertem a koddal kapcsolatos aggodalmaidat, en is sok kivetnivalot talaltam benne. Viszont ugy gondolom, hogy ez a kezdemenyezes ertekebol nem vesz el, nem is tesz hozza, nem befolyasolja. Maga a projekt meg olyan fazisban tart, mind kodmennyiseg, mind hasznaltsag teren, hogy konnyen lehet refaktoralni, akar teljesen ujrairni, urjagondolni az API - t. Meg komolyabb atalakitasokkal sem fogsz eltorni semmit, mert szinte senki sem hasznalja meg. Szimplan csak be kell kapcsolodni, refaktoralni es bekuldeni a modistasaid. Nem erzem azt, hogy a kod jelenlegi allapota megakadalyozna azt, hogy idovel jobb kod szulessen.
En tudok olyan projektrol, ahol az API - t annyian hasznaljak, hogy egy fuggvenyt sem irhatsz at, mert azzal mar eltorsz rengeteg mindent, szinte csak uj endpoint - okat vehetsz fel, az ujrairasa pedig annyi idot es energiat emesztene fel, hogy nem vallalkoznak ra Ezzel szemben itt nem fenyeget ez a veszely, szabad a palya.
Felreertes ne essek, nem isteniteni akarom a projektet, de ha ilyesmit felronank minden uj projektnek, akkor talan TrinityCore se lenne. A dolog ott kezd erdekesse vallni, amikor az emberek beszallnak es elkezdenek commit - olni, mert ugy gondoljak, hogy erdemes a dologgal foglalkozni. Ugy gondolom, hogy most eppen ez elott tartunk. Az, hogy az adott projektbol lesz e valami, inkabb mulik az utobbin, mint a jelenlegi kodminosegen. Azon mindig lehet javitani.
Azt, hogy nem latsz benne fantaziat, azzal semmi gond. Nem keltheti fel mindenkinek az erdeklodeset ugyan az a dolog.
A DB szerkeszteses dolgot pedig meg mindig nem tudom hova tenni, en speciel nem szeretnek azzal foglalkozni. Az meg az en erdeklodesemet nem kelti fel. :)
Fantázia van a dologban én nem a dolog ellen vagyok hanem a miként ellen.
Ahogy már sokszor mondtam a PHPmyadmin azért 100% használhatobb még mindig mert ott a teljes DB-t eléred, minden táblát minden mezőt, mindent.
Ebben az API-ban azt éred el amit a gyerek megad SELECT *-al, ez így nem jó. Max. 100 sorban meg lehet írni, hogy bármilyen DB bármelyik mezőjét le tudd kérni és mint API és akkor arra használod amire akarod a másik 100-200 sor pedig jogosultságok kezelésére.
Példa URI: ./api.php?db=creature_temp&row=all
./api.php?db=creature_temp&row=entry,name
...
@eztcsekk:
A mikenten szerintem lehet valtoztatni, azon mar kevesbe lehetne valtoztatni, ha teljesseggel a dolog ellen lennel.
A phpMyAdmin meg mindig egy adminisztrator felulet MySQL adatbazis kezelo rendszerhez, nem tobb (bar talan kevesebb), mint Oracle DB eseten az SQL Developer. Az API es amirol en beszeltem alkalmazas, az teljesen masrol szol, megha az implementacio felrevezeto is volt. Egy ilyen API epitesenek tobb celja is van, az elso es talan legfontosabb, hogy http(s) - en keresztul vegezhetsz barhonnan eroforraskezelest, megfelelo autentikacio mellett akar erzekeny adatokkal is. Milyen elonyokhoz juttat ez? Akar a felhoben (pl. heroku) tudsz futtatni egy teljesen elszaparalt alkalmazast, ami a neki szukseges eroforrasokat http(s) - en keresztul eri el, es nem foglalkozik azzal, hogy pl. a lekert adatok mikent allnak elo, nem marad az alkalmazas felelossegi kore. Ki tudsz szervezni altala funkcionalitast, ami nagyon sokat segit, akar az olyan esetekben is, amikor bonyolult SQL lekerdezesek megirasa helyett, csak kiadsz egy lekerdezest adott url - re. Arrol nem is beszelve, hogy ez nem egy remote access az adatbazis - kezelo rendszerhez, annal sokkal tobb is lehet. Egy jol levalaszthato reteget kepzel vele a nyers adatbazis felett (ami jelenleg meg nem valosult meg), ami tartalmazhat plussz ellenorzeseket, plussz optimalizalasokat (igenyekhez merten), jol tesztelhetove valik az eroforraseleres, akar biztonsagot is novelheted vele (persze csokkentheted is :)), teljesen komplex logikat emelhetsz ki bele az adatbazisbol, amiket az alkalmazasban sem szivesen implementalnal, sorolhatnam meg tovabb.
Ha egy alkalmazast szeretnel fejleszteni, mint en, egy ilyen reteg uj lehetoseget ad erre es megkonnyiti a munkad. Ezen felul ha valaki meg microservice - ekben is gondolkodik egy alkalmazason belul, az meg jobb, hiszen egyseges interface - t kapsz az adatok kezelesere minden microservice - nel, kiemelhetove valik a kod, szinten sorolhatnam.
Ezek mind olyan dolgok, amire a phpMyAdmin nem jo, mert nem erre talaltak ki, es koze sincs ehhez. En speciel regota varok hasonlo kezdemenyezesre. Szerver uzemelteteshez szukseges eszkozok teren meg nem sokat tud felmutatni az open source kozosseg. Amit ettol a projekttol varok az az, hogy ennek egy uj lenduletet ad.
Az olvasottak alapján, úgy gondolom, hogy ez egy igen jó kezdeményezés lehet. Bár így nem tudnám megmondani, hogy ez valójában mennyit könnyíteni a szerverkészítők dolgán, de nekem tetszik az ötlet. ;D
Nyilvánvalóan a közös munka is sokkal jobban egyszerűsíthető lehetne ezzel, persze akkor már gondolni is kell a külön felhasználói felületre, hogy ez párhuzamosan működjön.
Az adatbázis kezelését ezzel tulajdonképpen úgy lehetne megkönnyíteni, hogy esetleg példákon keresztül illusztrálnánk részleteiben vagy egy kész SQL kódot (is) kapna hozzá a fejlesztő. Gondolok itt olyan egyszerűbb dolgokra is, mint pl. egy Quest, ahol mondjuk feltételként meglenne adva, hogy X creature-t öljön. Így mondjuk lehetne több általános Quest "sablont" létrehozni, amit egy-két kattintással, illetve mezőkitöltéssel meglehetne oldani.
Persze ezeket nyilván nem nehéz megoldani bármely SQL kezelő programban vagy épp a PHPMyAdmin-ban, de ha már egy ilyen alkalmazásban gondolkodunk, az legyen felhasználó- és fejlesztőbarát.
Azt nem tudom, hogy ezt Scriptelés szintjén hogyan tudnátok, vagy megtudnátok-e oldani, ugye itt gondolok arra, hogy egy Boss scriptelése jóval egyszerűbben megoldható lenne, nem igényelne programozói tudást, szimplán kezelési tapasztalat lenne hozzá szükséges. :)
Egyelőre ennyit tudok hozzászólni a dologhoz, várom a fejleményeket.
Most, hogy megneztem tuzetesebben a jelenlegi API - s projektet, igazat kell, hogy adjak @eztcsekk - nek. Nem vagyok egy nagy Laravel szakerto, de eros ketsegeim tamadtak azzal kapcsolatban, hogy egyatalan jol hasznaljak e ezt a keretrendszert. Lehetne refaktoralni, de az ujabb commit - ok alapjan erre nincs semmilyen torekves. Ez nalam egyet jelent, egyszeruen csak sajatot kellene irni.
En PHP/Ruby/JavaScript implementacion gondolkodok, esetleg van valakinek javaslata egyeb nyelvre, akar keretrendszerre? Hozzam a legkozelebb a JavaScript all es Koa.js, mint keretrendszer (http://koajs.com/ (http://koajs.com/)). Hamar eltudnek vele indulni, de ez nem jogos erv. Viszont az emlitet nyelvek szerintem mind bovelkednek eszkozokben, keretrendszerekben es alkalmasak egy API kialakitasara. Meg merem kockaztatni, hogy kozel mindegy, hogy melyiket valassza az ember. Viszont hatha valaki meg tud gyozni, hogy van a feladatra alkalmasabb nyelv, illetve PHP es Ruby eseten keretrendszer javaslat.
@Zolee:
Ennek pontosan ez a lenyege. A vegeredmeny ugy is az lesz, hogy SQL lekerdezesek fognak futni, valtozik az adat az adatbazisban. En ugy gondolom, hogy vannak olyan rutinfeladatok, amiket erdemes elrejteni es egy alkalmazassal megkonnyiteni a folyamatot. Pl. egy legordulo menubol sokkal konnyebb kivalasztani az NPCFLAG mezo erteket egy uj NPC letrehozasanal/modositasanal, ahol beszedes nevek vannak felsorolva (Gossip, Quest Giver, Trainer, ...), mint szamokat beirogatni egy SQL lekerdezesbe, es folyamatosan utananezni, hogy oda pontosan milyen ertek is kellene. A feladat megoldasanak szempontjabol senkit nem erdekel, hogy az adatbazisban milyen ertekkel es milyen absztrakcioval van megoldva egy NPC tarolasa. Az ilyen reszletekkel valo foglalkozas csak lassitja es fajdalmassa teszi a munkat. Ennek az orvoslasaval felgyorsulna a szerver uzemeltetes soran felmerulo problemak megoldasa, tobb ido maradna masra. Ez most pont egy olyan pelda, amire fel lehet hozni a phpMyAdmin - t, viszont a problema amit irtam ott is ugyanugy megmarad. Ezen felul meg rengeteg olyan funkciot eltudok kepzelni, aminek egy uj rekord beszurasahoz koze sincs, egyszeruen csak konnyiti a munkat es a phpMyAdmin szoba se johet a megoldasara.
Tovabba en a fentebb emlitett legordulo lista megjeleniteset az alkalmazas logikaba tennem, viszont az NPC letrehozasat egy API moge rejtenem, amit az alkalmazasom "mint egy fuggvenyt" csak meghivnam. Ez a koncepcio nekem ezert tetszik.
Én azt mondom, hogy ez az SQL API kuka kategória, egy sima PDO-t kell csinálni 3-4db függvénnyel, UPDATE,INSERT,REPLACE...
Minden mást pedig akkor kliens oldalon Javascript-ben. Az fontos lenne, hogy a program tudjon generálni SQL kodot amit bármikor le lehet futatni máskor is.
@eztcsekk:
Az az erzesem, hogy meg mindig elbeszelunk egymas mellett. A jobb megertes erdekeben felejtsuk el az adatbazisokat ugy ahogy vannak. Nincs SQL, nincs adatbazis - kezelo rendszer, nincs phpMyAdmin. Ezektol tekintsunk el. Legyen egy sima fajlunk, amiben JSON formatumban tarolunk adatot. Nyilvan atirogathatnank a fajlt kezzel, de legyen a fajl bazi nagy es jojjunk ra, hogy egy programmal tobb eselyunk van karbantartani azt. Ezt a fajlt betudjuk olvasni gond nelkul, de legyen erre egy kezelo osztalyunk, nevezzuk JSONFileHandler - nek. Ez most eleg altalanosan hangzik, de probaljunk meg eltekinteni a reszletektol. A JSONFileHandler - nek legyenek metodusai, amik altal kapunk egy letisztult, tesztelheto, ellenorzesekkel ellatott, meghivhato interface - t a JSON file - unk modositasara.
Mind a JSON fajl es a program, ami azt kezeli legyen egy A gepen, viszont szeretnenk elerni azt B geprol is. Nyilvan a JSON fajl es a program atmasolasa szoba se johet, hiszen mi a helyzet, ha a JSON fajl erzekeny adatokat is tartalmaz, amiket a JSONFileHandler szepen elfed, de a fajlok atmasolasaval az egeszet kidobhatnank a kukaba. Nem is szolgalhatjuk ki se FTP - n, se natur HTTP(S)- n keresztul a JSON fajlunkat, mert akkor ugyanott tartanank.
Ennek a megoldasara johet szoba egy Restful API, amivel az A gepen levo JSON fajlt, a JSONFileHandler funkcionalitasan keresztul ki tudod szolgalni a B gep szamara. Az, hogy a B gepen mit tudsz kezdeni a JSON fajllal, azt az API hatarozza meg. Azert van szukseg egy jol definialt API - ra, hogy a B gepen is futtathass egy alkalmazast, ami az API -n keresztul eri el az eroforrast, aminek az alapja a JSON fajl. Azert probaltam meg igy elmagyarazni, hogy erzekeltessem a retegek kozotti kulonbseget.
Nyilvan felmerul benned, hogy miert akarom elerni a JSON fajlt egy masik gepen? Ugyan azert, amiert nem telepitesz fel egy Gmail programot a gepedre, amin keresztul levelezel, hanem megnyitod a bongeszod es hasznalod a szolgaltatast. Ugyan azert, amiert mukodik a web mint platform.
Kovetkezo kerdes pedig lehet az, hogy mi legyen az az alkalmazas, ami a B gepen fut. Es itt jon a lenyeg, nem egy SQL generator vagy egy adatbazist kezelo felulet. Ezeket mind felejtsuk el. Az lehet barmilyen alkalmazas, ami nagyban epit egy API - ra, amin keresztul a szamara szukseges eroforrasokat eleri. Ezt a legfontosabb fontos kiemelni, hogy az API nem a felhasznalokat szolgalja ki, hanem az alkalmazasokat.
Amit javasoltal megoldas az pontosan amiatt nem jo, hogy nem ezt, hanem teljesen mast old meg.
Valóban elbeszélünk egymás mellet, mert te Általánoságban beszélsz, én pedig ennek rendszernek a megvalósithatóságáról.
Szóval jelenleg egy Stock TC-ben 163 World 89 Char és 13 Auth tábla van. Ez összesen 265db tábla és amiben van olyan ~2000 unique key.
RESTfull API-ra pedig itt nincs szükség mert az adatbázis ismert, márpedig a RESTfull API egyik alap ötlete, hogy a DB Layer-t rejtsük el || tegyük egyszerüen kezelhetővé.
Mivel az adatbázis szerkezete ismert kliens oldalon is ezért nem látom értelmét szerver oldalon tovább bonyolitani, mint egy jól használható Parser a JS kódból jövő JSON-hoz.
A Kliens oldal így se lesz egyszerű, de elég lesz neki megtanitani a mezőket illetve, ha egymező fix értékeket vehet fel akkor az értékekhez tartozó jelentést.
Az elmult napokban ugye felvetettem ezt a temat, de bennem is csak idovel kezdett pontosabban megfogalmazodni, hogy mit is szeretnek. Ezert lehetseges, hogy nem volt annyira vilagos a kezdemenyezes, mint ahogy szerettem volna. Ezert szeretnek irni egy osszefoglalot, hogy mire is gondolok pontosan.
Esettanulmany:Mielott barmi szo esne a viziorol mutatnek egy peldat, ahol hasonlo API - t alakitottak ki, mint amire en is gondolok, es a felhasznalasa is hasonlokeppen tortenik, mint amire en is gondolok. Ez egy eszkoz, megpedig a Docker (https://docs.docker.com/). Aki meg nem hasznalta az egy minimalis koltsegu virtualis gepkent tekinthet ra (mielott barki megkovezne erte, a Docker eseten nem beszelhetunk virtualizaciorol, de igy konyebb elkepzelni). Az eszkoz segitsegevel tudsz a kulvilagtol (host) teljesen izolalt kornyezetet, container - eket letrehozni. En peldaul kulonbozo nyelvekben irt programok tesztelesere hasznalom, igy nem kell a host gepre feltelepitenem 10 darab futtato kornyezetet, forditot. Ugy tudok haskell es javascript kodokat is tesztelni egyszerre, hogy a host gepemre nincs felteve se Node.js se Haskell fordito. Ezt a szerepet is kezdi kinoni, es egy teljes szoftvercsalad epul kore, meg tobb lehetoseggel.
Van egy CLI - je, amivel tudsz tobbek kozott container - eket letrehozni:
docker run -i -t ubuntu /bin/bashA parancs vegrehajtasa igazabol a Docker daemon - nek fog szolni, ami figyel a hatterben es ha kell vegrehajtja a parancs altal kiadott feladatot. A Docker csapat ennek a Docker daemon - nak adott egy API (https://docs.docker.com/reference/api/docker_remote_api_v1.20/)- t is, ami rengeteg mindent ad:
- Az osszes funkcionalitas, ami a CLI - ben megtalalhato, elerheto az API - n keresztul is
- Sokkal konyebben valik programozhatova a Docker menedzselese
- A Docker - t tavolrol is el lehet erni es akar egy masik gepen futo szoftver is vezerelheti
- Szinte teljesen mindegy, hogy milyen nyelven programozol, az API - t meg fogod tudni szolitani barmely nyelvben
- etc...
En pl. nem voltam elegedett a NPM package - ekkel, amiket eddig irtak a Docker vezerlesehez az API - n keresztul, ezert elkezdtem egy sajat package - en dolgozni, amiben egy Docker container letrehozasa mar csak igy nez ki:
var container = new Container('image_name');
container.run({ ...options... }).then((output, error) => ...);Azt, hogy ilyen egyszeruen, ennyire programozhatova valt a Docker, akar Node.js - en futo JavaScript alkalmazas szamara, az az API - nak koszonheto. Ha nem lenne az API, az, hogy ez a kod egy masik gepen fusson elkepzelhetetlen lenne, illetve teljesen mas megoldasra lenne szukseg (string - konkatenalgatasa egy exec() fuggveny szamara, hogy parancsokat futtassunk).
Ami meg szinten szepen latszik ebbol a peldabol az az, hogy a Docker ugyanugy tarol adatokat, viszont arrol, hogy miket, hogyan es miert, neked mint felhasznalonak (CLI) es mint programozonak (API) fogalmad sincs. Mert nincs is ra szukseged. Eleg baj lenne, hogyha egy container letrehozasanal azzal kellene foglalkoznom, hogy milyen fajlokat kell atirnom, vagy kicsit a jelen esetunkre visszakanyarodva, milyen SQL lekerdezeseket kellene kiadnom.
Vizio:Egy, a TrinityCore - hoz irt API minimum ugyanezeket tenne lehetove, mint amiket a Docker eseten felsoroltam. Az, hogy en ezt mikent hasznalnam fel, azt mar az eddigi posztokban probaltam reszletezni, de fussunk neki meg egyszer. Egy API a TDB felett lehetove tenne azt, hogy barmely nyelven irj programokat, amelyek - addig amig van internet kapcsolatod - barhol futhatnak. A barmely nyelven irt, barhol futo program nem tudom elegge nyomatekositani, hogy mennyire eros erv. Aki alkalmazast szeretne irni a TrinityCore - hoz, az onnantol kezdve, hogy ki tud kuldeni egy HTTPS kerest es ossze tud allitani egy JSON - t, nyert ugye van.
Ez a megoldas azt is lehetove tenne, hogy adott szerveren jatszo jatekos sajat maganak irhatna egy mini alkalmazast, amivel a sajat karakterenek aktualis adatait lekerdezi, vagy a szerver publikus adatait. Kerdes, miert irna valaki ilyet? Csak egy pelda akart lenni.
Egy JavaScript - hez irt SDK - val (itt csak egy wrapper osztalykonyvtarra gondolok a keresek fole), egy single - page application alkalmazasban, peldaul egy uj karakter letrehozasa idaig egyszerusodne:
...
CharacterManager.createCharacter({ ...options... });
...(Az alkalmazas adja a logikat, hogy mikor hozol letre uj karaktert, az SDK adja a CharacterManager osztalyt es a keres kikuldesenek logikajat, az API adja az uj karakter letrehozasanak lehetoseget es biztositja, hogy adott SQL lekerdezes lefusson. Az alkalmazasodnak goze sincs, hogy a karakter mikent jon letre es nem is kell tudnia. Az alkalmazas irojanak az SDK - t kell ismernie, es tudnia hasznalnia es az alkalmazas logikara koncentralnia. Csak ezzel egyszerusodhet az alkalmazasfejlesztes.)Ennek a megvalositasa jelenleg elkepzelhetetlen. Ilyen alkalmazasok jelenleg nincsenek. Minden alkalmazas ami eddig szuletett vagy a host gepen fut, vagy PHP altal van kiszolgalva es kozvetlenul buzeralja az adatbazist. Az, hogy nem csinal e valami baromsagot az az alkalmazas irojatol fugg.
Mar rengeteg helyen lattam ilyen megoldast (Facebook API, etc...), a Docker csak 1 pelda a sok kozul. Lattam is mar ilyen megvalositast, sokkal de sokkal tobb adattal az adatbazisban, sokkal bonyolultabb szituacioban. Jol mukodik, kivitelezheto, es a vegeredmeny a konnyu alkalmazasfejlesztes. Ahhoz, hogy TrinityCore - hoz normalis alkalmazasok szulethessenek, szerintem erre van szukseg.
Ez az bonyolitsuk még tovább, nem használhatunk Docker-t vagy akármilyen cél programot, mert a PHP+Mysql minden szerveren elérhető, ezt kell használni.
Ha egy valamit biztosan nem lehetne API-n keresztül csinálni az a Karakter generálás, hogy ezt meg lehesen csinálni az API-t a Trinity Cora-ba kéne implementálni.
Ezt mondom, ez egy konkrét rendszer ismert ne áltlánositsd!, a Character DB-be például nagyon minimálisan lehet belenyulkálni, mert az aktív részét a Core a memóriába tárolja, amit nem lehet:
- Item adás bárhogyan, ezzel a levél küldés is kilőve.
- Guildek modositása bárhogyan.
- Online karakternél a teljes character tábla modositása, ha Offline akkor lehet.
Jó lenne ha nem általánositanál tovább ez itt a Trinity Core a DB ismert, a müködése ismert a probléma adott:
- Questek szerkesztése egyszerübben.
- Smart AI készitése.
- Creature és Gameobject-ek szerkesztése.
- Loot-ok kezelése (creature,gameobject,reference,item,spell)
- Conditionok készitése
- Spell Proc Eventek kezelése
- Game Event táblák kezelése.
Ha ezt a 7 dolgot már tudja a program gyakorlatban is kliens oldalon akkor lehet tovább lépni.
Egyszeruen nem tudom hova tenni azt, amirol beszelsz. Nincs koze ahhoz, amit irtam. A peldakat amiket meg emlitettem azok egyszeruen peldak, nem kell beloluk hibas kovetkeztetest levonni. Internal tablakat meg nyilvan nem szeretnek felulirni, de olyan adatokat nincs is ertelme nyilvanossa tenni. Azt meg nyilvan figyelembe kell venni, hogy az adatbazisban tortent valtozasokat a Core mikent, mikor es egyatalan fogja e figyelembe venni. A TrinityCore - nak es az API - nak nem kell tudniuk egymasrol, annyi a kozos bennuk, hogy egy adatbazison dolgoznak. De mint mondtam, nem szeretnek alkalmazasbol karaktert letrehozni, az egy pelda volt. Irhattam volna ItemManager.create() - t is, a mondandom szempontjabol teljesen mindegy volt.
Illetve, amiket felsoroltal:
Idéz- Questek szerkesztése egyszerübben.
- Smart AI készitése.
- Creature és Gameobject-ek szerkesztése.
- Loot-ok kezelése (creature,gameobject,reference,item,spell)
- Conditionok készitése
- Spell Proc Eventek kezelése
- Game Event táblák kezelése.
...ezekkel meg nem akarok foglalkozni. Mar leirtam tobbszor, hogy nem akarok adatbazis szerkeszto alkalmazast kesziteni. Nem ertem, hogy miert nem lehet ettol eltekinteni.
Igazad van ötletem sincs mit is akkarsz fejleszteni.
De inkább becommitolom a gyerek TC-s PHP API-jába a módositásokat.
https://github.com/Plexis/Wowlib ezt probaltad mar?
igaz 3 eve nem volt updatelve, de picit jobban nez ki mint pistike elso wowos account managere :)
nem sokaig tart kiboviteni..
a kerdes hogy erdemes -e ezzel szenvedni, van-e eleg hely a piacon?
Ne erts felre de 8-9 evvel ezelott jo kis gondolat lett volna.. :) de most mar inkabb azt latjuk, hogy egyre kevesebb ember foglalkozik ezzel, kevesebb ember jatszik, egyre nehezebb kovetni az uj wow kiegeszitoket..
@Zoltan
Meg nem lattam, de koszi, hogy linkelted. Nekem egy sima wrapper/helper library - nak tunik az adatbazis fole, ami nem rossz, de az, hogy 3 eve latott utoljara commit - ot az tenyleg kiabrandito. Az elozo beszelgeteseknek annyi ertelme mindenkeppen volt, hogy az megfogalmazodott bennem, hogy a fuggosegeket erdemes minimalisan tartani. Ennek az eredmenye lett az, hogy erdemes lenne egy sajat API - t implementalni es azt tisztessegesen megirni/karbantartani. Az azt hasznalo alkalmazasokat pedig csak utana.
Nem erzem szenvedesnek a dolgot, mert erdekel a tema. Az sem zavar, ha senki nem fogja hasznalni. Nyilvan azt fel lehet hozni, hogy fordithatnam masra az idoben, ami esetleg meg penzben is megterul, ilyesmi. De ez nalam az n + 1. hobbi szintu elfoglaltsag, ami meg belefer ugy erzem. Ha esetleg megis felkapottabb lenne a dolog, mint aminek most tunik, akkor meg novelni kell a prioritasat a projektnek. Csak agilisan. :)
Most egy ideje nem irtam a forum - ra, de az nem azt jelenti, hogy ennyi volt. Mivel innen nem kaptam meg visszajelzest a nyelvek/technologiak teren, ezert magam kezdtem el utanajarni. Elso sorban Ruby - val kezdtem el ismerkedni, End-to-End tesztelesnel kerult a kepbe, ugyanis a JavaScript - es eszkozok nem voltak tul meggyozoek. (watir/cucumber/rspec kombinacio eddig meggyozott) Tovabbra is opcio a nyelv, framework/library (elnezest, gem - ek) meg van dogivel hozza. PHP - rol is erdeklodtem, ott a Laravel tenyleg jo. JavaScript nalam meg adott, ott kezdtem el korbenezni eszkozok teren, szinten van mire epiteni.
Az API - nak szerintem ket sarkalatos pontja van. Az egyik, hogy a DB felett egy olyan reteg legyen, ami azert elkapja a hibas adatokat, ne nagyon engedje szetbaszni az adatbazist, mar elnezest. Illetve az autentikacio es a biztonsag. Ezek mar leragott csontok, nem is akarom ujrafeltalalni a kereket, de ket kattintassal se letudni a dolgot. Ezeknek ugy erzem, hogy erdemes utanajarni, rengeteg jo anyag van arrol, hogy hogy is erdemes ezt csinalni, az pedig ido. Igy jelenleg itt tartunk.
Idézetet írta: Shyro Dátum 2015 október 15, 12:22:16 DÉLELŐTT
@Zoltan
Meg nem lattam, de koszi, hogy linkelted. Nekem egy sima wrapper/helper library - nak tunik az adatbazis fole, ami nem rossz, de az, hogy 3 eve latott utoljara commit - ot az tenyleg kiabrandito. Az elozo beszelgeteseknek annyi ertelme mindenkeppen volt, hogy az megfogalmazodott bennem, hogy a fuggosegeket erdemes minimalisan tartani. Ennek az eredmenye lett az, hogy erdemes lenne egy sajat API - t implementalni es azt tisztessegesen megirni/karbantartani. Az azt hasznalo alkalmazasokat pedig csak utana.
Nem erzem szenvedesnek a dolgot, mert erdekel a tema. Az sem zavar, ha senki nem fogja hasznalni. Nyilvan azt fel lehet hozni, hogy fordithatnam masra az idoben, ami esetleg meg penzben is megterul, ilyesmi. De ez nalam az n + 1. hobbi szintu elfoglaltsag, ami meg belefer ugy erzem. Ha esetleg megis felkapottabb lenne a dolog, mint aminek most tunik, akkor meg novelni kell a prioritasat a projektnek. Csak agilisan. :)
Most egy ideje nem irtam a forum - ra, de az nem azt jelenti, hogy ennyi volt. Mivel innen nem kaptam meg visszajelzest a nyelvek/technologiak teren, ezert magam kezdtem el utanajarni. Elso sorban Ruby - val kezdtem el ismerkedni, End-to-End tesztelesnel kerult a kepbe, ugyanis a JavaScript - es eszkozok nem voltak tul meggyozoek. (watir/cucumber/rspec kombinacio eddig meggyozott) Tovabbra is opcio a nyelv, framework/library (elnezest, gem - ek) meg van dogivel hozza. PHP - rol is erdeklodtem, ott a Laravel tenyleg jo. JavaScript nalam meg adott, ott kezdtem el korbenezni eszkozok teren, szinten van mire epiteni.
Az API - nak szerintem ket sarkalatos pontja van. Az egyik, hogy a DB felett egy olyan reteg legyen, ami azert elkapja a hibas adatokat, ne nagyon engedje szetbaszni az adatbazist, mar elnezest. Illetve az autentikacio es a biztonsag. Ezek mar leragott csontok, nem is akarom ujrafeltalalni a kereket, de ket kattintassal se letudni a dolgot. Ezeknek ugy erzem, hogy erdemes utanajarni, rengeteg jo anyag van arrol, hogy hogy is erdemes ezt csinalni, az pedig ido. Igy jelenleg itt tartunk.
(http://31.media.tumblr.com/edf634447a2cb6885ffa5ca1b80d92d8/tumblr_npntnijAYS1r2aobgo4_400.gif)
Kiegesziteskent erdemes elolvasni ezt a posztot is:
https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547 (https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547)
Az API implementalasara a JavaScript nyelv mellett dontottem, Node.js platformon persze. Igy elkezdtem gondolkodni a kivitelezesen:
- MySQL drivernek ezt neztem elsore: https://github.com/felixge/node-mysql (https://github.com/felixge/node-mysql) Meg sosem hasznaltam, igy nem tudom, hogy milyen. Elso ranezesre jonak tunik abbol a szempontbol, hogy van valamennyi hasznalhato dokumentacio, a projekt aktiv, az issue - kra reagalnak. Egy probat meger. Az egyetlen ami zavar az a callback hivasok. Ezt nehez atlatni, ronda kodhoz vezethet, stb. Igy ekore mindenkeppen szeretnek egy wrapper - t irni, amivel lehetne a package - t async fuggvenyekkel hasznalni.
- Web framework - nek a mar emlegetett Koa.js (http://koajs.com/) - t fogom hasznalni. Ez egy nagyon minimalis package, viszont rengeteg middleware/plugin talalhato hozza. Tamogatja az async fuggvenyeket. Nem ismerem az osszes middleware/plugin - t hozza, ez konkretan feladat: megtalalni azt a minimalis stack - et, amire szuksegunk van es jol hasznalhato. Pl. az autentikacio kezeleseben meg nem vagyok biztos, hogy sajatot lenne e erdemes irni vagy behasznalni valamit.
- Mint projekt fuggosegeket a babel (https://babeljs.io/) - t es a gulp (http://gulpjs.com/) - t mindenkeppen be akarom hasznalni. Azaz szeretnem a legujabb JavaScript feature - oket hasznalni, es automatizalni a folyamatokat. Pl. a kod stilus ellenorzeset eslint (http://eslint.org/) - el. Bar ezek mar inkabb development specifikus fuggosegek, nem a feladathoz kapcsolodnak, erdekesek lehetnek abbol a szempontbol, hogy szeretnek egy olyan projektet osszetenni, amivel a fejlesztes minel gordulekenyebb, meg akar az uj fejlesztok szamara is. Automatikus kod ellenorzes egy git hook - kent megvalositva pl. rengeteget segit. Ezt mondhatom, hogy tapasztalatbol tudom, ezekre erdemes odafigyelni.
Ezeket azert irtam le, hogy legyen lenyomata annak, hogy fejben hol tartok. Illetve tovabbra is varom a hozzaszolasokat, akar kiegesziteseket, akar megcafolasokat, vagy akar aki csak egy egy pont irant erdeklodne, vagy technologia irant.
Udv,
Shyro
Idézetet írta: Shyro Dátum 2015 november 17, 01:04:07 DÉLUTÁN
Kiegesziteskent erdemes elolvasni ezt a posztot is:
https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547 (https://community.trinitycore.org/topic/12112-the-tc-family-has-a-new-member-aowow/#comment-76547)
Az API implementalasara a JavaScript nyelv mellett dontottem, Node.js platformon persze. Igy elkezdtem gondolkodni a kivitelezesen:
- MySQL drivernek ezt neztem elsore: https://github.com/felixge/node-mysql (https://github.com/felixge/node-mysql) Meg sosem hasznaltam, igy nem tudom, hogy milyen. Elso ranezesre jonak tunik abbol a szempontbol, hogy van valamennyi hasznalhato dokumentacio, a projekt aktiv, az issue - kra reagalnak. Egy probat meger. Az egyetlen ami zavar az a callback hivasok. Ezt nehez atlatni, ronda kodhoz vezethet, stb. Igy ekore mindenkeppen szeretnek egy wrapper - t irni, amivel lehetne a package - t async fuggvenyekkel hasznalni.
- Web framework - nek a mar emlegetett Koa.js (http://koajs.com/) - t fogom hasznalni. Ez egy nagyon minimalis package, viszont rengeteg middleware/plugin talalhato hozza. Tamogatja az async fuggvenyeket. Nem ismerem az osszes middleware/plugin - t hozza, ez konkretan feladat: megtalalni azt a minimalis stack - et, amire szuksegunk van es jol hasznalhato. Pl. az autentikacio kezeleseben meg nem vagyok biztos, hogy sajatot lenne e erdemes irni vagy behasznalni valamit.
- Mint projekt fuggosegeket a babel (https://babeljs.io/) - t es a gulp (http://gulpjs.com/) - t mindenkeppen be akarom hasznalni. Azaz szeretnem a legujabb JavaScript feature - oket hasznalni, es automatizalni a folyamatokat. Pl. a kod stilus ellenorzeset eslint (http://eslint.org/) - el. Bar ezek mar inkabb development specifikus fuggosegek, nem a feladathoz kapcsolodnak, erdekesek lehetnek abbol a szempontbol, hogy szeretnek egy olyan projektet osszetenni, amivel a fejlesztes minel gordulekenyebb, meg akar az uj fejlesztok szamara is. Automatikus kod ellenorzes egy git hook - kent megvalositva pl. rengeteget segit. Ezt mondhatom, hogy tapasztalatbol tudom, ezekre erdemes odafigyelni.
Ezeket azert irtam le, hogy legyen lenyomata annak, hogy fejben hol tartok. Illetve tovabbra is varom a hozzaszolasokat, akar kiegesziteseket, akar megcafolasokat, vagy akar aki csak egy egy pont irant erdeklodne, vagy technologia irant.
Udv,
Shyro
Hajrá.