Can this package be used with Filament?

[parijke]

I was wondering if we can use event sourcing along with Filament

[rapkis]

I'm currently using event sourcing for one of my projects in production. I'm looking to create a simple administration panel for said project and was looking into multiple packages, one of which was Filament.

After reading their docs, it does seem like it could support Event Sourcing. Filament allows to customize the create, save and delete processes:

• https://filamentphp.com/docs/2.x/admin/resources/creating-records#customizing-the-creation-process
• https://filamentphp.com/docs/2.x/admin/resources/editing-records#customizing-the-saving-process
• The delete process customization was deprecated (link). They suggest the ->using() method in the Tables\Actions\DeleteAction, as far as I understand.

I believe you could simply override these methods and fire events instead.

Haven't tried much of this myself yet, as Filament isn't the only candidate for me. But I hope it helps you out :)

[felahdab]

Hi @rapkis .

Thanks for this short comment. I am starting a project which will use event sourcing. Your remark is obviously very useful.

Regards.

[rapkis]

I'm glad to hear it was helpful for someone! :)

As it's been over a year since then, I thought I'd share a quick update for anyone interested (TL;DR at the bottom):

Firstly, I still find event sourcing and its benefits valuable. However, we've opted to return to the conventional Laravel/CRUD architecture with FilamentPHP due to development speed considerations. While event sourcing has its merits, it's crucial to assess if it aligns with the needs of your specific project:

• Development with event sourcing is definitely slower. Many libraries, especially those tailored to Laravel, assume CRUD usage and may not be easily adaptable. For instance, FilamentPHP abstracts CRUD actions, which clashes somewhat with event sourcing. Although we've sacrificed development speed, FilamentPHP remains beneficial with its component library. If event sourcing were indispensable, I'd still pair it with FilamentPHP.
• Event sourcing poses challenges in fast-evolving projects. If your project's future isn't clear, adopting event sourcing prematurely could be problematic. Even though its extremely difficult to bring in event sourcing in an already existing project, I would still go this route. Businesses usually prefer to build fast and break fast. With event sourcing you have to think really hard and plan way more in advance to ensure that you're able to reuse that data in the future, ensure its structure doesn't change too much, ensure you're not storing too much or too little.
• Consider developer proficiency. Most developers are accustomed to CRUD architecture, making it challenging to find or onboard event sourcing proficient developers. This means long developer onboarding and probably lower quality or slow results.
• Lastly, evaluate if you'll fully utilize event sourcing benefits. Will you frequently migrate data? Do you need multiple projections? Will you replay events? Will you ever be "traveling in time"? Consider if these features are practical or merely appealing.

TL;DR:
Since the thread was created for FilamentPHP, here are my main recommendations:

• Opt for CRUD if your app's scale/growth/future isn't predefined. You can get event sourcing benefits manually (like logs libraries, DB migrations with custom scripts, etc.) and migrate later if needed.
• Choose event sourcing if your app's scope is defined, and you require its benefits consistently throughout the project lifecycle.

In conclusion, while event sourcing hasn't suited our current projects perfectly, it's been a learning experience. I believe it will be ideal for some future projects, and I encourage exploring new technologies to find the best fit for your needs.