Question about sdl generation and updates

Hi, I am new to RW (and loving it) so this might be an obvious question.

We use Directus as a DB content manager and RW to build an application on the data.
I love how sdl generation creates scenarios tests and services. Now what happens in the dev process, is that I have to edit the model and add/change fields/relations/etc.
Now if I generate sdl for that model I need to --force the update of all the generated files.
So the tests and scenario and service file will lose any modifications I might have added.
I read on the docs that I can skip recreating the test and scenario file, but what about services?
What is the best strategy to get the best mix of generation and customization?
Do you create separate files for extra scenarios, test, and service functions?

TIA

Hi @smarchesini-DQ and welcome to the community,

RedwoodJS offers a lot of freedom for the api side so it can be confusing and intimidating.

I would consider the following:

  • Generate for new models, customize for updates.
  • Services should not contain logic but call external functions/classes that will contain the required logic. This is to make sure you expose only what defines your API, instead of exposing your entire logic.
  • Get very confortable with creating & curating your own scenarios, tests and resolver modifications. You won’t let your application take off if you don’t do that early on, because you can end up pretty quickly with a bloated code base.
  • Consider feature domain design for you API. I have a method that’s proved to scale & mature particularly well, which is to split my code into domain, entity, verb/action. This is the kind of path you would find yourself working with: api/src/lib/community/user/create/[Create,Create.test,Create.scenario].ts.
    In this pattern, api/lib/community/user/create/Create.ts exports only its default module but it can also contain module scoped structures (functions, variables, types…). Since it is located in api/src/lib I can call it from a proper service endpoint if needed or from other api/src/lib/* modules. This pattern answers directly the concern about creating extra scenarios & tests, but be aware that you have the same freedom when it comes to service functions. I usually have a couple of these which are not related to the model, so I create my own service files for them.

Hope it helps.

2 Likes

Thanks so much Noire, will try to follow your advice :slight_smile:

2 Likes

Please let us know how it goes!
And what works for you best.

1 Like