Great comment from Kévin Dunglas himself, the creator. He replied on TH-cam, but the comment seems to be hidden (too many links?). Here it is: "API Platform for Laravel is still quite new, and the docs is being improved. We still have a lot of work to do on this side. By default, we follow the @HydraCG API specification. It's where this "member" key comes from: hydra-cg.com/spec/latest/core/#collections You can customize this key (by using your own class for collection, or by registering a custom normalizer), but it's not a good idea because then you'll not be in sync with the spec, and client tools supporting this spec may not work as expected: - api-platform.com/docs/core/state-providers/ - api-platform.com/docs/core/serialization/ Alternatively, as mentioned in another comment, you can use another API format, such as JSON:API which may be "easier" at first to understand, or even just write a normalizer to have a totally custom format (which we don't recommend, using battle-tested standards or open API formats such as Hydra, GraphQL and JSON:API prevent a lot of foot guns): api-platform.com/docs/laravel/#content-negotiation Supporting "Model::toArray()" is a good idea and should be easy to add. This will ease migrating from "API resources", we'll work on this. The recommended way to customize the fields in API Platform is to use the #[ApiProperty] attribute (you can change the name of the field, expose virtual fields, etc). Regarding validation, I don't get your point. Are we missing some Laravel conventions that we should support? You can also add validation inline right in the attribute: api-platform.com/docs/laravel/validation/ For versioning, while we encourage using an evolution-based strategy instead, you can use the router to add a prefix to all routes, or just use a custom URL including the version prefix by passing it as the first parameter of the #[ApiResource] attribute (but we need to document that better)."
1:30 - as soon as I got here and saw that attribute, it all clicked. I just went "yooooo" outloud lol, using attributes to denote which models you want to make a CRUD API out of is genius.
หลายเดือนก่อน +4
I have been using API Platform for years with Symfony and loved it. I also like that it is compliant with Hydra standard - it might look strange at first but down the line I like the format, it is more descriptive, but you can also use normal json responses if you're not into it. Also adding /v1 to route is easily possible, at least I used that on one of projects on Symfony it was just a config setting.
As a developer whom worked a lot with Laravel it's very important to be able to do custom things. There's always something custom with either the business logic, existing database/codebase or other libraries from backend or frontend. Either we like it or not we don't live in a perfect world, so we always need to be able to adapt the libraries we use.
excited for them to release attribute support. Very surprised it wasnt available out of the gate. I know they have a some solutions merged with their 4.0 branch, but not actually released yet
It looks very nice and you get so much with so little effort. However, I really hate that it is so closely tied to the models. I don't want every resource to be 1:1 mapped to my models. There needs to be some kind of layer between the models and the endpoints.
Nice to know for the simple update/create. Although I'm using V1 in the path of my biggest API project... Are there any filters or relationship parameters for the index/list endpoint?
most common way is to use l5-swagger package and manually write OpenApi annotations for controller methods, model resources etc. then it generates swagger ui.
@@virinom then you get an OpenAPI spec (which is indeed a must-have), but your API is still not following any battle-tested standard or open format such as Hydra, JSON:API, HAL or GraphQL (API Platform support all of them), you must be careful to update the OpenAPI definition when you change the shape of the objects, you must implement pagination, filtering logic, authorization rules etc by hand, and not forget to document them. Totally doable, but still a lot of infrastructure work while with API Platform you can focus on adding features that have business value.
I have followed your Mini CRM tutorial, and of course I want to develop the API for the mobile app. But from this video, I think API Platform is not the good choice because of the limitation and "weird way" you mentioned. So, what are the other good choice to develop the API for Mini CRM?
in laravel 11 i suffer to make api auth with sanctum , and i saw a vedio in ur channel talking about that they removed kernal.php and the index.php is the alternate and you press on the functions inside that class it goes to the implementation of that function and i tried to do that but with vscode it doesn't work
Allow me to ask a question outside the text 😅 Is it advisable to implement unit tests for standard operations, such as CRUD operations, in applications ؟
API Platform is almost a decade old and can handle all complex API logic, and most of the time automatically. The Laravel package is not as mature as the Symfony one, but as most of the code is shared between them, almost everything supported by the Symfony bundle also works with Laravel.
@kdunglas most users here are beginners or ppl looking for simple intros. It would be useful to see a real-life crud using the API platform beyond one model (1 to m). I hope to see that.
It looks good and great but can we add different methods? It only works for crud operation. Is it possible to add methods like getCustomerDetail or something? If it's possible, where do we write it? or did it detect from the controller methods?
Please, please if you're reading this: Api Platform is a good tool, but don't just expose your models to the world; once your API gets beyond the prototyping stage you'll regret how massively snarled the model will become. Use Dtos just like you would on a regular API
all i see everywhere is CRUD stuff be let's be honest, most forms are not basic cruds. You make an api call that contains more levels of data on different levels. There have been very few apps in my 10 years + experience working in laravel there have been very few pure CRUDs
Creating APIs with Laravel is so simple that I found it somewhat unnecessary, an excessive abstraction for something that isn't complicated to do in vanilla Laravel.
API platform offers a lot of features from a few configuration. Your same model can be exposed as REST and GraphQL, with documentation, with pagination and filters. That's a lot of boilerplate that you get for free, so you can spend your time on advanced features.
Does your 'first impression' really boil down to copy-pasting two PHP attributes and hiding the created_at field? It seems like those 12 minutes could have been better spent reading the docs, including the Symfony part, to grasp the bigger picture instead of immediately questioning whether the 'member' key is configurable. It might help provide a more thorough and accurate review for everyone watching.
This entire project is an anti-pattern because it is a continuation of the mistaken philosophy that a REST resource is a DB table and that a model is just an interface for a DB table. Using models to describe endpoints instead of DTOs is really dumb. Using CRUD is simplistic to the point of being useless. Not using HyperMedia-based responses is dumb. Everything about it, at this release version, is useless
You should also look at the code, for example in the main directory of api-platform/laravel there is a `ApiPlatformProvider`, that in the register mehtod binds a Laravel Singleton called `ResourceMetadataCollectionFactoryInterface` - that has over 15 levels of nesting.
Honestly, I never understood this obsession with making CRUD APIs, haha. It never made sense to me. APIs usually have logic behind them, not just basic operations. Maybe it's useful when working with a JavaScript frontend, but even so, having something so abstract and rigid seems kind of 'silly' to me.
@@MichalKuzmickiAPI Platform has a lot of services because its internal code implements a lot of features, strictly follows SOLID principles, and prefer composition through constructor injection over inheritance or traits.
@@kdunglas it's not about using composition or not, but overcomplicating the code by creating a rotated 90 degrees Mount Everest from the abusive amount of layers that one class needs to fulfill. Over engineering dependencies is the 10th, unpublished Dante's Hell circle. Creating too much dependencies only slowly tightens a rope around the neck of the Open/Closed principle.
@@MichalKuzmickiAPI Platform has been entirely open source for 9 years, powers thousands of advanced APIs in production and has been improved over the years by around 1,000 people. We try to keep the code as simple as possible. If the design or the code can simplified without affecting modularity, extensibility, performance and security, we’ll be glad to merge your patch. « Talk is cheap, show me the code ».
Great comment from Kévin Dunglas himself, the creator. He replied on TH-cam, but the comment seems to be hidden (too many links?).
Here it is:
"API Platform for Laravel is still quite new, and the docs is being improved. We still have a lot of work to do on this side.
By default, we follow the @HydraCG API specification. It's where this "member" key comes from: hydra-cg.com/spec/latest/core/#collections
You can customize this key (by using your own class for collection, or by registering a custom normalizer), but it's not a good idea because then you'll not be in sync with the spec, and client tools supporting this spec may not work as expected:
- api-platform.com/docs/core/state-providers/
- api-platform.com/docs/core/serialization/
Alternatively, as mentioned in another comment, you can use another API format, such as JSON:API which may be "easier" at first to understand, or even just write a normalizer to have a totally custom format (which we don't recommend, using battle-tested standards or open API formats such as Hydra, GraphQL and JSON:API prevent a lot of foot guns): api-platform.com/docs/laravel/#content-negotiation
Supporting "Model::toArray()" is a good idea and should be easy to add. This will ease migrating from "API resources", we'll work on this. The recommended way to customize the fields in API Platform is to use the #[ApiProperty] attribute (you can change the name of the field, expose virtual fields, etc).
Regarding validation, I don't get your point. Are we missing some Laravel conventions that we should support? You can also add validation inline right in the attribute: api-platform.com/docs/laravel/validation/
For versioning, while we encourage using an evolution-based strategy instead, you can use the router to add a prefix to all routes, or just use a custom URL including the version prefix by passing it as the first parameter of the #[ApiResource] attribute (but we need to document that better)."
1:30 - as soon as I got here and saw that attribute, it all clicked. I just went "yooooo" outloud lol, using attributes to denote which models you want to make a CRUD API out of is genius.
I have been using API Platform for years with Symfony and loved it. I also like that it is compliant with Hydra standard - it might look strange at first but down the line I like the format, it is more descriptive, but you can also use normal json responses if you're not into it. Also adding /v1 to route is easily possible, at least I used that on one of projects on Symfony it was just a config setting.
As a developer whom worked a lot with Laravel it's very important to be able to do custom things. There's always something custom with either the business logic, existing database/codebase or other libraries from backend or frontend. Either we like it or not we don't live in a perfect world, so we always need to be able to adapt the libraries we use.
excited for them to release attribute support. Very surprised it wasnt available out of the gate. I know they have a some solutions merged with their 4.0 branch, but not actually released yet
Overall it looks good but fir advanced things we should dig deeper for it
you can get the typical Laravel api response by uncommenting jsonapi in the formats key in api-platform.php in config
It looks very nice and you get so much with so little effort. However, I really hate that it is so closely tied to the models. I don't want every resource to be 1:1 mapped to my models. There needs to be some kind of layer between the models and the endpoints.
Same, must be possible with symfony, guess we need to read the docs more
Nice to know for the simple update/create. Although I'm using V1 in the path of my biggest API project...
Are there any filters or relationship parameters for the index/list endpoint?
I guess you should read the docs to find out, or try it out yourself.
Great review. Could you mention alternative packages or approaches to update/enrich a current project with API features?
most common way is to use l5-swagger package and manually write OpenApi annotations for controller methods, model resources etc. then it generates swagger ui.
@@virinom then you get an OpenAPI spec (which is indeed a must-have), but your API is still not following any battle-tested standard or open format such as Hydra, JSON:API, HAL or GraphQL (API Platform support all of them), you must be careful to update the OpenAPI definition when you change the shape of the objects, you must implement pagination, filtering logic, authorization rules etc by hand, and not forget to document them.
Totally doable, but still a lot of infrastructure work while with API Platform you can focus on adding features that have business value.
There are many issues with laravel. It's amazing and powerful for small projects.
sir, can u just click that 'new chrome available' button on up right corner for an update. appreciate that... 😅
High-precision followers 😅
Ok fine, just did.
engagement comment.
I have followed your Mini CRM tutorial, and of course I want to develop the API for the mobile app. But from this video, I think API Platform is not the good choice because of the limitation and "weird way" you mentioned. So, what are the other good choice to develop the API for Mini CRM?
By manually coding it with Laravel?
@@LaravelDaily I see, thanks for the feedback
in laravel 11 i suffer to make api auth with sanctum , and i saw a vedio in ur channel talking about that they removed kernal.php and the index.php is the alternate and you press on the functions inside that class it goes to the implementation of that function and i tried to do that but with vscode it doesn't work
I use PhpStorm not vscode, sorry
Allow me to ask a question outside the text 😅
Is it advisable to implement unit tests for standard operations, such as CRUD operations, in applications ؟
Always beneficial doing that if you have enough time.
Ill stick to Apiato for now XD
Looks nice, but in real life APIs usually contains way more complex logic...
API Platform is almost a decade old and can handle all complex API logic, and most of the time automatically.
The Laravel package is not as mature as the Symfony one, but as most of the code is shared between them, almost everything supported by the Symfony bundle also works with Laravel.
@kdunglas most users here are beginners or ppl looking for simple intros.
It would be useful to see a real-life crud using the API platform beyond one model (1 to m). I hope to see that.
what is that mysql app that he's using ?
Table Plus
@@LaravelDaily RIP Sequel Pro...
It looks good and great but can we add different methods? It only works for crud operation. Is it possible to add methods like getCustomerDetail or something? If it's possible, where do we write it? or did it detect from the controller methods?
Good question, I didn't dig deeper, I guess you should read the docs to find the answer.
@@LaravelDaily Ya I will check more into it.
You should have a CustomerDetailController instead
Please, please if you're reading this: Api Platform is a good tool, but don't just expose your models to the world; once your API gets beyond the prototyping stage you'll regret how massively snarled the model will become. Use Dtos just like you would on a regular API
all i see everywhere is CRUD stuff be let's be honest, most forms are not basic cruds. You make an api call that contains more levels of data on different levels.
There have been very few apps in my 10 years + experience working in laravel there have been very few pure CRUDs
API Platform implements the REST architectural style as well as the RPC style through GrahphQL. Both styles go far beyond simple CRUD.
Creating APIs with Laravel is so simple that I found it somewhat unnecessary, an excessive abstraction for something that isn't complicated to do in vanilla Laravel.
API platform offers a lot of features from a few configuration. Your same model can be exposed as REST and GraphQL, with documentation, with pagination and filters. That's a lot of boilerplate that you get for free, so you can spend your time on advanced features.
Does your 'first impression' really boil down to copy-pasting two PHP attributes and hiding the created_at field? It seems like those 12 minutes could have been better spent reading the docs, including the Symfony part, to grasp the bigger picture instead of immediately questioning whether the 'member' key is configurable. It might help provide a more thorough and accurate review for everyone watching.
That's why it's a "first impression" and not a "review". But noted for the future.
Not much support for Laravel, if you look deep in docs it tells how to do for Symphony but not for Laravel.
We're updating the docs to show examples for both frameworks everywhere, it will take some time to update all the pages but we're on it.
@@kdunglas That's good news! Thanks!
I see the Lambo car everywhere. What in the.... why do people start to associate a framework with a car... any car...
That cheesy car graphic almost puts me off using this at all!
I Love your vids, please, update your browser Povilas. :D:D:D:D
Updated
Naaaah. the core laravel is good in itself. Laravel had everything it needs to be a robust framework. Why use an extra package which is already there
This entire project is an anti-pattern because it is a continuation of the mistaken philosophy that a REST resource is a DB table and that a model is just an interface for a DB table.
Using models to describe endpoints instead of DTOs is really dumb. Using CRUD is simplistic to the point of being useless. Not using HyperMedia-based responses is dumb. Everything about it, at this release version, is useless
You should also look at the code, for example in the main directory of api-platform/laravel there is a `ApiPlatformProvider`, that in the register mehtod binds a Laravel Singleton called `ResourceMetadataCollectionFactoryInterface` - that has over 15 levels of nesting.
Honestly, I never understood this obsession with making CRUD APIs, haha. It never made sense to me. APIs usually have logic behind them, not just basic operations. Maybe it's useful when working with a JavaScript frontend, but even so, having something so abstract and rigid seems kind of 'silly' to me.
@@MichalKuzmickiAPI Platform has a lot of services because its internal code implements a lot of features, strictly follows SOLID principles, and prefer composition through constructor injection over inheritance or traits.
@@kdunglas it's not about using composition or not, but overcomplicating the code by creating a rotated 90 degrees Mount Everest from the abusive amount of layers that one class needs to fulfill. Over engineering dependencies is the 10th, unpublished Dante's Hell circle. Creating too much dependencies only slowly tightens a rope around the neck of the Open/Closed principle.
@@MichalKuzmickiAPI Platform has been entirely open source for 9 years, powers thousands of advanced APIs in production and has been improved over the years by around 1,000 people. We try to keep the code as simple as possible. If the design or the code can simplified without affecting modularity, extensibility, performance and security, we’ll be glad to merge your patch.
« Talk is cheap, show me the code ».