magic.library - Tying Magic together

This project helps you to wire up everything related to Magic. Normally you’d use it simply like the following from your startup class in your .Net 6 Web API project.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using magic.library;

namespace magic.backend
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        IConfiguration Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {
            // Initializing Magic.
            services.AddMagic(Configuration);
        }

        public void Configure(IApplicationBuilder app)
        {
            // Initializing Magic.
            app.UseMagic(Configuration);
        }
    }
}

However, you can also take more control over how things are actually wired up, by instead of using the “do all methods” called AddMagic and UseMagic, invoke some of the specialized initialization methods, you can find below.

The above methods is basically what the AddMagic method actually does, and they’re extension methods of IServiceCollection, that can be found in the magic.library namespace. Similar alternatives to UseMagic can be found below.

If you use these methods instead of the “do all methods”, your motivation would probably be to replace one of these methods with your own implementation, to exchange the default wiring, by (for instance) using a “virtual database based file system” by creating your own service implementation of for instance IFileService from “magic.lambda.io”, or use a different logging provider than the default, etc. If you wish to do this, you’d probably benefit from looking at what the default implementation of your method does, to understand the requirements from your method. Doing this is very powerful, and allows you to change the way the system behaves by default - But is also definitely considered an “advanced exercise”.

Exceptions handlers

Magic allows you to provide a custom exceptions handler on a per folder level. This overrides the default exception logic with a custom exception handler expected to be named “exceptions.hl” and found within the folder hierarchy where an HTTP invocation is resolved. For instance, if you wish to create your own exception handler for a specific module called “foo”, you can create an exception handler file called “/files/modules/foo/exceptions.hl”, and expect this file to be invoked every time an unhandled exception occurs, anywhere inside of your “foo” folder. This allows you to transform an unhandled exception, such as for instance localising it or customising it in any ways. Your custom exception handler will be invoked with the following arguments.

You can return a “transformed” exception from your exception handler, returning the following arguments, that will end up becoming the response object returned to the client.

The default exception handler can be found in “/files/exceptions.hl”, which will be invoked if no custom exception handler is declared further down in your folder hierarchy.

Project website for magic.lambda.library

The source code for this repository can be found at github.com/polterguy/magic.library, and you can provide feedback, provide bug reports, etc at the same place.

The projects is copyright of Aista, Ltd 2021 - 2023