/DHaven.Faux

Dotnet version of the Netflix Feign library

Primary LanguageC#Apache License 2.0Apache-2.0

DHaven.Faux

Lobby 3g77q1gu23cbsfu3?svg=true nuget package blue

NetFlix created a bunch of really useful cloud projects, all of which are Java based. Steeltoe OSS has made service discovery and a few other integrations available to the DotNet community. One glaring missing feature is an analog for Feign. This library intends to fill that gap. I’m only one guy, so I appreciate any help I can get.

What does DHaven.Faux do?

Given an interface to a web service with all the Mvc like attributes decorating the methods, DHaven.Faux will generate an implementation that calls the web service for you. It will even use Steeltoe.Discovery.Client to resolve the service for you.

Even better, this is integrated with Microsoft’s Dependency Injection framework so that you only have to add your interface, and Faux will generate the implementation.

The following interface:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

namespace Fortune_Teller_UI.Services
{
    [FauxClient("fortuneService")]
    [Route("api/fortunes")]
    public interface IFortuneService
    {
        // GET api/fortunes
        [HttpGet]
        Task<IEnumerable<Fortune>> Get();

        // GET api/fortunes/random
        [HttpGet("random")]
        public Fortune Random();
    }
}

Will have all the plumbing done for you so that you can use the service just like a standard CSharp object. (Appologies to Steeltoe, I adapted their starter example)

Using Faux in my Net Core Web App

All you need to do is register faux in your services startup:

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services.
    services.AddFaux(Configuration);

    services.AddMvc();
}

Using Faux in my applications without dependency injection

We get it, not every project actually needs dependency injection. It’s great we want to support it, but it’s just as important to support the less complicated way of doing things. For that, we have the FauxCollection class. It hides the dependency injection away from you, and allows you to use the services directly.

Note
if you are running unit tests you may need to add an anchor type to let Faux search within the assembly it belongs to. Anytime the entry assembly (test runners) loads your assembly dynamically, it’s something you’ll have to do. The AddFaux() above also allows you to do that.
var collection = new FauxCollection(typeof(MyTest));

var fortuneService = collection.GetInstance<IFortuneService>();

What does DHaven.Faux do right now?

DHaven.Faux generates the web service implementations for you at runtime. Alternatively, DHaven.FauxGen is a command line tool that will generate an assembly for you so that you can explicitly identify them and skip the compilation step at initialization time.

Note
it is important that the objects you use in your interface are objects that NewtonSoft.JSon knows how to serialize.

Generated Classes

If you want to enable looking at the generated source code for your implementation, you can control many aspects of the code in your appsettings.json file:

{
  "Faux": {
    "OutputSourceFiles": true,
    "SourceFilePath": "./faux-generated",
    "RootNamespace": "My.Application.Namespace",
    "GenerateSealedClasses": true
  }
}
  • OutputSourceFiles: true to write the generated classes to the file system

  • SourceFilePath: path to the directory you want the generated classes placed

  • RootNamespace: the namespace to put all generated code inside. It defaults to "DHaven.Faux.Wrapper"

  • GenerateSealedClasses: the default is true, sealed classes cannot be inherited from.

To prevent naming conflicts between your parameters and internal Faux code, all Faux variables are prefixed with the Kanji 仮 (kari). Kari is word that means "temporary". When it’s used as a prefix it also means "fake". It seemed fitting to use that particular character with English to represent internal variables in this project.

Contributing

Please add issues if there any problems, questions, or feature requests.

We need the CLA to protect the project and to protect you from legal implications. Feel free to fork, make changes, and provide pull requests.