Make the `Service` available as a NuGet package
aaronpowell opened this issue · comments
I'm wanting to host KM as a service alongside other services that I have in an application I'm building but currently there's no easy way to do this.
The easiest way to do this is to clone the KM repo and run the service from there, but that means it's disconnected from the project that you're trying to integrate with.
An alternative solution is to copy the Program.cs from the Service project into your own Minimal API project and add the appropriate NuGet packages, but that's a bit risky for if/when the APIs that it consumes change.
Proposal
Another option would be to make the part of the Service project that registers the appropriate services and creates the routes, into a NuGet package.
Then, you as the consumer of the NuGet package you would do builder.Services.AddKernelMemory() and use a fluent API to configure that with the AI services/memory store/etc., and then app.MappKernelMemory() to add the appropriate routes.
@aaronpowell I just merged a PR changing the structure of Service.csproj, who is now depending on nugets instead of having direct references to the code. "Service" is now basically 3 files:
- Program.cs: minimal.API
- ServiceConfiguration+KernelMemoryBuilderExtensions: parse appsettings.json and create memory instance
- HttpAuthHandler: custom code to handle API keys
and the project
<ItemGroup>
<PackageReference Include="Microsoft.KernelMemory.Core" Version="0.23.231224.1" />
<PackageReference Include="Microsoft.KernelMemory.Postgres" Version="0.3.231224.1" />
</ItemGroup>What about using Microsoft.KernelMemory.Core the same way that Program.cs does? Otherwise, what would the nuget offer?
Another option would be to make the part of the Service project that registers the appropriate services and creates the routes, into a NuGet package.
you would be ok injecting KM minimal API, injecting KM URLs, as they are, into your web service? I think that would work
Seems reasonable, I need to dig deeper into the code and how that might impact development. As you can see from #223 we're moving all extensions to packages, and Service to be a consumer of these, so I need to evaluate the change when all of that is in place. Thanks!
Yes, I see how that will make things more challenging, especially around the idea of "auto-wire up from config".
I actually think it'd be better to not have the auto-wire up mode in the Services.Core project that I proposed, because I'd imagine that if you're integrating into your own ASP.NET Core project you're probably going to care more about configuring the way KM is setup (reusing DB connections, sharing Azure creds, etc.) so just having a AddKernelMemory(memoryBuilder => { ... }) method would do the job.
I was about to raise a similar concern for the Service, keeping in mind that the Service code is copied on my side might evolve differently from your codebase based on different internal development constraints or timelines. Otherwise, maybe shipping the service as a docker container would make sense?
While being able to just use the source code and import it in my project seems to be interesting, it also opens the door for people to start modifying (both the service and potentially the SK plugin) to fit their need (or based on ignorance :) ). It also means, that once in a while, I need to sync code, figure out what changes are mine and which are yours... it also means syncing less often because it might become painful in the long run.
@SimonLuckenuik we published the Docker image a few weeks back, did you have a chance to try?
@SimonLuckenuik we published the Docker image a few weeks back, did you have a chance to try?
Thanks for the follow-up @dluc, considering I am using dotnet, I decided back then to use the serverless version for now.
Thanks for the PR, merged 👍
The nuget should be ready next week