( Som-Som | 2021. 10. 22., p – 10:52 )

Nem értek hozzá, de azért el tudnék vele indulni. Legyen mondjuk a cikkeket kezelő article microservice.

Első körben azt mondom, hogy a path /article/v1/articles/{id}. A cikket még id nélkül POST-tal lehet beküldeni, olvasni GET-tel, módosítani PUT-tal, publikálást akár PATCH-csel, törölni DELETE-tel lehet. Az összes cikket GET /article/v1/articles?offet=n&limit=m pathon kérheted le (a limitet nem árt limitálni). Idáig minden művelet, ha megfelelő eszközöket használunk, pár sor. De sok problémát nem oldottunk meg.

Ha az emberke profiljában, ami egy másik service meg akarjuk mutatni a cikkeit, akkor SELECT title FROM article WHERE author=userid ORDER BY create DESC; módon meg is van. Csak itt sérül az, hogy az article service a saját db-jének az ura. NoSQL-lel lehet egy külön redundáns táblát erre létrehozni, de akkor is közös a tábla és még munkra húztuk a konzisztencia problémáját, amit batch-csel esetleg lehet orvosolni, ha a db motor támogatja, csak drága. Egy másik lehetőség, hogy a profile service az article service-től kéri el a cikk listát, nyilván nem a teljeset, csak a címet, esetleg create/modify/publish dátumokat is, hogy a user kedvére rendezhesse a böngészőben. Erre kell egy külön API hívás, pár sor csak.

A másik probléma az, hogy honnan tudjuk, hogy a saját cuccát módosítja a felhasználó? Sütiben ott lehet titkosítva a userid, a db alapján látjuk, hogy az övé-e. Az összes nem GET-be ezt bele lehet szenvedni, de valamikor biztosan hibázunk, amit persze egyszerű tesztekkel meg lehetne fogni, ha nem felejtenénk el. Lehetne egy API GW, elborult embereknek sidecar, ami ezt leellenőrzi, persze db nélkül. Na erre kíváncsi vagyok, hogy hogyan csinálnátok meg?