3 ms·
I've spent a lot of time with GraphQL, in the backend, frontend, and middleware, with TypeScript and also Python. At my startup, we used Strawberry on the backe
by chatmasta 3y ago
I've spent a lot of time with GraphQL, in the backend, frontend, and middleware, with TypeScript and also Python. At my startup, we used Strawberry on the backend, TypeScript in the middleware for stitching multiple APIs together [0], and codegen on the frontend with graphql-code-generator. Once we got it working, this was an amazing setup and my favorite part of our stack. GraphQL was a shared cross-language type layer with end-to-end auto-generation. We could define a resolver with Strawberry in Python, and get auto-generated types all the way to the frontend. We could collaborate on new features by defining a GraphQL schema in the RFC and coding the frontend and backend in parallel.
I recognize a lot of the problems described here in the docs (the "How Grats Works" [1] page is a good read). I could see this library fulfilling a similar role to Strawberry, for a backend written in TypeScript rather than Python.
Overall, it looks like a compelling implementation of some good ideas from the author, who incidentally is on the Relay team at Facebook, so he's probably done a lot of thinking in this problem space. Next time I'm working on a project with a TypeScript backend, I'll definitely take a look at this.
[0] https://www.splitgraph.com/blog/graphql-schema-stitching https://www.splitgraph.com/blog/graphql-schema-stitching
[1] https://grats.capt.dev/docs/faq/how-grats-works https://grats.capt.dev/docs/faq/how-grats-works
- emptysea 3y agoDid you manage to get IDE support to click into the backend implementation from the front end code?
- chatmasta 3y agoNo, that would have been cool though. We did have auto-generation on save of backend, all the way to the front. That was nice when it was just myself and co-founder, and I was doing a lot of fullstack code editing. But as we hired Python and TypeScript specialists, it became less important since each developer was only focused on their side. The interface, or "contract" between frontend and backend was the .graphql schema that we checked into the codebase. And if we needed to find an implementation, it was usually simple enough to grep for a matching resolver name.
- captbaritone 3y agoGrats and Relay (I work on both) can be combined to get this developer flow, and it’s pretty incredible. Would love to see it working with Strawberry as well. https://x.com/captbaritone/status/1748020699263045659?s=46 https://x.com/captbaritone/status/1748020699263045659?s=46 Example project with this setup working can be found here: https://github.com/captbaritone/grats-relay-example https://github.com/captbaritone/grats-relay-example
- dventimihasura 3y agoAt your startup, why did you choose Strawberry over, say, Prisma?
- chatmasta 3y agoMostly because the backend services were all in Python and already used Pydantic in a number of places. Prisma was just more heavyweight than what we needed. We actually started with Postgraphile, but found it was too much magic and eventually moved to defining resolvers explicitly with Strawberry for each service (which was much easier to do once we added the stitching layer).
- dventimihasura 3y agoInteresting. Yeah, I also found Prisma to be a bit heavyweight. Postgraphile is nice, though. I wish it went beyond postgres.
- captbaritone 3y agoGrats author here: Strawberry was definitely (and continues to be) a big inspiration for Grats, I’m pleased to hear that you see the resemblance!