Question: is there any point to use API platform or shouldn't Controller/User/* be built around REST resource then?

[danaki]

Despite the comprehensive documentation of API platform, it's not too user friendly especially for beginners. I've spend a day to figure out how to make my own custom controllers for some REST resources I had planned. And it appears for my real-life project which is far from no-brainer blog-with-comments web site API platform is just a useless dependency. Because when I build my application around REST resource concept some calls are declaratively described in API platforms decorations but some operations I have to override and put in separate controllers Creating Custom Operations and Controllers. I understand that I must keep entities slim and can't mix with controller code but if my application doesn't expose blogs & comments and majority of all REST calls are custom handlers, there's no point to use API platform at all, a FOSRestBundle will perfectly suit my needs, at least I'll have all my controller code in one place, not scattered around application.

I guess the same logic applies to your demo application, there's no need for dependency on API platform just for this:

/**
 * @ApiResource(
 *     shortName="User",
 *     collectionOperations={
 *         "get",
 *     },
 *     itemOperations={
 *         "get",
 *         "delete"={
 *             "controller"="App\Api\Endpoint\DispatchMessageEndpoint",
 *         },
 *     }
 * )
 */

because all your other controller code handling user actions lies in a completely different place and has nothing to do with API platform. I suggest either get rid of API platform or put these controllers under custom operations.

P.S. found your project because I don't like how FOSUserBundle is built and because there're no progress on it and it built on top bad technical decisions. As a Symfony developer one must either accept it or build his own user handling code with all these Oauth/JWT support etc etc reinventing bicycle all the time. I appreciate your work but vast majority of Symfony developers like me do not understand in DDD and all these domain/document/projections/buses terminology followed by the huge amount of interfacing code makes my bald scalp wrinkling and my brains boiling. I've read the blue book and DDD-php-book twice and took a little from both. Could you please be so kind to write the documentation for complete beginners like me, starting with terminology and decisions you have made. Blog posts are definitely not enough. I even do not understand why you needed the ElasticSearch in your toy example with cars and I've read your posts 5 times and things are not getting clear after studying the source code. Please don't understand me wrong, I appreciate what you are doing and ready to learn but without clear understanding I can't depend on your UserBundle in my project. And since most of php developers are uneducated like me and not coming from enterprise/java/dotnet there will be no future for msgphp project unless you take the mission of teaching us concepts of DDD from the ground up.

[ro0NL]

Hi @danaki

majority of all REST calls are custom handlers, there's no point to use API platform at all, a FOSRestBundle will perfectly suit my needs

I think you underestimate API Platform a bit. The handler is a single piece in a bigger concept, i.e. hypermedia-driven REST APIs. Meaning GraphQL, a GUI, end-user documentation, linked data, jsonld, error handling, etc.

The only reason we define a custom delete handler is because we decouple from an ORM, and use a projection layer in between. This approach needs custom handling one way or another. Also you're not required to do so in your app.

at least I'll have all my controller code in one place, not scattered around application.

You can have multiple actions in a single class. Though multiple classes in a single namespace (single action controllers) is my preferred way and i do not think it's "scattered around".

Last but not least, whether you use API Platform or not, isn't decided by MsgPHP. It's a design-choice of your app and I bet you can get it to work with FosREST as well :)

vast majority of Symfony developers like me do not understand in DDD and all these domain/document/projections/buses terminology

Im totally aware of your point, but dont underestimate SF developers :)

Could you please be so kind to write the documentation for complete beginners like me

Yes :) but it's long term effort mostly. I'll try to add some every now&then.

And since most of php developers are uneducated like me and not coming from enterprise/java/dotnet there will be no future for msgphp project unless you take the mission of teaching us concepts of DDD from the ground up.

Point taken. I know i'm doing things the hard way yes :) Indeed the mission is teaching how to go from "RAD" to "enterprise", as you call it :) But for now the demo app is your best source of reference.

[ro0NL]

is there any point to use API platform or shouldn't Controller/User/* be built around REST resource then?

In the demo app Controller\User define regular web controllers whereas Api\Endpoint are the API controllers sort of speak. For using API Platform, the latter are not regular controllers and cant be used as such.

So yes there's a point; not having to deal with REST/protocol handling in API endpoints, just raw data.

[danaki]

GraphQL, Jsonld etc are not required for demo app as well as Elasticsearch (what is the added value?).

API platform allows you to skip repetitive task of building controllers around REST resource going straight from routing to entities. It's common for simple CRUDs and convenient for internal (micro)services, but in some cases it's too much hurdle to overcome. For example your registration/forgot/confirm controllers can be built around a /api/users REST resource which is absolutely necessary if you build a SPA -- all application calls become API calls. Thus you either leverage configuration that API platform offers you and route your entire application thru it or drop it and build using FOSRest or just with plain symfony, otherwise some of your controller logic will be here and there. It's not a big deal, but I prefer when my code doesn't look like a patchwork quilt.

[ro0NL]

what is the added value?

showing different flavor of doing things. Sure it's less approachable / more complex. But my personal goal is to built an app that scales, and this is my way of sharing :)

If you don't need Elasticsearch etc. that should be easy to strip out. It's not a MsgPHP requirement for sure. In that sense the demo app is based on my own requirements, yes. The issue is a lack a source of documentation to clarify design choices, alternative approaches, etc.

For being a demo app i want to show both regular web controllers, as well as API endpoints, CLI commands etc. Agree in practice (a SPA) can be API-only, sure :)

For example your registration/forgot/confirm controllers can be built around a /api/users REST resource

Thats on my list yes :) see #31

Thus you either leverage configuration that API platform offers you and route your entire application thru it or drop it and build using FOSRest or just with plain symfony,

API Platform makes it a bit more opinionated and may not be a requirement for your app. Feel free to use plain SF, FOSRest, etc. But IMHO a API Platform based demo app has more added value in general.

[danaki]

Keep going, you're doing a great job!