A case for frontend based UI annotations
We’ve started working with Fiori elements, it’s an exciting journey and I see lots of possibilities- and challenges ahead. It’s really a group effort where you need to involve everyone from the business, UX to the dev.
But one thing leaves me especially puzzled; in all examples and tutorials the CDS views are annotated with @ui-annotations, to control the UI of our fiori apps.
Except in the most simple cases this makes no sense to me. I’ve always believed, and still believe, that we should separate business logic from the UI.
The option would be to annotate the UI in the Fiori app, and I can see almost only advantages with this.
- You seperate UI logic from the business logic
- We can use CI/CD pipelines and GIT to version control and deploy our frontend. Although we all love our transport system this enables faster turnaround, better versioning and ability to easier peer review with Pull Requests
- Front end developers don’t have to learn a new skillset, they can work with well defined OData services.
- Guided Development in BAS helps alot for simple cases, and code completion with the rest
- No Dev-key needed in the backend systems for “simple gui changes”
- It’s much easier to write unit tests when we can test front ends with mock data. This is my pet peeve and an area where I feel the SAP community in general lags behind.
The only advantages I see with the CDS based approach is
- ABAP developers don’t have to learn a new toolset . The actual annotations are the same in CDS or the frontend, so the only difference is where to write the annotations, not how to write them
- You can transport both back and frontend together, avoiding dependencies between transports.
Please enlighten me why the CDS based approached seem to be favoured by SAP themselves.