Jak správně strukturovat resolvery v GraphQL?

Tak já ti na to zkusím odpovědět. Obecně se v praxi doporučuje organizovat resolvery podle typů. To znamená, že pokud máš User, Post a Comment, tak mít tři samostatné soubory pro každý z těchto typů, kde budeš mít všechny resolvery související s daným typem pohromadě. Tím se to celé lépe udržuje a orientuje. Když máš hodně resolverů na jednom místě, může to rychle přerůst do chaosu.

Pokud jde o mutace, tak je dobrý mít je oddělené od dotazů, protože se jedná o jinou logiku. Můžeš buď mít samostatný soubor pro každou mutaci nebo je seskupit podle typu, jako u dotazů. Hlavně dej pozor na to, aby byly jasně oddělené a snadno pochopitelné.

Co se týče správy chyb, tak hodně záleží na tom, jakým způsobem chceš chyby vracet. Můžeš mít nějaký centrální systém pro zpracování chyb, což usnadní údržbu. A testování? No, snaž se psát testy přímo na resolvery – to hodně pomůže, když se ti projekt rozroste.

Každopádně nejlepší praxí je prostě dělat to tak, aby ses v tom vyznal ty a další lidi v týmu. Je to dost individuální a záleží na konkrétním projektu.

Strukturování resolverů v GraphQL je dost o osobních preferencích a velikosti projektu. Obecně se doporučuje organizovat resolvery podle typů, protože to dává smysl a udržuje věci přehlednější. Takže mít soubory pro User, Post a Comment samostatně může být užitečné. Pokud máš ale malý projekt, klidně můžeš mít všechno v jednom souboru, dokud se ti to nezamotá.

U mutací bych řekl, že bys měl mít nějakou logiku oddělenou. Například můžeš mít složku pro mutace a tam si udělat soubory na různé operace, což pomůže udržet to čisté, když začneš přidávat víc funkcí.

Co se týče správy chyb, hodí se mít nějaký centrální mechanismus, jak chytat a zpracovávat chyby. Můžeš třeba použít middleware nebo hooky na error handling – to ti ušetří spoustu času.

A testování? Tam bych doporučil psát testy pro jednotlivé resolvery zvlášť. Tím pádem si můžeš zajistit, že fungují tak, jak mají a zároveň ti to dává větší flexibilitu při změnách.

Takže shrnuto, rozdělit podle typů, udržovat logiku u mutací odděleně a mít dobrý error handling a testy je fajn základ.

Strukturování resolverů v GraphQL je fakt zajímavá věc. Osobně bych doporučil organizovat je podle typů, takže mít samostatné soubory pro každý typ jako User, Post a Comment. Takhle se ti to pak líp udržuje a hledáš v tom snadnějc. Když máš všechno v jednom souboru, může to rychle přerůst v chaos, zvlášť když se přidávají mutace.

Co se týče mutací, hodně lidí dělá to, že si vytvoří zvlášť soubory pro každou mutaci nebo skupinové operace. Tím pádem je to přehlednější a víc modularizovaný. Chybová správa by měla bejt taky součástí tvých resolverů - měl bys mít nějaký centrální způsob, jak chybový stavy zpracovávat, třeba pomocí middleware nebo helper funkcí. Testování by mělo jít ruku v ruce s organizací - když máš dobře rozdělené resolvery, tak se daleko líp píšou testy. Takhle si můžeš otestovat jednotlivé části bez toho, abys musel projíždět celým jedním obřím souborem.

Shrnuto - podle typů, odděleně pro mutace a myslet na chyby a testy. To je podle mě nejlepší směr.