Separate server controllers into a dedicated project and publish as package

Feature

Separate the BaGet controllers (and other associated code, like HttpRequestExtensions) into a dedicated project that will be built into a package and published.

Why?

It would be awesome if the BaGet controllers could be consumed as an independent package. This could allow one to compose his/her own server implementation without making changes to the main BaGet project, while still benefiting from any additions, improvements or bug fixed that will be made to this area of the code in the future. Examples for things this change will allow -

1. Creating custom default behaviors.
2. Easily integrating a different UI, or just dropping it all together.
3. Supporting other configuration methods/providers/conventions.
4. Cancelling the inclusion of auxiliary packages (e.g. AWS, Azure, EF) if they are not used.
5. Change hosting solutions easily (which is actually where I’m coming from).

My use case

I’m thinking of creating a serverless BaGet server over AWS. The idea is to have the server hosted as a Lambda function and exposed through AWS ApiGateway. Storage will be S3 based (which I saw is pretty much supported already), and I’ll create a PackageService and a SearchService that are based on AWS SimpleDB.

At the end you have a private BaGet server in the cloud that costs nothing except for the S3 storage for the packages (so, virtually nothing).

Cons

• A package that you can just import into an empty asp.net project and have a full server isn’t exactly something common, and maybe there is a reason for that (although it wouldn’t be the first).
• Could make the project a bit more complicated, at least at a glance (because the BaGet project, which is the server, won’t have any controllers in it).

Pros

• Would make it very simple to create custom BaGet based package feeds, which may get more people to use it on more platforms.
• Would make BaGet the only open source .net-core project that allows this kind of flexibility and extensibility, as far as I could find.

[WernerMairl]

Idea

To validate some idea around “BaGet modularization” i have created the following draft:

Environment

BaGet Instance running on Azure

• Azure App Service
  • Web Ap
  • OS: Windows
  • Publish: Code
  • Kudu Build with Source Control Type "GitHub)

Running on this Url: https://mybaget.azurewebsites.net/ Deployed from this Repo/Fork: https://github.com/WernerMairl/CustomBaGet/tree/feature/init/src

Approach

The repo does NOT contains BaGet source code but a minimalstic dotnet core csproj.

In this repo i have created a folder “References” that contains the compiler output from the PR created by Nimrod above plus a folder “BaGet.UI/build” that contains the (builded!!) frontend.

The assemblies in folder “References” are added to the csproj by using Assembly references (later NuGet-References)

the files in “BaGet.UI/build” are added by using a msbuild targe inside csproj (stolen and adopted from the original BaGet project) INCLUDING BaGet.dll /the main project currently not available as nupkg)

and… it works (hosted on Azure)

I have found a few issues/questions/new requirements for BaGet during this try. They are noted as issues in the repo https://github.com/WernerMairl/CustomBaGet

Waiting for a discussion with @loic-sharma (after holidays) if it is worth to follow the idea (and create some issue/pr here in the main project)

[nimrodolev]

Hi @WernerMairl,

Thanks for help!

I actually have the all of the code changes done (they were not pushed to my fork up until now). I can revert things a bit an send out a PR with just the empty new project, if that’s better - but seeing as there is no code change (just file movements) I’m not sure that’s actually needed.

As for help - what I’m currently stuck over (I didn’t have a lot of time to dig into this yet) is that some of the tests were broken after I made the change. This seems to be related to the SPA middleware not finding the SPA files, something with the hard-coded file paths (in the Startup.cs).

I pushed all of the current changes to my fork (here) - I’d appreciate it if you take a look and let me know if you think I should try to fix the broken tests or just revert things to a simpler state with just the new, empty, project and send out the PR a “simple” PR.

Thanks, Nimrod