Thank you for the insightful feedback. You are absolutely right—the current coupling between the core RPC pipeline and the observability stack is deep, particularly within dubbo-config-api and dubbo-registry-api.
I have considered the trade-off between refactoring existing modules and building a new lightweight core. While my initial proposal focused on refactoring to ensure seamless backward compatibility for the dubbo-all distribution, I agree that a 'clean-room' lightweight core might provide a more sustainable architectural foundation for cloud-native Dubbo. *Perhaps we could consider a hybrid approach:* Instead of just 'cutting' dependencies from existing modules, I could focus on extracting a *dubbo-core-minimal* module that contains only the absolute primitives (remoting, serialization, and basic SPI). This new core would serve as the foundation, and the existing 'heavy' features (Prometheus, complex metadata) would then depend on this minimal core as optional extensions. I would love to hear the community’s thoughts: Should the priority be on *cleaning up the existing tree* to benefit all current users, or *building a new parallel core* specifically for the next generation of lightweight/serverless use cases? On Tue, Apr 7, 2026 at 9:18 AM Rain Yu <[email protected]> wrote: > I have read your proposal, and it seems that you intend to make cuts to the > existing Dubbo modules. This is certainly a good idea, but they are tightly > coupled, and I don't think this will be an easy task. Perhaps it would be > better if we completely refactor a new lightweight RPC core module? > > RAGIRI Naga sunoj <[email protected]> 于2026年3月30日周一 16:44写道： > > > Dear Dubbo Developers and Mentors, > > > > My name is Sunoj Ragiri, and I am a Computer Science student writing to > > formally submit my proposal for GSoC 2026: *Apache Dubbo — Lightweight > > Refactoring*. > > > > After conducting an in-depth study of the Dubbo 3.3 codebase, I have > > identified a critical "core tension" where the framework's organic growth > > into 99+ Maven modules has led to significant dependency bloat. > Currently, > > even a simple RPC consumer pulls in approximately 15 MB of shaded JARs > and > > over 100 transitive artifacts, including 6 metrics modules and Prometheus > > integrations as hard compile-scope dependencies. > > *Project Overview* > > > > My project aims to transform Dubbo into a truly lightweight, cloud-native > > framework through a systematic refactoring of the dependency graph. Key > > objectives include: > > > > - > > > > *Decoupling Observability*: Moving metrics and tracing from > > compile-scope to optional dependencies using a new MetricsBridge SPI > in > > dubbo-common. > > - > > > > *Lazy Initialization*: Deferring non-critical startup work, such as > > TypeDefinitionBuilder and MetricsReporterFactory, from eager bootstrap > > to first-use loading. > > - > > > > *dubbo-minimal Profile*: Creating a new distribution module that > > delivers core RPC functionality in under 5 MB with fewer than 30 > > dependencies. > > - > > > > *Performance Benchmarking*: Providing quantitative proof of > improvements > > in JAR size, startup time, and memory footprint. > > > > *Technical Strategy* > > > > I plan to leverage Dubbo’s existing ExtensionLoader and the > > @Activate(onClass > > = "...") annotation. This allows us to move coupling from compile-time > hard > > dependencies to runtime SPI discovery, ensuring that observability > features > > only activate if the relevant JARs are present on the classpath. > > *Timeline & Availability* > > > > I have outlined a detailed 13-week execution plan, starting with a > > comprehensive dependency graph analysis and ending with the final > > dubbo-minimal artifact and architecture documentation. I am available to > > contribute approximately 29 hours per week throughout the coding period. > > > > You can review my full proposal here: > > > > > https://drive.google.com/file/d/1_SKEgxDNwmFYgwt7JJbMaOSeuKm14hPR/view?usp=sharing > > > > I would greatly appreciate any feedback or guidance from the community > > regarding this proposal. > > > > Best regards, > > > > Sunoj Ragiri GitHub: sun-9545sunoj <https://github.com/sun-9545sunoj> > > >
