How to: have one class per endpoint - instead of one applicationservice with all the endpoints

[gentledepp]

The Problem

We have a lot of experience with aspnetboilerplate. Our main problem is/was, that applicationservices tend to get bloated and too big, because we add all the service methods to them.
This still seems to be the "best practice" in abp.io.

public interface IBookApplicationService
{

Task<BookDto> GetBook(Guid id);
Task<UpdateBookResponseDto> UpdateBook(Guid id, UpdateBookDto request);
Task<CreateBookRequestDto> CreateBook(CreateBookDto request);
....
}

However, we would like to have one class per endpoint.

The only way to achive this at the moment is to use a library like MediatR like so:

public class BookApplicationService : AppService, IBookApplicationService
{

         public Task<BookDto> GetBook(Guid id)
         {
                   var response = _mediator.Send(new GetBookRequest(id));
                   return response.ToDto();
         }   

}

This, however is far from ideal, as it requires us to add yet another layer of DTOs to the mix:
We have the DTOs that are fed into the application service.
And then we need to convert them to the Request and Response "Dtos" for MediatR.
I would like to avoid this.

Now with MinimalAPI, there is a new framework that does exactly what we seek for: FastEndPoints
However, it does not bring any of abp's functionalities that we so rely on.

The Question

Is there a way to achieve a "one class per endpoint" approach with ABP?
It would be great if it worked like this:

• write application services with a single method
• mark these with a special attribute, so that they show up in Swagger in the same group and appear to belong together
• have the code generation spit out combined interface for all applicationservices using the same name (name attribute!) so that for C# and JS clients those services appear to be a single service.

The pros would be:

• we can scale our code better. Every "app service endpoint" gets only the stuff injected that it needs
• this makes it much easier to write tests too
• we could add another endpoint to the same "name" group in a totally different module

Alternatively, does anyone have experiences with integrating FastEndPoints to abp?

[gentledepp]

After fiddling around with the code and debugging abp a bit, I guess I found a solution.

The goals were

1. to make the code more maintainable by splitting app services to one service per request (or app service endpoint)
2. At the same time, I wanted to group them together for swagger
3. and to be able to combine them to a single interface to use it in blazor

Now starting from a fresh layered abp solution:

abp new Acme.BookStore -u blazor -csf

... I created multiple dummy endpoints for handling books.

For each request/method added a separate interface in .Application.Contracts like so:

    public interface IGetBookEndpoint : IApplicationService
    {
        Task<BookDto> GetAsync(Guid id);
    }

    public class BookDto
    {
        public Guid Id { get; set; }
        public string Name { get; set; }
    }

Notice that the interface must implement IApplciationService or the Auto API Controllers feature will not work.

This class is then implemented in the typical manner in .Application:

    [ControllerName("book")]
    public class GetBookEndpoint : BookStoreAppService, IGetBookEndpoint
    {
        public Task<BookDto> GetAsync(Guid id)
        {
            return Task.FromResult(new BookDto
            {
                Id = id,
                Name = "Dune"
            });
        }
    }

One thing to note here is the ControllerName attribute.
I use this to name the controllers for the OpenApi/Swagger documentation and ensure that I can group endpoints together.
So all the endpoints that belong to the topic books get this attribute on top.

By default, this does not do anything at all. In order to apply this ControllerName, I added the following logic to the BookStoreHttpApiHostModule in the .HttpApi.Host project:

    private void ConfigureConventionalControllers()
    {
        Configure<AbpAspNetCoreMvcOptions>(options =>
        {
            options.ConventionalControllers.Create(typeof(BookStoreApplicationModule).Assembly, opts =>
            {
                // COMBINED: - added controllermodelconfigurer that takes the name for the controller from the ControllerNameAttribute
                opts.ControllerModelConfigurer = controllerModel =>
                {
                    var attr = (ControllerNameAttribute)controllerModel.ControllerType.GetCustomAttribute(typeof(ControllerNameAttribute), true);
                    if (attr != null)
                        controllerModel.ControllerName = attr.Name;
                };
            });

            options.ConventionalControllers.FormBodyBindingIgnoredTypes.Add(typeof(IRemoteStreamContent));
        });
    }

as you can see, my ControllerModelConfigurer tries to get the ControllerNameAttribute from any controller. If it finds one, it applies its name.
This allows us to see all the different endpoints in one group in swagger:

Now, the last goal was to still have a single interface to inject to blazor.
For this, I simply added an interface IBookEndpoints to the .Application.Contracts project which simply combines all the -Endpoint interfaces:

  // COMBINED: - created the interface that should be forwarded to the client:
  // it simply combines all the endpoint-interfaces to one single client-side interface
  // that way, while the endpoints are all separated (separate application service each)
  // the client sees a single interface that combines all the endpoints
  public interface IBookEndpoints : ICreateBookEndpoint, IGetBookEndpoint, IUploadBookCoverEndpoint, IDownloadBookCoverEndpoint
  {
  }

Now I simply injected it in some blazor component and called one of its methods.....
did not work:

The reason turned out to be, that the ApiDescriptionFinder of apb framework tries to find a controller type, that actually implements the requested interface:

And of course, our combined IBookEndpoints interface is not implemented by any controller! Just all of its sub-interfaces is!
As the ApIDescriptionFinder.FindActionAsync(...) method unfortunately is not virtual, I had to copy the whole code just to make the following minor modification:

    public async Task<ActionApiDescriptionModel> FindActionAsync(
        HttpClient client,
        string baseUrl,
        Type serviceType,
        MethodInfo method)
    {
        var apiDescription = await GetApiDescriptionAsync(client, baseUrl);

        //TODO: Cache finding?

        var methodParameters = method.GetParameters().ToArray();

        foreach (var module in apiDescription.Modules.Values)
        {
            foreach (var controller in module.Controllers.Values)
            {
                if (!controller.Implements(serviceType) &&
                    // COMBINED: for the dynamic api clients to work, we need to tweak this logic a bit, 
                    // because it expects all controllers to implement the service type.
                    // However, no controller actually implements our combined client interface! (actually, _nothing_ implements it!)
                    !(serviceType.IsInterface && serviceType.GetInterfaces()
                        .Any(i => typeof(IApplicationService).IsAssignableFrom(i) &&
                                  controller.Implements(i))))
                {
                    continue;
                }

as you see, I modified the condition to also accept the controller if

• the requested serviceType implements interfaces which themselves implement IApplicationService
• and the controler implements any of those base interfaces.

Now, I can use the IBookEndpoints interface in blazor while every of its methods is implemented as a separate applicationservice on the server! 🚀

What do you think of the approach? @hikalkan

It would be nice if I

• could opt-out of the client creation process for the IxxxEndpoint interfaces containing just a single method.
• would not have to copy the code of the ApiDescriptionFinder