Jak zjistit, kdy mám použít promisy v resolverech?

Když řešíš promisy v resolverech, tak to v podstatě vždycky záleží na tom, co děláš. Jak jsi správně poznamenal, když dotazuješ databázi nebo voláš externí API, je jasné, že budeš potřebovat promisy, protože tyhle operace obvykle trvají nějakou dobu a musíš čekat na výsledek. Ale i když máš data v paměti, má smysl používat promisy, pokud chceš mít konzistentní způsob, jak se vypořádat s asynchronními operacemi. Jen tak to nebudeš muset mixovat s callbacky a budeš mít přehlednější kód.

Prakticky řečeno, pokud provádíš něco, co může trvat (i když ne dlouho), jako je např. filtrování nebo nějaké složitější operace nad daty v paměti, můžeš použít Promise.resolve(). To ti umožní udržet asynchronní styl programování i pro synchronní úkoly.

Co se týče chybového hlášení, tak většinou bude stačit zachytit chyby pomocí .catch() nebo try/catch s async/await. Měj na paměti, že když použiješ await v resolveru, GraphQL automaticky vrátí chybu jako odpověď. Takže je dobré mít tyhle věci promyšlený a testovat je.

Závěrem - používej promisy i pro úkoly v paměti, ideálně drž stejný styl – buď vše asynchronní nebo vše synchronní. Přehlednost a konzistence jsou klíčové.

Když řešíš resolvery v GraphQL a přemýšlíš o použití promis, tak si dej pozor na to, co vlastně děláš. Pokud máš operace, které trvají nějakou dobu, jako dotazy na databázi nebo volání externího API, tak je jasné, že budeš chtít použít promis. To ti umožní vrátit hodnotu asynchronně a správně zpracovat výsledky, když už jsou hotové.

Pokud ale pracuješ s daty, která už máš v paměti a jsou okamžitě k dispozici, tak použití promis není nutné. Můžeš klidně vrátit přímo hodnotu. Na druhou stranu, používat promis i tam může být dobrý nápad pro konzistenci kódu. Připravíš se tím na situace, kdy třeba data ještě nabíráš nebo zpracováváš a nechceš se pak s tím prát, že někde máš synchronní a jinde asynchronní kód.

Co se týče chybového hlášení, když používáš promis, tak můžeš jednoduše chytat chyby pomocí catch bloku, což je fajn. Pokud něco selže při volání API nebo databáze, nebudeš mít problém vrátit relevantní chybu klientovi.

Takže shrnuto: používej promis pro asynchronní operace a když chceš mít konzistentní přístup. Při práci s již dostupnými daty můžeš klidně vynechat a udržet to jednoduché.

Když děláš resolvery v GraphQL, tak promisy použiješ většinou, když máš asynchronní operace. Jasně, když dotazuješ databázi nebo voláš nějaké API, tam to je obvious. Ale i když pracuješ s daty v paměti, pokud bys třeba měl nějakou operaci, co trvá déle (třeba zpracování velkého pole), tak je fajn použít promisy. To ti umožní neblokovat event loop a dodržet principy asynchronnosti.

Co se týče chybových hlášení, tak pokud něco selže v promis, můžeš zachytit chyby pomocí .catch nebo async/await s try/catch blokem. To ti dá větší kontrolu nad tím, co se děje, a jak reagovat na případné problémy.

Nejlepší praktiky pro organizaci kódu zahrnují udržet resolvery co nejjednodušší a delegovat logiku do separátních funkcí nebo služeb. Také se snaž nezapomínat na error handling hned od začátku. Když budeš mít jasno v tom, co se vrací a jak se to chová, půjde ti to líp. Takže klidně experimentuj s tím, co funguje, a uvidíš, jak promisy zásadně zjednoduší práci s asynchrónními úlohami.