Positioning of RedwoodJs - Comparison with other Frameworks

#1

I would request the view point of the core team on how RedwoodJs is positioned against

Is there an interest / opportunity to collaborate?

#2

Thanks for sharing a couple of interesting projects. How are you suggesting to integrate them with Redwood?

#3

I understood that @VinayaSathyanarayana’s post is asking for Redwood’s (marketing) opinion on how does RedwoodJS stack up versus KeysoneJs and React_Admin (both being similar to RedwoodJS.)

1 Like
#4

I thought so at first too, but then I read

Is there an interest / opportunity to collaborate?

And now I’m not so sure anymore.

KeystoneJS seems to be a headless CMS, and there has certainly been talk before about integrating Redwood with different CMSes. And I totally see the appeal.

React-Admin could also be used together with Redwood. It could connect to the RW gql api and be the “admin” interface for all data, and then the RW web side could be the user-facing view of all the data.

#5

Good arguments - I wrote mine to “force the issue” a little (expecting to see whether this is a marketing question). It is relatively seldom to see startups merges, as everyone hopes to hit gold.

#6

Hi! creator of Keystone here. Hope you don’t mind me jumping in.

I’ve been keeping an eye on Redwood and am really impressed, in particular the clear philosophy that’s been there from the start :clap:

I’m not sure I’d see Redwood as being a competitor project as such to Keystone, or at least they both seem like well differentiated takes on the problem space of building apps. Both are built on the same foundations (React, GraphQL, Prisma) but they’re trying to do different things (Redwood is a full-stack application framework, Keystone is a headless CMS that’s powerful enough to be an app back-end)

Don’t mean to hijack the thread too much, but I actually would be interested in talking some time about how we could get Redwood and Keystone to play nicely together. Not sure if there’s too much overlap for it to make sense, but in theory Keystone’s schema and Redwood’s schema could share a source of truth and that would mean people could get Keystone’s Admin UI in app they’re building with Redwood.

If anyone from the Redwood team’s interested in having a chat (even if just to compare notes) I’d be really happy to, feel free to reach out to me on Twitter at @JedWatson

7 Likes
#7

Hi @JedWatson and welcome!

I’ll pass that along to the RedwoodJS team (@thedavid).

BTW - I just recently watched your video with Prisma last week: What's new in Prisma (v2.17.0) - YouTube

For those who don’t know about KeystoneJS, it’s a great intro. Jed starts ~ 30 mins in.

I actually would be interested in talking some time about how we could get Redwood and Keystone to play nicely together

Definitely!

1 Like
#8

As I said previously I definitely agree that Redwood could work with a headless cms as a backend with a nice ui already built!

#9

Sorry guys, I was not online for a while. It is nice to see the discussion progressing. Thanks to @JedWatson @Tobbe @dthyresson @adriatic .

Use case 1: Super Schema
Ideally, I would prefer to create my schema (master source of truth) in one place and leverage it for
a. Prisma Schema - for DB Backend
b. Admin UI using KeystoneJs and GraphQL
c. REST API for Integrations using loopback.io and OpenAPI Spec - I know that GraphQL Api exists, but in a number of cases we still need REST API to integrate with legacy systems.

Vinaya’s view point: At this point in time, KeystoneJS schema is a superset and can be used to generate other schemas.

Use Case 2: Integrated Access Control
We need the ability to define roles and fine grained access control that can be used consistently
across - APIs (GraphQL + REST), Admin UI and Front End.

#10

Use case 3: Easy / Fast Way to build Front End Apps
I am hoping that in the end we will get an easy and fast way to build front end apps.

I will be happy to participate in the discussion { KeystoneJs + RedwoodJs}

#11

Hey Jed, thanks for joining the discussion! I really enjoyed your presentation at the recent Prisma meetup, and thought it was interesting how much overlap there was between the tech that we’re using.

At the same time, as you say, we’re aiming at slightly adjacent use cases, Redwood has never gone after the CMS space. I agree that there’s some potential integration points between Redwood and Keystone and would be happy to brainstorm in that area.

#12

please look at hasura.io It provides GraphQL API End Points which could be leveraged.

#13

There’s a good article over on the Hasura blog showing how to integrate with Redwood.

ReactDOM.render(
  <FatalErrorBoundary page={FatalErrorPage}>
    <RedwoodProvider graphQLClientConfig={{
      uri: 'https://learn-graphql.demo.hasura.app/v1/graphql' 
    }}>
      <Routes />
    </RedwoodProvider>
  </FatalErrorBoundary>,
  document.getElementById('redwood-app')
)
#14

Thanks @ajcwebdev

#15

Any inputs on React-Admin

#16

I haven’t used it but it looks pretty powerful based on the examples and documentation and has a ton of community contributed projects. Judging by the first two features listed:

it sounds like it’s covering fairly similar ground to the Redwood web side (styling, data fetching, forms, client side routing) but with slightly different opinions.

#17

Hi all, just wanted to join the conversation in regards to React-Admin! First off, I’m really excited by all that RedwoodJS offers!

I think there could be a lot of promise in React-Admin + Redwood, for driving the data administration side of things. The go-to GraphQL data provider for React-Admin resides here, and depends on GraphQL introspection / naming conventions to work (naming conventions that I believe Redwood is already following!)

React-Admin handles a lot of the typical Admin type things included related data, pagination, search and filtering, etc. and would pair really well with Redwood’s DX. Generating pages for each CRUD type is great but when fields are related React Admin starts to offer more.

#18

Hey @RyKilleen :wave:! Thanks for joining, we love seeing what other projects are happening in the open source world that we could potentially collaborate with. With projects like this I find that it’s good to first try and think of a simple proof of concept you could create to show the community what the integration would look like.

I do not have enough experience with React-Admin to know exactly what that kind of proof of concept would look like, especially since many of the integrations we’ve seen up to this point have been more so on the backend with things like databases and APIs.

We’re happy to help spike something out though if you have an idea of what you think would be a good example application.

#19

I’m happy to try and build out a proof-of-concept! After some poking around, the ra-data-graphql-simple data provider won’t work out of the box because of custom schema expectations, mostly around listing data and meta data around listing data, eg.

type Query {
  Post(id: ID!): Post
  allPosts(page: Int, perPage: Int, sortField: String, sortOrder: String, filter: PostFilter): [Post]
  _allPostsMeta(page: Int, perPage: Int, sortField: String, sortOrder: String, filter: PostFilter): ListMetadata
}

There are a few other avenues worth looking into, based on the available providers list. The Prisma one stuck out but I see that it leans on Nexus, which the RedwoodJS FAQ specifically mentions pulling out.

The most likely route is a little extra effort but I’ll try and take a look at it this weekend. The Data Provider is the bit here that causes any real resistance.

Edit:
After looking around a little further I think GitHub - hasura/ra-data-hasura: react-admin data provider for Hasura GraphQL Engine might be a great inspiration (built directly in response to the issue I just ran into, avoiding custom grammar required by ra-data-graphql-simple

1 Like
#20

On a “data admin” and management note, wanted to share what Prisma has planned for the near future in “collaborative data browser” – sort of a hosted, team-based Prisma Studio:

While this isn’t ad Admin UI w/in your deployed app, it does touch on the data updates.

Also a good view is how Prisma discusses this Data Browser as part of their DX and collaboration efforts (starts at ~7:37 in):

Of course with this and any solution, roles, permissions are key when allowing access to your data – something that online browser data starts to support.