Is using tag numbers in the code - anti-pattern?

[Yan Zaitsev]

Hi, 
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.

I was not able to find a similar usage of protobuf structures. We found devs using descriptors and sending whole descriptor models to work with dynamic messages, or using FieldMask for filtering.
Using the whole descriptor sounds overkill for this purpose.
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?

[Yan Zaitsev]

On the client
When we recursively parse the View Structure and see some `id` (aka tag number) key. We trying to find it in Backend response like `data[tagNumber: 11] as bytes` and merge with the current view (aka Text in the example).

[Em Rauch]

I think it's hard to tell all the details from the message, but it seems like you're creating some new form of extensions, perhaps combined with the known pattern of "overlay messages" (which is where a client schema is maintained with a perfect strict subset of fields of the serverside schema, which permitting round tripping of the data to/from the server without those fields being included in the client shipped schema).

It seems the specific pattern that you're describing isn't generally one known to the protobuf team as having any precedent, so it is unlikely to have any prior established decision about it being a known antipattern.

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/97e3a1b2-539c-4d0f-96c4-477390b49d5an%40googlegroups.com.