Decoupling front-end and back-end teams: a UI schema as a contract

BED-Con 2023 presentation

Transcript

1. Decoupling front-end and back-end teams: a UI schema as a contract Dr. Gerald Brose Akelius Technology
2. Background Akelius Technology technology provider for an international residential real estate group, including a forest property management providing services and solutions also to other companies In-house development –strategic choice: owning the applications –development HQ in Berlin
3. Project context „Property Catalog“ Mostly CRUD back-end application ~ 120 KLOC Java/Spring Boot/K8s/neo4j APIs for ~ 15 internal systems Source of truth for property master data Wraps ERP systems from different vendors in different countries –US, CA, GB (Yardi Voyager) –DK, DE, SE (Bolig, Incit Xpand, Immotion) –SE (ArcGIS, with forest data) –FR, CY (residential, replaced other ERPs!) All photos under CC0 public domain license
4. Project context High visibility: • 2 previous attempts at delivering this application failed! • Time to market an issue! Frontend policies: • SPAs required: Angular or React • No central frontend integration strategy • frontend developers in high demand internally
5. Team 1 project owner 1 tech team lead 2 senior devs (HTML/CSS, jQuery, Bootstrap, templating engines, …) 2 mid-level/junior devs Project focus: • integrating and harmonizing data models internationally • Data imports and synchronization • Internal APIs for applications • DB performance, multi-tenancy, data quality…
6. Important decision Build the front-end in the team? • Invest some time to learn Angular • Full control, no external dependency • But: quality and time-to-market? Or off-load to the central “portal app” team? • would deliver quickly • concentrate design expertise in the front-end team • But: introduce coupling and depend on another team’s priorities? Which option is easier to revert later?
7. Coupling between teams and projects • release schedules and sprint plans need synchronization • many internal API endpoints need to be published and documented • front-end developers need to be involved even for small tasks • back-end data model details might „leak“ into the front-end
8. Standard approach: define a contract „Property Catalog“ • declares and publishes • Java annotations on DTO classes as declarations • Reflection to generate and publish the schema GET /ui-schema?type=apartment „Portal application“ • consumes and renders • Implements a mapper JSON schema → Formly (~1KLOC + config)
9. Entity <X> x:X Ui-DTO <X> UI-schema type=x { X = {..} } Config services REST endpoints Schema service RestController <X> View Components (tables, forms, …) view model BE Service <X> FE DTO <X>
10. • Data model: named types with attributes parent-child relations • Navigation: entry point „property list“ • Actions: embedded links to GET & POST endpoints advice about permissions • structure: detail views, expandable sections, tables • content: ordered attributes in groups or in table columns labels and translations core concepts
11. hierarchy
12. Content
13. Annotations in DTO classes @EntityDTO(value = Apartment.class, ignoredFields = {„…"}) public class ApartmentDTO extends AbstractAssetDTO { @UiUpdateConfig(createable = true, editable = true, required = true, editableInCountries = {CountryCode.France, CountryCode.Cyprus}, creatableInCountries = {CountryCode.France, CountryCode.Cyprus}) @EntityField @DictionaryKeys(value = "apartment.name") private final Assignable<String> name = new Assignable<>(); @UiUpdateConfig(createable = true, editable = true, editableInCountries = { CountryCode.Canada, CountryCode.France, CountryCode.UnitedKingdom, CountryCode.UnitedStates, CountryCode.Cyprus}, creatableInCountries = {CountryCode.France, CountryCode.Cyprus}) @EntityField @DateBefore(attribute = "adminEndDate") @DictionaryKeys(value = "apartment.administrativestartdate") private final Assignable<LocalDate> adminStartDate = new Assignable<>();
14. action links
15. tables
16. • reduced coupling! • Not hard to build • relatively little maintenance effort Some preconditions, however… • data model is relatively stable • UI style is minimalistic Restrictions • Completely new UI features cannot be done without extending schema concepts • Some visibility constraints are currently hard-wired in annotations conclusion
17. Keeping things simple pays off! Putting the contract in the right place can allow a back-end team to • avoid playing politics just to ensure capacity • Deliver features without waiting for front-end changes • Isolate from frontend library wars, UI/UX discussions, and style guide changes Take-aways