Two API Things that Laravel Automates For Us

Let me show you a few Laravel "tricks" and why they may be risky.
Links mentioned in the video:
- Docs on Eloquent Serialization: laravel.com/docs/11.x/eloquen...
- My course "How to Build Laravel API From Scratch" laraveldaily.com/course/api-l...
- - - - -
Support the channel by checking out my products:
- My Laravel courses: laraveldaily.com/courses
- Filament examples: filamentexamples.com
- Livewire Kit Components: livewirekit.com
- - - - -
Other places to follow:
- My weekly Laravel newsletter: us11.campaign-archive.com/hom...
- My personal Twitter: / povilaskorop

[@CodeWithJagadish]

Lately, I've been considering different ways to handle data, like using query filtration instead of relying solely on Resource Collections in Laravel. You see, Resource Collections basically just create new arrays for each item in a collection, without helping minimize the memory load on database queries. If it is automated then why we don't have those cool features I mentioned earlier, you know? I know it might sound a bit unconventional, but my aim is to boost performance while also keeping our data secure.

[@LaravelDaily]

Yes, ideally you need both. API Resources are for PRESENTING the data, querying the data is a separate topic.

[@darwinllacuna5328]

thank you for giving me a understanding the power of Resources now im using it now

[@michaelsold7934]

Your videos rock! I love them

[@hamiha]

I actually prefer using Spatie's Laravel Data package, because it is using objects instead of arrays, giving you the power of code autocompletion etc

[@science_trip]

same with query builder. eg: use Illuminate\Support\Facades\DB; Route::prefix('api/v1/')->group(function(){ Route::get('users', function(){ return DB::table('users')->get(['name', 'email']); }); }); it returns a json with all users with the columns of the table inside the get. Like eloquent do. if you will use return DB::table('users')->get(); it will return all users with all columns

[@rathakann2471]

Nice and thanks

[@rushabhjoshi5350]

Always in resource, because of many features like relationship when loaded

[@fernandolamas330]

Great tip sr.! as you always do!. Just a question, if I use a resource to customize the fields that will be returned, do I still need to use the $hidden variable on the model?. Thanks a lot!.

[@learn-web-dev]

If you manually build the response array, no. This is very easy to test by yourself. But you should always hide sensitive data, as a best practice.

[@learn-web-dev]

We should not encourage people to return the collections directly as API Responses, because we need to be strict with data types and the real return type is not "Collection" :) Very well that you mentioned why the model automation used for API Responses is not a good idea. API Resources are a very good tool, indeed. We always need to control Requests and Responses.

[@kirayamato6128]

yup that's correct. for me api resources are some kind of extra easy way for beginners to do API. which I don't really like. when the application is getting bigger, API resources will be usesless.

[@francescoleto2823]

Resources everywhere!

[@warrenarnold]

Yeap problem with this is it becomes so hard to maintain, more places to change if needed

[@francescoleto2823]

@@warrenarnold spatie data package and you win!

[@Flankymanga]

Its the same idea of not using in SQL queries `SELECT * FROM` but name all the columns and enforce what to display and in what order....

[@musaddiqktk]

I personally prefer using API resources over implementing global control for API output. As we noticed, implementing global control could potentially affect the output in the future.

[@OliverKurmis]

Caution: `User::all()` will become a problem, once you have a decent amount of users in the database. You probably newer want to get all users, but maybe the recent 100 users or some users of a search result. I would use all() only for models with small and predictable amount of rows like dimension tables, e.g. `Country:all()` .

[@gazorbpazorbian]

can you nest resources? or say for example you want to bring all the users within a company like: Company::with('users')->get() without using select to get the specific fields of users?

[@learn-web-dev]

Yes, you can nest the API Resources.

[@LaravelDaily]

Yes, here's an example: laravel.com/docs/11.x/eloquent-resources#relationships

[@vipinfarswan6555]

resources might cause the performance issue for large dataset right?

[@LaravelDaily]

Not really, why?

[@chiagozieokafor5512]

Please someone should help me out (concerning another topic) How can I communicate to an external websocket from my Laravel application

[@MAAZKHAN-xv1lc]

Will you please make a tutorial series on Laravel relationships with examples?

[@LaravelDaily]

I have a full course about it called "Eloquent: Expert Level" laraveldaily.com/course/laravel-eloquent-expert

[@MAAZKHAN-xv1lc]

@@LaravelDaily Hey, can you teach us how to create custom table search filters using darktables and Livewire 3 in laravel10?

[@WallSpot]

Is calling artisan commands through route a good practice...

[@LaravelDaily]

Depends on what command, how and when.

[@luiszuniga4283]

I have an artisan command that schedules every day to import some data from an API. I made a route so that the admins can launch that command from their panel. It's the only case where I do that because it's not very clean.

[@ikarolaborda726]

Does anyone know what theme he is using in PHPStorm?

[@LaravelDaily]

Material Darker

[@iconicae8814]

I want know how frontend use our backend api with framework and with no framework that's what i need to see because i create alot of apis and i can't use it except in postman

[@LaravelDaily]

You should dictate the rules of what they see. Usually API is created and documented, and then front-enders use it according to the documentation you write.

[@iconicae8814]

@@LaravelDaily thanks so much mr povilas

[@ammaralhasanat6329]

Use resource every time

[@trewlove]

Always resources or DTOs, never models 🙂

[@learn-web-dev]

Yes, we should not expose the models as a best practice.