Proposal for Quarkus Extension - Azure Storage Queue - Working Prototype Available #150
Labels
feature
New feature or request
Comments
sarxos
changed the title
|
Hello @sarxos First of all, I'm sorry for late response as I was in vacation last week and just returned back this week. Your proposal is great and generally I like it which targets to enrich the Azure storage Quarkus extensions and purse cleaner code by reducing the duplicated code. Regarding to your |
|
Hi @sarxos , I have been trying to generate a native image of my Quarkus application that uses EvenHub & Storage Queue, however I have been running into below exception: I have been referencing the existing Azure Storage Blob extension, and have made necessary changes in my POM. |
|
Is there any news on this? Thanks! |
|
The initial thought is that both Quarkus extensions for |
|
@burl21 The idea proposed by @sarxos is great. |
|
Hello @burl21, sounds good. Looking forward to your contribution! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dear Azure Services community of Quarkiverse,
I've been working on implementing a Quarkus extension for Azure Storage Queue and have made good progress. I'd like to share my thoughts on the current state of my implementation and seek your input on the best way we can move forward to merge it into the official release.
Background
I've based my work on the existing Azure Storage Blob extension, which allowed me to quickly build a working prototype extension for the Azure Storage Queue. In most places, the prototype uses a copy of the code from the Blob extension to establish the basic functionality. The working prototype together with working integration tests and a bit of documentation can be found in my fork.
Current Status
The prototype is working rather well and meets the initial requirements for interacting with Azure Storage Queues. However, there are certain aspects of my implementation that are duplicated between the two extensions. In particular, the following components are duplicated in most places:
DevServicesConfigclassStorageQueueBuildTimeConfigclassDevServicesStorageQueueProcessorclassQuarkusPortAzuriteContainerclassSome might argue that a functional PoC is sufficient, but due to my strong inclination towards maintaining clean code, the absence of a suitable abstraction for the classes mentioned above is incredibly frustrating to me. 😉
Opportunity
I believe there is a valuable opportunity to deduplicate the code by extracting common components and making them more universally applicable. By doing so, we can achieve cleaner and more maintainable code while reducing redundancy between the Blob and Queue extensions (and most likely a new extension for Storage Table that may potentially be created in the future, since it would also use the same abstraction).
Proposed Refactoring
What I would like to propose would involve extracting the common components mentioned above into a shared dependency (either a new or existing one, e.g.
quarkus-azure-core-deployment), which would be utilized by both the Blob and Queue extensions (and most likely Table in future). After performing some preliminary exercises in this approach I found out that this would entail changes to the configuration paths, if we are willing to keep it clear, as well as some structural modifications to accommodate the new shared components.Challenge
It's important to note that extracting these common components and making mentioned changes would result in a break of backward compatibility within existing configurations. The reason lies mainly in the fact that we have a
blobfragment in theconnection-stringconfiguration path. When implementing my extension I did use the same approach and placed aqueuein the path as well. However, with the assumption that we have Blob, Queue, and most likely would have a Table extension in a future, we will end up with three different configuration paths to carry the same exact value:Similarily, we would end up with three, exactly the same Azurite containers running in dev mode, which is a complete waste of resources (ah, just thinking about this with my mere 16 GB of RAM, annoys me as hell). The only difference between these containers would be port number they exposes, specifically:
This sucks.
Solution
What I would like to do is to drop the
blob,queueortablefrom the connection string configuration path, and have it common between the extensions:While having a smaller configuration just for the ports, e.g.:
By doing so we can have only one configuration for
connection-stringand only one Azurite container instead of three separate ones. However, this would break backward compatibility, since, as you can see, the old configurations users use in the wild would become invalid.While I understand the significance of maintaining compatibility, I also believe in the long-term benefits of cleaner code and easier maintenance, which may outweigh this concern. But I'm at a crossroads.
Community Input
At this juncture, I would greatly appreciate the community's insights and opinions on how we can proceed. I'm seeking your thoughts on the following questions:
Your Feedback
I understand that this decision may have implications for the broader Quarkus Azure Services ecosystem, and I value your opinions on this matter. Please share your thoughts, concerns, or alternative suggestions regarding the direction we can take. I believe that any feedback in regard to this matter will help us make a well-informed decision that benefits the entire user community.
Thank you for your time and consideration.
The text was updated successfully, but these errors were encountered: