Add lucid make:resource

[adibhanna]

I have this situation were I'm creating a simple resource (mainly for APIs).
Let's say we have an ArticleController. we usually need Features for all methods in the resourceful controller (things like StoreArticleFeature, UpdateArticleFeature...) then a set of default jobs (CreateArticleJob, UpdateArticleJob...) and for validation, we might need an ArticleRequest class.
So, I'm wondering if we can add a command that automate this process, something like lucid make:resource that will create a boilerplate for all those classes.

Let me know what you think.

[Murzbul]

I totally agreed.

[Mulkave]

Love this! Added to the roadmap 👍

[undjike]

Hello guys. I agree too, that is very usefull.

Even though @Mulkave, what I meant for make:resource command was related to this https://laravel.com/docs/8.x/eloquent-resources.
🤭

[Mulkave]

Ah, that's different 😅 also to be taken into consideration!

[ksimenic]

I am wondering if there’s any progress related to API Resources. They were briefly discussed in few places in Slack and here.

I am wondering if someone is using Laravel API Resources in project. Where do you store them? How do you use them? Do you have a "global" job like RespondWithApiResourceJob?

[Mulkave]

It would be best to keep things Laravel-friendly in terms of structure, this is what we try to achieve most with Lucid. Since resource classes are generated in the Http directory they’re best suited to remain there. A RespondWithApiResourceJob is a good idea of course 👍 in that case it gets passed a combination of resource class name and the model. Otherwise, you could create decorator jobs (specialised jobs) to return a resource per domain, but that could become overhead with a lot of models/resources.

As for resources within services, they’d still reside in the Http dir of the corresponding service (e.g. app/Services/Auth/Http/Resources/UserResource.php however, these resources may only be used by the service (in principal) meaning that services will not use each other’s resources. This is beneficial when resources are different from a service to another, but will not work if you want resources to be available app-wide instead of at the service level.

Another approach would be to put resources next to their corresponding models under app/Data, e.g. app/Data/User/User.php and app/Data/User/UserResource.php this allows the entire application to use them (services, domains, etc.).

The reason why Lucid hasn’t adopted one approach is because it depends on the scenario and the personal/team preference. All approaches are equally valid.