One of our services, S1, is responsible for serializing metadata of users/tenants which is later consumed by other downstream services. This stack is limiting for us, because the S1 service and downstream services are constrained to use the same version of the metadata libraries.
To address this issue, we decided to use multiple versions of the metadata libraries within S1, by shading them to appropriate packages, say metadata.current and metadata.next. However, this way the serialized object refers to the new package names of the metadata libraries, i.e. metadata.current and metadata.next.
This leads to a failure when deserializing the metadata object from the downstream services because they still refer to the original metadata libraries, and not the shaded ones. The downstream services would only consume a single metadata object, dependent on the metadata library version that we provide via the resource files.
We were pursuing the option to create empty traits for the shaded metadata libraries, deserialize the object and then copy the object over to the original metadata library. However, this would be realistically difficult given the number of classes inside the metadata library.
We are looking for ways to solve this problem, on how we can deserialize the metadata object without introducing the shaded metadata libraries in their scope. A few of our ideas that we thought of are as follows, although we are not sure if they are feasible and/or reliable eventually:
- Modify the binary serialized object to refactor the package names inside it based on a regex pattern
- When serializing the object, modify the package name (somehow) so that the downstream services can consume it without any issues.
Any leads or comments on this problem would be helpful and are welcome. Thanks <3