Create project db context automatically for requested project

[myieye]

I'm not quite sure we want this, but I believe we could automatically create ProjectDbContexts scoped to a specific project per request by reading the requested projectCode from the path like so:
https://github.com/shaunluttin/asp-net-core-from-path-value-provider/blob/master/PathValueProvider.cs

If a service contains a combination of methods that access a specific project as well as ones that don't a potential solution would be to make ProjectDbContext a lazy service.

https://github.com/sillsdev/languageforge/blob/48332f3d2584fe05ac9cee44c906144c6d4d6019/backend/DataAccess/DataServiceKernel.cs#L28

[myieye]

@hahn-kev what do you think?

[hahn-kev]

I like the idea. The only downside I can see is that tests will need to jump through a few hoops to specify what project db they want for the test, but most of the time that can just be specified ahead of time.

As far as where the projectCode comes from. If we use a path value then it's fairly error prone as to what value gets used I'd imagine. In the code you linked it's referencing a key for the path value, but it's not really clear to me where that key is specified and how it determines what path value to pull from the URL. I think I'd much rather standardize on a query parameter projectCode=lf_test or a header like lf-projectCode:lf_test which can both be pretty easily read globally from the back end, and set globally from the front end as the URL is generally custom per request.

[myieye]

Something like this is what I was thinking. Apparently, services.AddHttpContextAccessor(); costs a bit.

        services.AddHttpContextAccessor();
        services.AddScoped<ProjectService>((provider) =>
        {
            var httpContextAccessor = provider.GetService<IHttpContextAccessor>();
            httpContextAccessor.HttpContext.Request.RouteValues.TryGetValue(PathConstants.ProjectCode, out var projectCode);
            return new ProjectService(projectCode);
        });

    // GET: api/Project/5
    [HttpGet($"{{{PathConstants.ProjectCode}}}")]
    public string GetProject(string projectCode)
    {
        return "value";
    }

[hahn-kev]

Yeah that makes sense.

So does that mean we need to make sure we specify that on the path for every endpoint? Or can we do that at the controller level?

I'm fine with using the context accessor, we'll use it for other things anyway.

I would probably create a project context class which is what determines the project name from the http context, and then inject that context class into the project service. That way for tests we can easily inject the project name. This also means if we need to inject new services into the project service we don't need to rewrite the service creation.

[myieye]

The more I've thought about this the more I think it just adds unnecessary complexity, so I'm closing it.

[myieye]

I guess I thought it would be confusing if the projectCode parameter was just ignored, because it was magically honoured somewhere else, but now I've gone full circle.

I think we'd also want to inject the "project-context" into some custom middle-ware to verify that the user is authorized to access the requested project-code.
https://learn.microsoft.com/en-us/aspnet/core/security/authorization/customizingauthorizationmiddlewareresponse?view=aspnetcore-7.0

[hahn-kev]

That sounds good to me. It should be pretty simple just verify that they have a claim for that project id in the jwt.

[myieye]

I branched #15 off of this issue to implement the first couple of steps.

Then, I started injecting the project-context into our data-access layer and it felt weird.
We'd end up with something like this:

public class ProjectDbContext
{
    private readonly MongoClient _mongoClient;
    private readonly ILfProjectContext _projectContext;

    private string CurrentProjectCode
    {
        get
        {
            if (_projectContext.ProjectCode == null)
            {
                throw new InvalidOperationException($"{nameof(ILfProjectContext.ProjectCode)} can only be used in the context of individual projects.");
            }
            return _projectContext.ProjectCode;
        }
    }

    public ProjectDbContext(MongoClient mongoClient, ILfProjectContext projectContext)
    {
        _mongoClient = mongoClient;
        _projectContext = projectContext;
    }

    public IMongoCollection<Entry> Entries()
    {
        return GetCollection<Entry>(_projectContext.ProjectCode, "lexicon");
    }

    private IMongoCollection<T> GetCollection<T>(string projectCode, string collectionName)
    {
        return _mongoClient.GetDatabase($"sf_{projectCode}").GetCollection<T>(collectionName);
    }
}

The caller of Entries() needs to know if there's a "current-project", which feels awkward.

I'm not sure if it would be much better in the service layer, but probably a bit at least. Although the data-access layer is where we'll actually use it the most.

We could just fly with the code above and see where it takes us. Maybe it's not confusing 🤷...then again maybe it is.

[hahn-kev]

Yeah that is frustrating.

We could just push the issue to the front end by using a header and then just require that header for most requests (excepting the user profile page for example). Then we always have a project context for a request because the URL doesn't determine if it's set or not. We can just document in the API that you always need to set the project code header. This would also be easier for the front end to just inject into all http requests, rather than injecting into each individual URL.

[myieye]

@hahn-kev Ultimately, the project-code is part of the resource path/identifier, so it feels more conformative to keep it in the URL. 🤔 hmmm...