I’m starting a new greenfield project using RedwoodJS. In the few weeks I’ve been working with rw, I’ve come to really love the ‘scaffold’ capability. Great way to get a significant amount of functionality with very little work.
But I have just one problem: scaffold needs to be driven by the Prisma schema and I find myself almost completely driven by third party APIs. I’m sure I’m missing something, but I’m wondering if the rw community would benefit by a version of the scaffold command that were driven by the SDL schema instead of the Prisma schema? Create all the scaffolding that the current scaffold command currently does including stubbed services.
Maybe I’m looking at this all wrong and I’m the only one with this ‘want’? Or maybe the smart people driving rw are already thinking of an answer to this? Just feel like I’m having to go to significant work to achieve the functionality that scaffold provides by doing a lot of copy/paste work from a dummy scaffold to my SDL driven model.
This is a very interesting idea and definitely not something we’ve considered before! We do think Redwood works great with 3rd party APIs and would love to make that even better by finding a DX that feels like Redwood should feel.
@joconor would you consider turning this into a draft RFC here on the Forums? We’re big fans of README Driven Development, which we’d adapted as Tutorial Driven Development for Redwood. Using that process, if you could write up the example workflow, showing pseudo code and CLI commands along the way, that would give me a much better understanding of things.
Lastly, I’m wonder if there’s a hacky workaround for now — if you created a Prisma moded which you Scaffolded, could you then modify some things (including reverting the Prisma migration and model) to used the Scaffold with the 3rd party API?
I’ll definitely try to write something up in the way of an RFC, but I can’t promise timing. I’m under the gun right now to provide a rwjs based PoC, after which I’ll be away for a couple weeks.
Given my relative newness to rwjs, I’m not quite comfortable ‘undoing’ a lot of the stuff that the CLI does for me (that’s a ‘me’ problem). But I am working around this by creating scaffolding in a new, empty rwjs project and then just copy/pasting those pieces that are useful in my sdl driven version. I think that will also largely inform me on what the workflow & pseudo code should look like for the draft RFC
Roger all that. And, yes, that there “hacky” workflow is exactly the kind of thing I was looking for!
I’m under the gun right now to provide a rwjs based PoC, after which I’ll be away for a couple weeks.
Very cool! Not sure how much you can develop this in public and/or with the community, but do keep in mind that this community 
s being able to “ride shotgun” with solo devs who are building things. From Makers Hour to Discord chat, let people know what you’re working on, show what you’re doing, and ask for help/suggestions/you-name-it.
@joconor I think this is a really good idea or something we should consider. I ran into a similar problem. @thedavid when I was working on the redwood events discord bot. I didn’t really want a database table because I was interacting directly with a 3rd party service but you can’t generate an sdl without a model.
This a slightly different use case but I see the benefits of the generators not being tied to the prisma models.
For instance when running yarn rw g sdl discord it errors and says no model with name discord. It should probably still give you the sdl file and the services files. Then after you generate those you could fill out the sdl and run the scaffold against the sdl to interact directly with 3rd party apis.
I came here to ask the same question. “Could I generate the graphql scaffolding based off a different spec (Open API Spec would be incredible)”?
I do have the time to write up the “README Driven Development” document, so do I just open a PR to Redwood with just a ‘README’? Or is a better question, do you have an FAQ on how to make a feature request for Redwood?
Thanks!
@Hardwick a readme or RFC is welcome and can let the community work through the needs and some examples to use to test.
One question - since scaffolds typically have CRUD functionality do you still plan to generate a service that the db Prisma client to insert, update and fetch data?
And if so. What model would these use?
Or, would they simply stub out empty services to define?
The use cases I’m considering are…
- Having your front-end work with an existing API (could be internal brown-field project or external vendor APIs)
- Separate FE and BE teams working on a project at different paces
In both of these use cases, I still see the need for mutations and queries (CRUD), that would be a straight forward starting point.
I’ll shall write it up!
@dthyresson - Here’s my attempt at writing it up - RFC on using API specs to drive scaffolding by davidkhardwick · Pull Request #5552 · redwoodjs/redwood · GitHub
This actually isn’t so bad.
I needed a new “api endpoint” (what do you even call those in gql-speak?) So I needed the sdl, the service, the cell. Everything but the prisma model.
So what I did was just write the model in schema.prisma (you don’t even have to migrate it) and then generated all the files I needed. And finally I just removed my model from schema.prisma and ended up with exactly what I needed 
The MVP here might just be an option to generate the model in a schema.api file instead of schema.prisma, and run the sdl command with an option to indicate that it’s an API vs DB generation, and so it doesn’t create the migration but does the other stuff.