-
Notifications
You must be signed in to change notification settings - Fork 3
Dependency Injection and Async initialization #194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Secrets | View in Orca |
57ae691 to
2551654
Compare
5b9e24a to
45280ba
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
| Infrastructure as Code | View in Orca | ||
| SAST | View in Orca | ||
| Secrets | View in Orca | ||
| Vulnerabilities | View in Orca |
Implements async initialization pattern with IHostedService for proper DI integration without blocking calls or GetAwaiter().GetResult(). Key Features: - Async initialization using Lazy<Task> pattern - Eager initialization via IHostedService (default) - Lazy initialization option for on-demand scenarios - Full backward compatibility with Connect.Local/Cloud helpers - Follows existing REST → Meta → gRPC initialization flow New Components: - WeaviateOptions: Configuration class for DI scenarios - WeaviateServiceCollectionExtensions: AddWeaviate() extension methods - WeaviateInitializationService: IHostedService for eager initialization - DI-friendly constructor: WeaviateClient(IOptions<WeaviateOptions>) Public API Changes: - Added: WeaviateClient.InitializeAsync() - manually trigger initialization - Added: WeaviateClient.IsInitialized - check initialization status - Added: EnsureInitializedAsync() - internal helper for async methods - Modified: GetMeta(), Live(), IsReady() - now await initialization Dependencies Added: - Microsoft.Extensions.Hosting.Abstractions 9.0.8 - Microsoft.Extensions.Options 9.0.8 Documentation: - DEPENDENCY_INJECTION.md - comprehensive DI usage guide - DependencyInjectionExample.cs - example demonstrating all patterns Benefits: ✅ No more GetAwaiter().GetResult() anti-pattern ✅ Works seamlessly with ASP.NET Core DI ✅ Thread-safe initialization with Lazy<Task> ✅ Keeps REST → Meta → gRPC flow for max message size ✅ Connect.Local() and Connect.Cloud() still work unchanged ✅ Proper async/await throughout Breaking Changes: None - All existing constructors and patterns continue to work - Connect helpers unchanged - WeaviateClientBuilder unchanged
Implements IWeaviateClientFactory for managing multiple Weaviate clients
with independent configurations. Each client can have different hosts,
ports, credentials, timeouts, and other settings.
Key Features:
- Named client pattern similar to IHttpClientFactory
- Each client has independent configuration
- Lazy initialization and caching
- Thread-safe client creation
- Automatic disposal of all clients
New Components:
- IWeaviateClientFactory: Interface for client factory
- WeaviateClientFactory: Implementation with lazy creation and caching
- AddWeaviateClient(): Register named clients
- AddWeaviateCloudClient(): Helper for cloud clients
Public API:
- IWeaviateClientFactory.GetClient(name): Get client synchronously
- IWeaviateClientFactory.GetClientAsync(name): Get client asynchronously
Extension Methods:
- AddWeaviateClientFactory(): Register the factory
- AddWeaviateClient(name, configureOptions): Register named client
- AddWeaviateClient(name, hostname, ports...): Helper for local clients
- AddWeaviateCloudClient(name, endpoint, apiKey): Helper for cloud clients
Use Cases:
- Multi-environment (prod, staging, local)
- Multi-region deployments
- Multi-tenant architectures
- Different databases/clusters
- Analytics vs operational databases
Documentation:
- MULTIPLE_CLIENTS.md: Comprehensive guide with patterns
- MultipleClientsExample.cs: Complete working examples
- DifferentConfigsExample.cs: Shows independent configurations
Example Usage:
```csharp
// Register multiple clients
services.AddWeaviateClient("prod", options => { ... });
services.AddWeaviateClient("staging", options => { ... });
services.AddWeaviateClient("local", "localhost", 8080, 50051);
// Use in service
public class MyService
{
private readonly IWeaviateClientFactory _factory;
public async Task ProcessAsync()
{
var prod = await _factory.GetClientAsync("prod");
var staging = await _factory.GetClientAsync("staging");
// Each has completely different config
}
}
```
Breaking Changes: None
- Single client pattern (AddWeaviate) still works
- Factory is opt-in via AddWeaviateClient
…er support
Adds headers and timeout parameters to match the Connect.Local() and
Connect.Cloud() helper API signatures, providing consistency between
DI registration and direct client creation patterns.
Changes:
- AddWeaviateLocal(): Added headers, defaultTimeout, initTimeout, dataTimeout, queryTimeout
- AddWeaviateCloud(): Added headers, defaultTimeout, initTimeout, dataTimeout, queryTimeout
Now these methods have the same configuration options as Connect.Local/Cloud:
```csharp
// Single client DI registration - now with full options
builder.Services.AddWeaviateLocal(
hostname: "localhost",
headers: new Dictionary<string, string> { ["X-Custom"] = "value" },
queryTimeout: TimeSpan.FromSeconds(120),
eagerInitialization: true
);
builder.Services.AddWeaviateCloud(
clusterEndpoint: "my-cluster.weaviate.cloud",
apiKey: "key",
headers: customHeaders,
defaultTimeout: TimeSpan.FromMinutes(1)
);
// Matches the pattern of:
var client = await Connect.Local(
hostname: "localhost",
headers: new Dictionary<string, string> { ["X-Custom"] = "value" },
queryTimeout: TimeSpan.FromSeconds(120)
);
```
Benefits:
✅ API consistency between DI and Connect helpers
✅ Full control over timeouts in DI scenarios
✅ Support for custom headers
✅ No need to use Configure<WeaviateOptions> for simple cases
Breaking Changes: None
- All new parameters are optional with sensible defaults
- Existing code continues to work unchanged
- Add AddWeaviateLocal(name) with default localhost:8080 configuration
- Add AddWeaviateLocal(name, Action<WeaviateOptions>) for custom configuration
- Add AddWeaviateLocal(name, hostname, ports, ...) with full parameter support
- Add equivalent AddWeaviateCloud(name, ...) overloads for cloud clients
- Mark old AddWeaviateClient() and AddWeaviateCloudClient() as obsolete
This provides a more intuitive API where users can write:
services.AddWeaviateLocal("local-rbac");
services.AddWeaviateLocal("local-test", options => { ... });
services.AddWeaviateCloud("prod", "my-cluster.weaviate.cloud", "api-key");
Reorganized the Example project to make all examples easily accessible: - Added interactive menu in Program.cs to choose which example to run - Support for command-line arguments to run specific examples directly - Moved original example code to TraditionalExample.cs - Renamed Main() to Run() in MultipleClientsExample and DifferentConfigsExample - Created comprehensive README.md with: - How to run each example (interactive or command-line) - Detailed overview of all 7 examples - When to use each pattern - Prerequisites and troubleshooting - Common patterns for ASP.NET Core and background services Examples now available: 1. Traditional - Basic usage with Connect.Local() 2. Dependency Injection - ASP.NET Core-style DI 3. Multiple Clients - Working with multiple named clients 4. Different Configs - Per-client custom settings 5. Configuration - Reading from appsettings.json 6. Lazy Initialization - On-demand client creation 7. Connect Helper - Backward compatibility Run interactively: dotnet run --project src/Example Run specific: dotnet run --project src/Example -- di
The DependencyInjectionExample requires Microsoft.Extensions.Hosting for Host.CreateDefaultBuilder() but the package reference was missing from the project file.
…eamline async initialization
45280ba to
08d2360
Compare
g-despot
approved these changes
Dec 2, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduce an async initialization pattern and dependency injection support for the Weaviate client, ensuring non-blocking operations. Implement a factory for managing multiple named clients with independent configurations. Enhance existing methods for consistency and add comprehensive documentation and examples. No breaking changes introduced (maybe?).