Feedback

[jorge07]

• Bridge/ApiPlatform is Infrastructure, should be inside infrastructure folder.
• Having the request stack in the application layer indicates the mix of UI and Application layer. Could be an indicator of a possible improvement https://github.com/jon-ht/api-platform-cqrs-es/blob/develop/src/Application/Command/CommandInputTransformer.php#L9
• With this naming I would expect a boolean https://github.com/jon-ht/api-platform-cqrs-es/blob/bc1cbee40fb8fc8af5dc851d7392c005fc78c934/src/Domain/User/Repository/CheckUserByEmailInterface.php#L12. Could be just because I used too and I'm in a different context.
• Serializer in the read model can be a HUGE bottleneck, use it carefully. If you end not using the serializer then align the specs becomes more difficult. But we're talking about a huge bottleneck specially when listing objects.
• For the main boilerplate I see difficult to justify add it to it, to be honest it adds an extra complexity that isn't required for most projects for the benefit of improve documentation and support multiple content-types. But I see the value here, my suggestion is improve this one to have it as an api-platform example.

Not all are bad news/feedback, there're things I really like, like the usage of validator, voters and many others. Nice work

[jon-ht]

Thanks a lot for your feedback ! I will fix your suggestions and I will continue to iterate

Actually I'm still discovering CQRS + ES pattern/architecture and I don't know if Ishould use 1 projection/view by query or if the same projection can be use multiple times (which justify serialization groups). Also, there is still a need of using groups when embedding credentials for example, I don't want to return hashed password in my view

Honestly, I had some struggle to get things working like I wanted, I agree with you about the extra complexity. Maybe my lack of experience with both APIP and CQRS/ES is the main point here

As a side note, I found another project which has an APIP bridge and it's inspired by your project

• https://github.com/botilka/botilka
• https://github.com/botilka/botilka-demo

Again, thanks for taking the time to review my code

[jorge07]

Actually I'm still discovering CQRS + ES pattern/architecture and I don't know if Ishould use 1 projection/view by query or if the same projection can be use multiple times (which justify serialization groups).

As always it depends if fits requirements or not. I can help you to save space and indexation time but in the other side can be less efficient for some queries. You've to measure per use case. But I generally go first for option 1.

Also, there is still a need of using groups when embedding credentials for example, I don't want to return hashed password in my view

Don't store hashed password in your view then. (goto 1, different use cases, don't really want to reuse projection. Reason" security)

Keep iterating, doing, redoing, and deleting. Assimilate all this concepts require start from scratch multiple times at the beginning