Hey everyone, I was planning to build a GraphQL API boilerplate that I wish to use jointly with next.js and leverage its ISR, image optimization etc. After researching a lot, I ended up hesitating between:
-
for orm/query builder/postgres driver: when interacting with a database, I prefer to avoid ORM and write raw queries (so I can easily use another tool if I want to switch or if it is not maintained anymore). One of the key point of the API would be to expose relay pagination queries that support conditional filtering + sort on nested tables + page cursors for which I would like optimal performance, so using for example raw queries with libraries such as slonik/zapatos/postgres.js/pgtyped. That stuff is quite hard to implement (and even prisma dropped its relay connection implementation in favor of an easier one), I found a few different implementations (on the server: some using graphql-relay, some nexus, some pothos, and most using urql or relay on the client). Libraries like slonik/zapatos/postgres.js/pgtyped would also allow to use some field type (like ltree) which are still not supported by prisma even in a raw query. Also I saw there is a huge list of issues with prisma raw queries so I am a bit hesitant (RQ: Raw Query Improvement Epic · Issue #12367 · prisma/prisma · GitHub) to go all in with prisma only. I would however would like to leverage prisma for basic CRUD to reduce my boilerplate.
-
for GraphQL server: graphql-yoga and mercurius
-
for GraphQL schema: nexus, pothos, graphql-relay so code-first
I then stumble upon redwood which implements some of the tech I was considering like prisma graphql-yoga, even fastify. That is why I’d really appreciate your opinions on how flexible redwood is regarding the possibility of changing the tech used for the aforementioned parts of the stack.
-
is it and will it always be easy to use redwood only for the API?
-
would redwood allows to use prisma jointly with one of the aforementionned library for raw queries? If not, is there a temporary workaround for end to end typesafe raw queries that circumvent the multiple prisma issues (RQ: Raw Query Improvement Epic · Issue #12367 · prisma/prisma · GitHub)?
-
is it easily possible to switch the GraphQL server and the library/framework used to create the GraphQL schema?
I had a quick look at the redwood codebase, and its structure is quite different than most open source projects I found that implement a graphQL server with the tech I mentionned, so I am a bit afraid that if at some point I hit a limitation with the framework, I may loose a lot of time fighting it. Unless it is modular enough so we can switch out components with what we want and easily extend it.
Nonetheless, I really love the fact that you strives to make redwood deployable to every platforms, contrary to next.js which gets more and more tightly coupled to vercel platform and it’s a shame that less efforts are put to improve the deployablility to other platforms.
Thank you for trying to make our work easier, that I end up using redwood or not I really appreciate.