I have seen this being mentioned and that in several tuts, Jeffery Way talks about it on Laracasts, but I Must say. This is the best explanation and demo of this in action, with the comprehensive demo, it makes it easier to understand. Hat off to you Adam, another great explination :-)
what if for example i want a function that downloads a pdf ? that's not exactly a create function, i would just create a FilesController and create a download function to be honest.
A very interesting talk and it also opens up so many possibilities as well. Like for instance - currently the subscription controller only has two methods - store and destroy. What if you want to see a list of podcasts you subscribe to. Then you can create a list in the subscription controller as well (maybe). And - so - much - more ...
Thank you very much to make this talk available here. When I read about REST and about endpoints and all about that API driven design stuff I always end up banging my head thinking about how nested resources will work, what methods do I need, exactly like you pointed out. This way of thinking that everything is CRUD really makes sense to me and I will try to apply this in a project I have and yes it is a nightmare right now. The way you explain and show how it is done seems very easy to apply and I like the concept of changing the pivot table's name too. That I already do as it makes a lot more sense but I never thought about creating a separate Eloquent model, so thanks for that.
Adam, just come back and watched this again, sometimes when you are live coding I find you get way too detailed, but this was really educational and gave me things to work on. I have been trying to do resource controllers for a little while but someof your refactoring was good incite and way to revisit things too, thank you.
Great talk, I like that you're showing a lot of common scenarios. 1. How would you model a restore method for soft deletes as CRUD? 2. Let's say you're building a proposal software, how would you model sending a proposal as CRUD? (considering you can send it more than once, unlike publishing)
My guesses / what I would do after watching the talk: 1. DeletedPostsController with an update = restore, delete = permaDelete 2. Probably something like a ProposalDeliveryController with a create. The nice thing about this is that you could easily make a model associated and store records in the db of send times and destinations if you wanted to as well.
1. Soft deleting a record means that you have _updated_ a certain flag to hide the record from a particular scope. So use _update_ for soft deletes and _delete_ for permanent deletes. 2. If every time you send a proposal out, you _create a new record,_ it means that you will have to call a _create()_ on your controller. You can have _SendProposalController_ (or even _EmailProposalController_ which makes more sense if you are emailing them out).
Perhaps it would be: Post: /pseudo-resource => PsuedoResourceBulkController Now you’ve set the scene for create update and delete pertaining to multiple records.
Adam, do you think that the trick where you set an object as attribute should be part of Eloquent core? Or would it over complicate things? And nice presentation, as usually.
but what if we submit the cover with the form data when we create a podcast, hmm how do we separate it to update route, when podcast hasn't been created yet, still so vague and u didn't mention it
you can do that by a separate Ajax call on your front end, uploading the image, returning its path, and then submitting it to the store route of your podcast .
Great talk. Tip1: Nested Controller? New Controller. Tip2: Edited independently: New Controller => (Updating profile image separately). Tip3: Touches pivot records? New controller and probably a new model => Subscription/Unsubscription Tip4: Transitions state? New Controller => Publish/UnPublish
in my mind this begs the question why not Route::get('/resource/create', CreateResource::class) and let the invoke take care of the create action and just have actions as classes... with one public method and whatever you need for private helpers... Why even have a "resource" controller? I like this talk and the ideas in it... it certainly cleans things up but why not just take it to the extreme and make everything super-specialized...
Hi Adam. Great Video. I have a question, If you want to have the option to download the cover image of a podcast. Should I add the action in the PodcastCoverImageController? What should it be the name of that action? action "show"? thanks so much.
before I watch this, I thought this is going to be repeated code and just a man who try the best for SOLID and some hell with the best practice but damn! this is gold, this is a killer design, especially the pivot naming xD
As someone on stackoverflow once told me... "Don't forget the single responsibility principle. Each function needs a single responsibility, the same can be extended to views, routes etc. For example, you have a controller responsible for submissions and a function responsible for editing said submissions." en.wikipedia.org/wiki/Single-responsibility_principle
Nice talk, even so I would disagree with the subscriptions and published podcasts resources. For me it would be /podcasts/{id}/subscription and /podcasts/{id}/publication and I don't have to pass the podcast id via the request body. I moves related stuff a lot more together.
I always come back to this talk. I've built my apps using this technique and it works perfectly. Thank you for this. @adam if you ever read this, do you still use this technique?
Great video. Did a lot of refactoring to my apps using your tips. But I was wondering, where do Single Action Controllers (invokable controllers) come into place?
@@BenGearig once I'm not delivering food, I will. I still deploy all my Laravel apps on Forge and purchased the TailwindUi package to support the man even on my limited budget. Does that count?
Very interesting ! What if i have a "filter" method in a "PostController" ? Should i extract it to a "FilteredPostController" and rename it "index" in this logic ?
Most of the times, you should be able to add the filters as part of the index action. If it’s mandatory to have a separate endpoint for some reason, then yeah a FilteredPostController with an index method is a good way to go imo
fine line and a little subjective - but - patch is partial update, put is replacing the whole object - so you could argue that since his 'resource' is a PodcastCoverImage, he is replacing the whole object and therefore a PUT should be used
Thanks for awesome talk. What if I want to call an api to check if current name of a user has been taken in the DB. What would be the best naming for that api end point? Is '/user/{name}/has-duplicate-name' ok?
