Support chat for http://getprooph.org/ - official announcement: https://www.sasaprolic.com/2018/08/the-future-of-prooph-components.html
https://github.com/prooph/pdo-event-store/releases/tag/v1.14.0
1 reply
Hey, I'm thinking about a revival of prooph/event-sourcing but in a totally new way and it would be nice to get some feedback regarding the idea:
@sandrokeil had the idea to create a plugin for Cody (https://youtu.be/0FAgsPNqUV4) that generates framework agnostic domain model code: aggregates, value objects, messages, handlers, ... from a prooph board event map.
One reason to abandon prooph/event-sourcing was that it creates a framework dependency in your business logic. Something you don't really want. So instead you should use the package as inspiration only. But what if you could have a code generator, that generates all the glue code for you in the namespace of your choice?
- Value Objects
- Event Sourced Aggregates
- Commands
- Events
- Repository Interface
One can then connect the result with the framework of their choice. We think about prooph/event-store and Ecotone packages that can be used in combination to also generate framework related glue code (e.g. repository implementation, PHP8 attributes for Ecotone, ...)
Would you be interested in such a package?
Let's try it like this:
Usually developers are lazy. They try to automate repeating tasks and make their life easier. That's the key idea behind Cody as well.
Once you've found rules and conventions how to organize your code base, you'll do the same coding over and over again:
Create this class here, configure message routing there, set up an API endpoint, map data to VOs, define a contract (e.g. OpenAPI/AsyncAPI files) and so on. Isn't that boring?
Why not automate the boring parts? Writing the automation logic is a purely technical and depending on how crazy you want it to be also a challenging task. Something developers usually like. If you write and maintain the logic yourself would you still say it's magic?
@darrylhein good point. The context is super important. For companies with multiple teams all working with the same basic set up and maintaining software over a long period of time, framework decoupling is much more important than for smaller single team projects. A framework often influence the way how problems are solved in code. what works good today, can become a huge problem tomorrow when you want to scale (technically and in teams size)
Another good reason for decoupling is much cleaner business logic that is easier to understand and change over time.
But a framework agnostic domain model means:
more glue code required to make it work with your current framework of choice. But if you automate glue code generation as well as parts of the domain model code itself then you have a win-win situation.
if it is possible to have a generator that can update the code with my changes mixed in later, I'd probably be more interested
that's actually the case. It works like rector or a code sniffer. In rector you have those rules to upgrade parts of the code to a new PHP version. It also modifies your code without destroying it. Cody can do the same. If a VO exists already, Cody does not touch it! But if you want to add a new interface and/or method to all VOs, Cody can easily do that while keeping the original implementation in place.
we are maintaining a single low-time project (ever since starting to use prooph :)), so no need to upgrade multiple things, just making sure things keep on running / evolve with least effort :) ( Also, no hostility meant, I am being honest but not judging, there absolutely is a value of what you suggest)
when I talk about magic, I mean magic in code. I like stupid code. I like obvious code. I spent way too much time of my life debugging / figuring out why something magically does not work (any kind of magic routing / loading / ... ). I prefer repetitive over magic.
When we (team) implement new features, the basic setup is the stuff that takes the least time. Setting up read models / projections is what takes the most time (although repetitive but way more time consuming). That's the place where I personally would like to cut effort (esp since we use json functions and these are a PITA).
The good thing about automation is: if it works once, it'll always work for that case. You save time and reduce the risk of silly mistakes made by developers who are bored to do the tasks.
Most bugs I produce are the result of boring work. When I'm 100% focused on the task, my code usually works. With or without tests ...
If I have to map data back and forth, write validation logic by hand etc. it happens more often that a bug slows me down. A spelling mistake for example. Of course most of the time I fix the bug even before committing the code, but it's still a waste of time. You know like wondering for an hour why the hell it's not working just to find out that you did a spelling mistake in a mapping ...
But, yes automation is great – use it all the time. I'm the Rector, CS, etc train.
But, I don't think automation > framework coupling.
There are apparently thousands of companies coupled to, all sorts of things. I don't know that if the team gets larger they're less likely to be coupled. From my experiences (in multi-billion $ companies), they were using an awful lot of coupling. It made it easier for them to hire.
But, in the end, it's a just a choice to decide at what level you uncouple at. If Prooph goes that (code gen) way, I'll have to see how it works and go from there.
@silviuvoicu
maybe not just some opinionated suggestion are what you need, but also an mvp, working example, you know, go to your customer and ask/communicate with them :), either company or developers.
yeah, that's the point.
We're in direct exchange with our customers and we demonstrated one real world result of what is possible with prooph board + Cody in a live demo session at EventSourcing.Live last year. BTW the recording is now available on youtube: https://www.youtube.com/watch?v=lKB8-l9MEvs
There you can see the potential incl. fully working FE and BE code generation.
We could release the Cody implementation used in the live demo as an example. But my fear is that people would think it's the only way to work with Cody:
Cody itself is an API. It gives you access to your design on prooph board. Now it is up to you, what you want to do with that information. Generate some boilerplate code, scenario tests or a fully working low-code platform.
Is this too low-level for developers? Because it requires too much learning effort?
I'd love to share the excitement with you. But I try to figure out what would be the best way to do that.
- how do you handle validation (as it's skipped in the video)?
- how do you handle logic (be it validation, read model logic, aggregate logic) that you cannot define in json (i.e. we have complex internal aggregate states etc..)? obviously I can add it in the generated code later on, but how would later updates on the board (and code re-generation) affect my custom added code?
- how does the board handle "branches", think of different features worked on in parallel? how would branches be merged on the board level?
- as we have to maintain our software for years (current installment for ~10 years), we have seen a lot of these tools come and go ;) not being maintained is one thing as long as they remain in our build chain, but SaaS really breaks away forcing you to look into alternatives.. I know the code generated is on our git, but it still breaks established workflows. any plans to bring the board as a self-hosted / run version? ideally as something I can define as a dependency on the project and start like "any other code generator" (just with a graphical UI instead of CLI).. running locally also would be preferred from a security & confidentiality perspective
Before I answer your questions I'd like to stress the point that the answers related to code generation are specific for the set up shown in the video. That said, you can build your own code generation logic the way you want/need it. @sandrokeil Put a lot of effort into an abstraction layer on top of PHP Parser to simplify code generation. It's organized in libs for specific tasks. Check out the github orga Open Code Modeling
Validation:
We translate metadata on prooph board to JSON Schema. I've skipped validation in the video to save some time but here are two examples from the same app:
{
"shorthand": true,
"ns": "/Common",
"voNamespace": "/Common",
"schema": {
"userId": "string",
"givenName": "string",
"familyName": "string",
"roles": "/Common/Roles",
"email": "string|format:email"
}
}It's metadata for a UserInfo VO. As you can see the shorthand version of json schema is used (our own creation, we have a translator to real json schema) and we can type hint properties with definitions (other VOs in the code) and define json schema validation like "email": "string|format:email"
{
"shorthand": false,
"ns": "/Expose",
"voNamespace": "/Expose",
"schema": {
"type": "string",
"pattern": "^((eigentumswohnung(en)?-)|(condominiums-))[üäöÜÄÖßA-Za-z0-9-]+$"
}
}- Generate fully typed, immutable VO structures with self-contained data mapping capabilities (from/to native data) respecting the defined namespaces (ns, voNamespace) in the schema
- Generate JSON Schema based API contracts that are also used for input validation on API level
how do you handle logic?
As mentioned by @sandrokeil the code generation layer is designed in a way that it can modify existing code without breaking it. Thanks to PHP Parser AST. That said, the goal is not to define everything on prooph board. You design the flow of information, document structures and responsibilities. But business logic insight aggregates or read model logic insight projections is still done by the developer. Cody supports developers with boring tasks. It's a code monkey :) You should really try it! It's so nice to have all the boilerplate in place and just focus on the challenging parts like complex aggregate logic. Messages, VOs, API all ready to use. And the documentation is already in place! And can be used as a starting point for the next design iteration! All the litte things add up quickly to huge time saver. It's not only the one hour saved, by not writing boilerplate code by hand.
The feature in the video works out-of-the box because the Cody implementation used is designed for Event Engine and it generates some common defaults that make it possible to have the whole thing working without touching the code itself. But others features of that app also have hand written parts in use.
on a related note, https://event-engine.io/ does not resolve for me
3 replies
how does the board handle "branches"
above you see a feature tagged as "planned". It appears yellow on the board. That's how we design new features in an existing system. We also mark changed information or messages with hot spots and write down what will change.
I know the code generated is on our git, but it still breaks established workflows. any plans to bring the board as a self-hosted / run version?
Two things:
- we have this case already with allmyhomes. If prooph board would be taken down tomorrow they would run into a problem, because their dev workflow is somewhat depending on prooph board. I mean you can work with out of course, but it would slow down everything for a while (well, back to the situation before prooph board ;))
So we're currently designing a contract that protects our customers from that risk. It includes an option to buy a copy of the tool in case we stop the service for whatever reason.
And yes, we also offer self-hosted options. But they are more expensive.
ideally as something I can define as a dependency on the project and start like "any other code generator" (just with a graphical UI instead of CLI).. running locally also would be preferred from a security & confidentiality perspective
@fritz-gerneth That exists! Cody is open source and can be installed via composer. The free version of prooph board is hosted on github and requires no login at all! Everything that you do there happens only on your local machine within your browser. You can import/export boards etc. But without the SaaS version you cannot collaborate with your teammates (yet). We're working on making that possible in the free version as well. That should become available at some point in this quarter, but will have limitations. We still want to earn some money with the SaaS version :D
The free client is available here: https://free.prooph-board.com
@fritz-gerneth if you really want to try Cody, let me where you need support. A good starting point is the tutorial:
https://wiki.prooph-board.com/cody/php-cody-tutorial.html
It covers the absolute basics. @sandrokeil could support you in exploring the "Open Code Modeling" stuff and we could open source the Event Engine implementation shown in the video if that is of interest as well. But this is highly opinionated :D
just released: https://github.com/prooph/event-store/releases/tag/v7.7.0
special thanks for @gquemener and also thank you @netiul for reminding me to take care of this.
spread the word!
