Questions about flexibility, modularity and raw queries

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.

@trompx These are great questions and I really appreciate you taking the time to write this post. Without any intention of being trite, I sincerely encourage you to go through the Redwood Tutorial as the best way to answer these questions for yourself. So many of the technologies you mention are great and either comporable or even superior in some regards or specific aspects. But our decision to solve first for DX and end-to-end integration is the whole point of starting with Redwood — there may be tradeoffs between libraries or components, but we feel the advantages of conventions and first-class integrations across the stack offer superior gains. For example, how much do you like writing your own end-to-end test suite with mocks, scenarios, test DB, etc.? :joy: All those “other things” add up to a lot of overhead.

So my honest advice is to:

  1. start with the Redwood golden path…
  2. …and when scale or performance requires changes, start swapping libraries/tools

But now to your questions:

  • is it and will it always be easy to use redwood only for the API?

Yes, this is a priority for us.

would redwood allows to use prisma jointly with one of the aforementionned library for raw queries?

I would believe so! But you should try an experiment. You can use any db client you want. It’s just not supported via the Redwood CLI.

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.

Redwood is tightly integrated but it is not tightly coupled. Plenty of startups are swapping things in/out, they just then choose to manage those things themselves.

For example, check out some of these links:
https://community.redwoodjs.com/search?q=relay

1 Like

I can give you quick short answers but someone more heavily invested in the API side will probably chime in.

is it and will it always be easy to use redwood only for the API?

It should be the Redwood team is heavily invested in making developer experience a top priority.

would redwood allows to use Prisma jointly with one of the aforementionned library for raw queries?

You should be able to use any thing you want to query because of the way Redwood handles querying through Redwood Services they are just functions. Make your queries or 3rd party queries return the data and add your service to the SDL

is it easily possible to switch the GraphQL server and the library/framework used to create the GraphQL schema?

This might be a little out of scope of what redwood is easily able to do. Redwood has a close relationship with The Guild - https://www.the-guild.dev/ to provide a cutting edge graphql server and plugin ecosystem.

One last thing I would mention is to take it out for a spin it is really quite easy to spin up a new redwood grapqhl project. You can then try implementing some of your trickier usecases and see if it works for you.

Definitely check out this thread with many similar questions and answers to yours:

Also:

is it easily possible to switch the GraphQL server and the library/framework used to create the GraphQL schema?

Oh, I meant to speak to this as well. So +1 to @KrisCoulson There’s no other GraphQL server we would recommend other than Yoga and anything created/managed by The Guild. They are the experts leading the way. And we tighly collaborate with them weekly if not daily. You should:

  • spend time in our GraphQL Docs to understand how feature-rich Redwood’s GraphQL API is out of the box
  • spend time looking at the features available and coming soon via Yoga + Envelop

Whatever you choose as your stack, make sure it includes Yoga!

Thanks a lot for all your prompt answers.

So many of the technologies you mention are great and either comparable or even superior in some regards or specific aspects.

I was first inclined to use nexus for its integration with prisma and initially for the t.model and t.crud provided by nexus-plugin-prisma but it has been deprecated and the new nexus-prisma is still not production ready and not offers the crud generation anymore (yet). In the meantime I checked a few redwood open source projects and I find the SDL approach very clean too. That plus the fact that I found this Command Line Interface | RedwoodJS Docs & Yarn rw g sdl <model> --crud which is great to generate just the services boilerplate and types.

For example, how much do you like writing your own end-to-end test suite with mocks, scenarios, test DB, etc.

That is the exact reason why I would like to leverage redwood to build my API as I didn’t have time to build that part of my boilerplate :slight_smile:

Concerning the frontend part, next.js has huge traction and has CSR, SSG, ISR, image component that prevent layout shift etc. that redwood could benefit from. I was really looking to leverage best in class libraries/frameworks to build my next project, but next.js was missing a good backend structure (since they implemented their api routes) that is why I am looking for another community supported backend framework. What I don’t like about next.js is that they push features that are vendor lock-in, like ISR where they cache at edge which is specific and optimized for their hosting platform. Hopefully, they have their infra on AWS, and a few solutions exists to deploy the same infrastructure (via CDK which I really like) but I admit this is not the best DX and deploying it is not trivial.

Anyway I’d be interested to know why you decided not to use next.js for the frontend, or being framework agnostic for the frontend so users can plug whatever tool they prefer (remix, svelte etc.) instead of developing your own?

Also, I found a great post about the possibility of using redwood with next.js (How to Connect a Next.js Frontend to Your Redwood API) but it is just a forum post and this does not appear in the documentation, which suggests that it is not officially supported.
This is my biggest concern about using redwood and I think having an official and supported way to connect a third party frontend library/framework jointly with the redwood API would inspire a big trust in the framework.

Redwood handles querying through Redwood Services they are just functions

I find this really clean finally, even cleaner than the nexus approach.

Make your queries or 3rd party queries return the data and add your service to the SDL

As I said, and I am not sure of how exactly the generators work but I guess prisma is used for that, and they don’t support all field type (like ltree). An example of how to use another query builder/postgres driver and still have e2e typesafe would be a great addition.

Questions mainly related to customising Redwood

Thanks for that great link which summarize a few other points I also wanted to raise.
In fact, there are still a lot of components required to build a full application, one that I consider primordial is to be able to share code between api & web (i.e. validation). Also background & scheduled jobs would be a great addition.

Redwood has a close relationship with The Guild to provide a cutting edge graphql server and plugin ecosystem.

I ended up to the same conclusion thus why I ended up considering redwood :wink: I needed a clean way to specify cache per query and I like how this is done via ttlPerSchemaCoordinate (even if there is still room for improvement). That + directives is really great, I intended to use graphql-shield for that but it seems it is a perfect replacement.

2 Likes