spring-cloud-streamspring-cloud-stream-binderspring-cloud-stream-binder-kinesis

Confusing messaging regarding the future of Spring Cloud Schema Registry


Here, it's explained that "starting with 3.2.x release of Spring Cloud Stream, we stopped shipping the schema registry clients (artifacts such as spring-cloud-schema-registry-client) as part of Spring Cloud Stream." If this is true, then can someone please explain the existence of the spring-cloud-stream-schema-registry-client project in a new repository location with commits made in the last week (vs. the old one located here)?

So, my question is what is the future of this project? Will it or will it not be supported in the future? We heavily rely on both the spring-cloud-schema-registry-client and spring-cloud-schema-registry-server projects. I am hoping that based on what I am seeing, the code has a new repository location and will continue to be supported in the future. I've had to make changes as described here to get our code working again after updating our Spring Cloud Stream annotation-based code to Spring Cloud Stream functions for the reasons outlined in this GitHub issue. This custom code is undesirable, and I'm hopeful that this will be addressed by the Spring team within an upcoming release.


Solution

  • I will give an explanation here, but the short answer is that the Spring Cloud Stream provided schema registry modules are back in the core Spring Cloud Stream project starting with 4.0.x version of Spring Cloud Stream.

    Code here: https://github.com/spring-cloud/spring-cloud-stream/tree/main/schema-registry

    Docs: https://docs.spring.io/spring-cloud-stream/docs/4.0.0-SNAPSHOT/reference/html/spring-cloud-stream-schema-registry.html#spring-cloud-stream-schema-registry-reference

    Originally, the schema registry modules were part of the core Spring Cloud Stream with built-in AVRO support. Since schema registry use cases were somewhat orthogonal to the core streaming use-cases, we thought it might be better for schema registry to move to its own repository under spring-cloud. The thinking was to evolve this top-level schema registry as a standalone registry that can be used in non Spring Cloud Stream contexts and include more supported formats etc. However, due to various reasons, although we moved it to the top-level spring-cloud org, our plans didn't really pan out and we found it hard to maintain it as a top-level project. Therefore, in 3.2.x version of Spring Cloud Stream, we stopped including the spring-cloud-schema-registry coordinates in the Spring Cloud Stream BOM, but the users were still free to use the registry directly in their applications. We were not going to continue work on this top-level schema registry project. We moved some AVRO message converter components into Spring-Cloud-Function to mitigate some use cases. I think this is the context around the issue you mentioned above.

    Ever since, we made the decision to drop support for Spring Cloud Schema Registry, we got enough feedback from the community that there are many situations in which people find these registry components as valuable to their applications, such as your situation. During this time, we were also working towards the 4.0.0 version of Spring Cloud Stream and we felt like this is an opportunity for us to resuscitate the schema registry efforts with certain caveats.

    Schema Registry components (server and client) are coming to Spring Cloud Stream proper with the spring-cloud-stream-schema-* in their artifact prefixes starting 4.0.x (as opposed to spring-cloud-schema-*).

    These components have a strict boundary of only supporting Spring Cloud Stream based applications and nothing else. This is very important since the spring-cloud based schema-registry project has the implication of usability outside of Spring Cloud Stream. By moving the code to Spring Cloud Stream repository, we are really trying to minimize the scope of the schema registry use cases we support.

    With this migration back to core Spring Cloud Stream repo we came in full circle, i.e. the schema registry components end up where they originally started their life. We feel that with this model, we can better support and maintain the components.

    As a side note, with this move, we removed that AVRO converter that was lifted and moved to Spring Cloud Function from Spring Cloud Schema Registry. I believe, this will fix the issue that you mentioned in the GH issue, starting from 4.0.x version of Spring Cloud Stream.

    If you could take the schema registry components we added in Spring Cloud Stream 4.0.x for a spin and give us any feedback, we will greatly appreciate it.

    Thank you!