Any plans for making DataCell generic/extendable for REST

Get Help and Help Others
1

Hey,

New to RedwooJS and modern JS paradigm (my experience primarily have been in mobile and cloud but have basic understating of web/browser/DOM tech) - literally just watched few YT videos and went through some docs.

I am considering it for re-writing my current web app for my startup. It is a SaaS platform that provides multiple services.

I want to take this step-by-step. Firstly would want to just update the frontend - that is the web part of the framework - without touching the backend part. I just want to use the React-Storyboard-Jest part of the framework.

However I found the concept of DataCell interesting:

  • declarative way to render based on various states
  • generated mock data and storyboard classes
  • repeatable pattern - managed by CLI

Now the problem is I can’t do the same (offcourse the doing HTTP part is easier - but I want other goodies too!) for REST APIs for my existing cloud server. Has anyone built something similar for REST with generator? Is it planned in RW roadmap? is redwood-cli extendable (went through redwood/packages/cli at main · redwoodjs/redwood · GitHub looks like it is not)?

Although this is not a deal-breaker. I like (alteast from distant, haven’t got my hands dirty yet) the “Redwood-ic” way of doing things - therefore anything I will do will not be as good for it!

2

Proposing Design Pattern for it

  • Let’s call it RestCell or HttpCell - keeping the namespace different because if RW doesn’t want to implement it I (or anyone who knows better) can do its on:
  • Similar to DataCell we have a command to generate them - with cell class MyRestCell.js, MyRestCell.test.js, MyRestCell.mock.js, MyRestCell.stories.js
  • Everything mentioned above will be same as DataCell except in the MyRestCell.js instead of QUERY, beforeQuery and afterQuery (whose name and functionality are GraphQL specific) we will have REST based equivalent alternatives - URL, METHOD, beforeRequest, afterRequest, etc.
  • Same as DataCell the actual component will be “generated” - if my understanding of how it works under-the-hood is not wrong.

Alternative solutions:

  • “unified” approach - making DataCell work with RestAPI concepts like URL, METHOD
  • “abstract” approach - abstracting out the Cell part and making it exentable - refactor DataCell to implment it without breaking compatibility - add new RestCell - additionally can make it customisable by end-user as well.
3

These are my first thought - maybe REST would require more “exports” or functions.

Consider it as just a draft.

4

Let me propose an alternative - access your REST api within your RedwoodJS graphql api.

See redwood-office-hours/2022-09-28-rest-directive at main · redwoodjs/redwood-office-hours · GitHub

Then you can simply use cells with all their lifecycle handling, auth, and data fetching.

1 Like
5

Hey @dthyresson for the response.

One quick question - Does the directive act as a proxy for a real API server? will that mean I have to host “api” app as well? If yes, then that will add unnecessary hop and latency. Or under the hood - it will bypass the GraphQL endpoint and query directly from the client.

6

Will have to think about it, if the approach you mentioned requires an additional “hop” for the new client I build and the existing server. May be this is not useful to me in that case - not only the API performance from clients perspective will be slower but also would make debugging things harder as well.