From 7309bce42da73159315280918452ba8df7039e72 Mon Sep 17 00:00:00 2001 From: orta Date: Fri, 21 Jun 2024 12:52:09 +0100 Subject: [PATCH] polish --- content/posts/2024/06/20/sdl-codegen/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/posts/2024/06/20/sdl-codegen/index.md b/content/posts/2024/06/20/sdl-codegen/index.md index f3aa4c7..c78d6c5 100644 --- a/content/posts/2024/06/20/sdl-codegen/index.md +++ b/content/posts/2024/06/20/sdl-codegen/index.md @@ -25,7 +25,7 @@ We're talking about the early days of GraphQL, and may even have pre-dated the [ When I started figuring out the tech stack for Puzzmo, I opted [for RedwoodJS](https://redwoodjs.com/) as a base for our API and admin tooling. RedwoodJS out of the box comes with a GraphQL API which uses a "SDL first" style strategy whereby you: - Write a `*.sdl.ts` file which includes the GraphQL definition for your API -- Write a corresponding 'service/*.ts' file which has functions that map to the SDL declarations +- Write a corresponding `service/*.ts` file which has functions that map to the SDL declarations For example, a simplification of the "Puzzle" in Puzzmo looks like this: @@ -79,7 +79,7 @@ As you might have guessed, it was not enough for me. What were my biggest issues? - The runtime description was not accurate enough. I'd end up with code which TypeScript is happy with, but crashes at runtime. -- TypeScript error messages in my resolvers very too abstract. +- TypeScript error messages in my resolvers were too abstract. - The generated types lacked nuance, and often included too much information, making it hard to call the resolvers like functions in my tests.