Is it a regular CRUD on the front-end if it is using Axon on the back-end?

#1

Hi all,

I am very new to the Axon framework and all the related stuff (DDD, CQRS, Event Sourcing).
After some exploring of the framework, the following question has arisen:
So, what about the front-end? Should it work as a regular CRUD application? or what?
Let’s say I will use Flutter at the front-end. Should this front-end work as a regular CRUD application? Or are there any other options?

Edit 1:
To clear my question.
If I am developing my front-end using Flutter to work on IOS and Android, I need my front-end app to work offline. So I need to save data on the local database in the device.
Of course, my front-end app will call REST endpoints of my Axon-based back-end.
Will my front-end app be a regular CRUD application that saves the final state of domain models? Are there any other options?
Thank you

#2

Hi Ahmed,

in a successful CQRS/DDD implementation, front-end most likely will end up following so called Task-based UI approach, where UI is designed in a way that it captures user’s intents and translate them into the commands.

So it depends on how you model the entire system, you could represent the giant form editing as a single command, which will pretty much look like a U from CRUD, or you could try to identify what user really intends to do and decompose this U into further commands (intention revealing actions).

1 Like
#3

Thanks for your reply Beka_Tsotsoria.
The Task-based UI link is useful.
I think I didn’t clear my question well. I updated it to be more clear.

#4

It’s hard to say exactly without specific use cases and the direction of dataflow, but answering the following questions might help.

Does the backend have some behavior? Does it need to react to the events that happened on the device (while it was offline) in some way? If not, it might mean that backend only serves as remote storage and in such a case simple CRUD (i.e. transferring the current state from device to backend) may work for you (assuming there’s no audit requirement).

If the backend has to react to the events, then why not borrow the idea from the well-known VCS tool - Git? You could explicitly model the changes made in the device as events, store them locally, and whenever the connection to the backend is restored, you could push the changes. It kinda reverses the roles though, the device acts as an EventStore where the backend, roughly speaking is some kind of a subscriber. If you were to code the native app in Java/Kotlin, perhaps you could have even used the dedicated AxonFramework on the device (I’ve never tried it, but I don’t see a reason why it may not work).