Using REST instead of GraphQL

Get Help and Help Others
1

Is there any examples in the docs on writing restful endpoints rather than using graphql?

2

Hello, there is a page about using custom Functions: Cookbook - Custom Function : RedwoodJS Docs.

You can still make use of your services, database, etc. from within one.

Just keep security in mind, as Redwood provides none on its own. But there is a section and package for using webhooks: Docs - Webhooks : RedwoodJS Docs.

2 Likes
3

I guess to know what is your use case for the REST support?

There are libraries like https://www.sofa-api.com/ that could generate REST endpoints from your GraphQL API automatically.
Helps if you want to maintain a single API and still support REST consumers.
Would be interesting to see what are the needs of the Redwood community around this and we could adjust and improve SOFA according to it

1 Like
4

Welcome to the forums @Urigo :rocket:!

I know a common point that is made in Blitz’s favor is their “Zero-API” data layer abstraction that “eliminates the need for REST/GraphQL.” In theory this allows developers to mostly ignore writing any API logic.

In reality this isn’t exactly the case, but their abstraction seems to have struck a nerve with users so I’d be curious if using SOFA would still involve creating a REST API like usual or if it provides extra features to simplify interacting with that REST API?

5

I mean, the question is, do we want people to write queries or not?
There are solutions also without…

6

Howdy @guledali! Funnily enough I just had this conversation with @mojombo and @thedavid about an hour ago!

I bet that with not too much work you could convert over the Cell architecture to make RESTful calls instead of GraphQL calls. You could keep the same behavior (show <Loading> while waiting for a response, show <Empty> if no data, show <Success> on completion, etc.)

Instead of useQuery here you could use node-fetch or a similar package that provides something similar to the useQuery states of loading and error (or create those states yourself wrapping node-fetch or something similar)

If you do this I’d personally love to see a PR that made this a potential option for the web-side when generating a Redwood app. We’ve looked into doing something similar with tRPC.

2 Likes
7

This would be really helpful! Has anything like this been introduced yet since this post?

8

Nope, not that I’m aware of…want to try? :smiley:

9

I’d love to give it a try, perhaps this weekend. I still do need to play around more with Cells and GraphQL, Redwoodjs in general.

10

I’ve been looking into tRPC aswel. I might give it a go.

Regarding createCell, can I simply copy the file into my project web/src/components/createCell.tsx and will webpack/babel pick up on it?

11

Was mentioned above, but I have wanted to see if

is an option.

Anyone want to try?

1 Like
12

I created a little setup with tRPC, it’s fairly easy to generate tRPC routes based on the services.
It would look something like this.

import { createTrpcHandler } from '../lib/trpc'

import services from 'src/services/**/*.{js,ts}'

export const handler = createTrpcHandler({
  services,
})

The problem is that the client infers the types from the server side router. Which we can’t access in web without some webpack/babel magic.

const router = trpc.router<Context>().transformer(superjson)
export type AppRouter = typeof router

I’ll see if I can get something working with sofa, since this topic is about REST :slight_smile:

1 Like
13

Hey! Any updates on this?