I am developing a server-driven UI service in my company. I want to know your opinion on whether our approach is anti-pattern of protobuf usage or if it is valid usage even if it is not common.

Thank you for your time reading this long message!

All our APIs for Client(iOS,Android,Web) <-> backend are based on protobuf models, thats why we want to use protobuf for SDUI too.

We want to build a new service that will provide the View structure to the client, which has to be rendered. The client can cache only UI styling and layout, while another service provides the data for it.
Client app has to bind server data to view the structure. The client does not know the schema of the server response, except it is protobuf data.
View Structure and Backend data are protobuf models and use the same types – see examples below.

message Text {
 string label = 1;
  Color color = 2;
}
message VerticalStack {}
message HorizontalStack {}

/// Typical View Structure in protobuf representation
VerticalStack {
  spacing = 20pt
  children = [
   Text { 
     id: 11
     color: .white
    }
   HorizontalStack {
     children: ...
   }
  ]
}

Another service has to provide data for this view structure.

message BackendResponse {
  Text productTitle = 11;
}

BackendResponse schema is NOT known to the client.

We came with idea to use protobuf tag numbers for binding.
You can see that Text.id = 11 and BackendResponse.productTitle = 11

We built the autogenerated interfaces to safely set number 11 to the View structure and ensure that the backend response uses the property with number 11.

On the client
We recursively parse the View Structure and see id (aka tag number) key. We looking for data with same key in Backend response like data[tagNumber: 11] as bytes and merge with the current view (aka Text in the example).

The question of this post: even if it is not a common technique, is it known as anti-pattern?

These binding(tag numbers) numbers are used across the different code stacks:

• View protos are known to clients, backend and separate DSL repository (repo with View structures)

• Backend models are known to backend and DSL repository

• DSL repository is TypeScript code

• Backend is Go code

• Clients are Swift, Kotlin, TypeScript/JS

Can the concept of extensions or custom options help us somehow? Do you know more appropriate way?

I was not able to find a similar usage of protobuf structures. We found that developers use descriptors and send whole descriptor models to work with dynamic messages or use FieldMask for filtering.
Using the whole descriptor sounds overkill for this purpose as we don’t need access by name or other field attributes. ID number is auto-injected to DSL by our generators.