graphql-public-schema-filter VS redwood

We actually built the following package, @n1ru4l/graphql-public-schema-filter which solves the problem stated within the blog post in a similar way (by filtering an existing schema into a subset of the original schema).

I am using this technique in one of my projects where we have a public API that is a subset of the internal API. I open sourced the library for doing that: https://github.com/n1ru4l/graphql-public-schema-filter

I built something similar that is "metaframework"-agnostic https://github.com/n1ru4l/graphql-public-schema-filter. Using this method has its benefits and drawbacks. If you simply public and internal part of the schema it can work pretty well. We use it for hiding the internal API from the public customer facing integration API. It is definetly easier than makntaining two seperate GraphQL schemas. However, if you want full inteospection capabilities doing this can be confusing as the introspection query operation result is different based on the authorization header which moght be weird if you are using tools such as code generators, as you now have to do it for two different schemas.

While building an GraphQL API that powers web applications we introduced a public customer-facing API. Instead of building two separate endpoints we chose to serve a different schema based on the authorization header. Furthermore, requests that do not provide an customer kntegration authorization header are only allowed to execute persisted operations. That way we somehow avoided having multiple HTTP routr endpoints. Instead of building two schemas from scratch and because the public schema is basically a filtered down version of the full graph we decided to filter down the graph using directive annotations on the schema SDL. I open sourced rhe JavaScript library for doing that (which is based upon graphql-tools). The dynamic schema selection based on the authorization header is done with Envelop

graphql-public-schema-filter: This library allows you to filter down you big graphql schema into a smaller subgraph. I have been using this for filtering our big production schema down into a public api schema that our customers use. So they don't have access to all the internal types, that are only for our internal web applications. The great thing about this is that we can just serve the correct schema based on the authorization headers as API users and Web Application tokens differ. If you have one big monolithic GraphQL server this is a great way of doing this and we are quite happy with it.

Public schema filter - for creating a simple GraphQL schema that can be used for public APIs based on existing GraphQL schema.

Frameworks are a theme with this month's Release Radar, so here's another. Redwood is a full-stack, JavaScript/TypeScript web application, designed to scale with you. It uses React frontend for the frontend and links to a custom GraphQL API for the backend. The latest version includes a bunch of breaking changes such as moving to Node 20.0, the Redwood Studio, and highly requested GraphQL features such as Realtime, Fragments, and Trusted Documents, the server file, new router hooks, and heaps more. If you've previously used Redwood, you'll probably want to upgrade to version 7.0. The team have put together a handy migration guide for you to follow.

The other piece of important information to acknowledge here is that when we say RSCs need a framework, “framework” effectively just means “Next.js.” There are some smaller frameworks (like Waku) that support RSCs. There are also some larger and more established frameworks (like Redwood) that have plans to support RSCs or (like Gatsby) only support RSCs in beta. We will likely see this change once we get React 19 and RSCs are part of the Stable version. However, for now, Next.js is currently the only framework recommended in the official React docs that supports server components.

Although there are quite a few opinionated battery-included frameworks that have picked up everything for you like RedwoodJS, Blitz, and Create-T3-App, you still need to choose between them and hope that they will remain mainstream and well-maintained in the future. So how should we choose?

Web development frameworks in JavaScript, such as NextJS and RedwoodJS, have gained popularity among developers. Choosing the right framework, library, or tool for a project is crucial for efficient development. Developers often seek the best tools to save time and avoid reinventing the wheel.

The community here is pretty friendly. https://redwoodjs.com/

Next.js 13 ignited the first wave of attention to React Server Components (RSC) around the end of last year. Over time, other frameworks, like Remix and RedwoodJS, have also started to put RSC into their future road maps. However, the entire "moving computation to the server-side" direction of React/Next.js has been highly controversial from the very beginning.

I'm currently experimenting with the fantastic Redwood framework. However, while going through the excellent tutorial, I didn't find any guidance on using data validation libraries like Yup, Zod, Vest, etc. So, I had to do some investigation and came up with a solution. This article describes the implementation of validation with Zod in a fresh Redwood app. You can find the sources at this github repository.

RBAC is one of the most common authorization models - users are assigned different roles, and resource access privileges are controlled at the role level. Despite its limitations, RBAC is a popular choice for simple applications, and some frameworks (like RedwoodJS) have built-in support for it.

Check it out here: https://redwoodjs.com/