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 
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 
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.