DEV Community: Guillaume Faas

Supabase .NET DevLog #9

Guillaume Faas — Tue, 08 Sep 2026 14:59:51 +0000

Welcome to our weekly log for the Supabase .NET SDK 🎉

Here we are, it finally happened: v8.0.0 has been published, and is now available!
Well, technically... v8.1.0 is the latest version now, as I've pushed a couple of features too.

This is an important milestone for the SDK and, with the major version behind us now, we'll get back to a much faster pace of releases.
I see it's being picked up by the community already, so please share your feedbacks!

So, if you want to see what's been packed in v8.0.0, here's the changelog.
If you're considering upgrading (you definitely should!), here's our migration guide. It's not a changelog: it lists all the breaking changes you might encounter during the upgrade, and how to address them.

I'm currently a bit away from the SDK itself, as I'm focused on content for now. Docs need to get updated, I'm writing a blog post to promote that version, as well as an introduction/tutorial post for the SDK as a whole.
TLDR: more writing for me!

And if you have any questions, you know where to ask.

Have a great day, and keep coding!

Supabase .NET DevLog #8

Guillaume Faas — Tue, 01 Sep 2026 13:58:44 +0000

Welcome to our weekly log for the Supabase .NET SDK 🎉

In last week's post, I mentioned I was attending a conference in Germany.

So...

I went to Gamescom in Cologne! Let me tell you, it was straight up insane... I've been to a lot of conferences in the last 4 years (around 50 events total) and I've never seen anything like it.

Anyway, I went there to meet indie developers and see how Supabase fits in that space. It was a fantastic experience, the community is very open and I was lucky enough to meet a studio (Loot Donkey) which showcased a game built with Supabase. The game's called Fool King; feel free to check them out!

Back to our SDK, each day brings us closer to the release of v8.0.0... which will happen this week!
I've integrated a couple of new features:

Full HTTP rework, enabling a better customization and override of the internal HTTP client
A new extension for dependency injection in ASP.NET
Support for publishable and secret keys
Automation on the quality gate (auto format, auto baseline update)

I'll try to fit a couple of more features before the release (best effort). If you want more details about what will get released, have a look here.

lately, I'd like to thank recurring contributors Bruno (@fresh55) and Diego (@diegofesanto) for their help with the SDK. Much appreciated!

Have a great day, and keep coding!

Supabase .NET DevLog #7

Guillaume Faas — Tue, 25 Aug 2026 16:21:05 +0000

Welcome to our weekly log for the Supabase .NET SDK 🎉

Last week, I continued tweaking the quality gate, especially regarding code coverage. I faced a nasty problem where coverage would sometimes differ when run locally vs. in a GitHub Workflow with async tasks. This creates a major problem when we expect the new coverage to be equal or higher... The good news if I solved it.

Anyway, I also added some QoL there too. Now, the baseline is automatically refreshed after a push on master, and style/format/naming guidelines aren't enforced anymore on a Pull Request. This step is now only a signal, because another workflow runs dotnet format on updated files after a push on master.
TLDR: less friction for contributors.

The major improvement has been the HTTP rework. Several developers complained (for good reasons) that there was no way to override the internal HTTP client used by the SDK, either for testing purposes or to define different options (connection pools, retry policies, etc). This had to be done across the board, and will be released along with v8.0.0 🎉

Finally, we're getting an increased flow of contributions and that's just fantastic to see 🙂

This week will be a bit quiet, as I'm attending a gaming conference in Germany. No spoilers, I'll share more next week 😉

Have a great day, and keep coding!

Supabase .NET DevLog #6

Guillaume Faas — Tue, 18 Aug 2026 04:55:06 +0000

Welcome to our weekly log for the Supabase .NET SDK 🎉

Following the monorepo migration, I started working towards the new major v8.0.0:

Upgraded all packaged to netstandard2.1
Enabled lockstep versioning to v8.0.0
Reworked the full package management, to guarantee uniform dependencies
Broader improvements on code styling, GitHub Actions, and repository structure
Migrated from Newtonsoft.Json to System.Text.Json for all packages
Started writing a proper migration guide for v8.0.0 (WIP)

If you want to stay tuned with what's coming in v8.0.0, have a look at this PR.

Priori to the System.Text.Json migration, I implemented a full suite of approval tests to guarantee that serialization didn't change. The codebase didn't have any, and we can't tackle such a migration without a safety net. If you wonder what Approval Testing is, just le me know. TLDR: Tests create a snapshot, and they keep getting evaluated against that snapshot. It guarantees models and queries keep producing the same output 😉

On top of all that, I created a proper quality gate for the SDK. It is executed by GitHub Actions and potentially local agents. As it's a script, it is deterministic! 🎉
It guarantees that things do not get worse (aka. stay stale or get better):

All tests (Unit/Contract, Approval, E2E)
Modified code must comply with format/style/naming guidelines specified in .editorconfig
Number of warnings cannot increase (goal is to get to zero and enable TreatWarningsAsErrors solution-wide)
No vulnerabilities on dependencies

From now on, this will be a hard requirement for all contributions, including mine. You can picture this as enforcing the "boyscout rule" to the whole codebase.

Stay tuned for more.
Have a great day, and keep coding!

Supabase .NET DevLog #5

Guillaume Faas — Mon, 10 Aug 2026 14:37:07 +0000

Welcome to our weekly log for the Supabase .NET SDK! 🎉

Last week marks a milestone for the SDK: the migration to a monorepo is now done!

Achievement Unlocked!

Everything can be found under the main repository supabase-csharp. Every package has its own project under packages/.
Nothing changes for you (yet): same packages, same public API.

Prior to that, I had to merge/fix all the open PRs for every package, as these couldn't get carried over, and transferred all the open issues too.

This is now the single place to contribute and fill issues, as other repositories have been archived.

Now that this has been dealt with, I'm focusing on the upcoming v8.0.0 and all the breaking changes that come with it. Wish me luck! 😅

Have a great day, and keep coding!

Supabase .NET DevLog #4

Guillaume Faas — Mon, 03 Aug 2026 13:36:31 +0000

Welcome to our weekly log for the Supabase .NET SDK! 🎉

I briefly mentioned I was working on the test suite in our previous entry. Well, I've got great news!
I made substantial progress on that: a small bump in code coverage (+11% average across packages), but mostly a significant bump on mutation score (+41% average across packages). If you never heard about mutation testing, the tldr is it represents how much you can trust your test suite, with a number: the mutation score. I digress, but let me know if you want to hear more about that.
This will help me build momentum on the SDK moving forward.

I also updated our SDK Reference, which hasn't been updated for more than two years, and made sure we exposed a C# snippet for every product in our docs.
The only caveat is nothing is automated on that front... I'll tackle that when we reach the monorepo.

Aside from those updates, I also closed a couple of PRs from contributors, and published a couple of releases.
I have to say the community have been responding so positively so far, it's just awesome 😎

We're getting closer to the monorepo migration. I'm currently planning this and getting together with other teams. My goal is to land this in the first half of August, and then the priority will be to work towards the new major version (hopefully soon).

Have a great day, and keep coding!

Supabase .NET DevLog #3

Guillaume Faas — Mon, 27 Jul 2026 12:29:46 +0000

Welcome to our weekly log for the Supabase .NET SDK! 🎉

Last week, I closed all the remaining critical fixes (P0s), which represented a total of 16 GitHub issues affecting developers.

Aside from the usual fixes, I also shipped OpenTelemetry which is a huge step forward for the SDK's transparency compared to the old debug logging.

We also got more releases this week as well:

Supabase v1.4.0
Supabase.Functions v2.2.0
Supabase.Gotrue v6.2.0
Supabase.Postgrest v4.4.0
Supabase.Realtime v7.3.0
Supabase.Storage v2.5.0
Supabase.Core v1.2.0

Remember folks: always keep your dependencies up-to-date, just sayin'

With the team, we also discussed the new versioning structure once we move to a monorepo: lockstep versioning, meaning all packages share the same version number.
One caveat is we'll have to start fresh at v8.0.0, so a +7 bump on the main package because of the odd version distribution we currently have. This will give us an opportunity to ship breaking changes at the same time to improve the DevEx.

I'm currently working on improving the overall test-suite, and I'll probably share metrics about that next week. This is a mandatory step for the SDK's future: we (the community, me included) need a test-suite we can trust, otherwise we can't safely add/update features.

This is probably the last step before the monorepo's transition.

Have a great day, and keep coding!

Supabase .NET DevLog #2

Guillaume Faas — Mon, 20 Jul 2026 06:00:37 +0000

Welcome to our weekly log for the Supabase .NET SDK! 🎉

Last week, I continued building our momentum on improving the overall experience with the SDK.
I released other critical fixes, as well as some improvements:

[Global] Fixing automated releases: The release process wasn't uniform across packages, and was also broken at places (especially on the umbrella package).
[Global] Fixed the telemetry: The telemetry is now consistent across packages but also more detailed. This will give us more details about who our users are and how they use our products.
[Global] Make Newtonsoft.Json 13.0.2 the ground version: We had to reduce the ground version of this dependency because of Unity 6 LTS. Indeed, Unity 6 ships with 13.0.2 and that version can't be bumped. This was locking out customers.
[GoTrue] Add missing OAuth2 state: We exposed a server-side state value, strengthening CSRF protection.
[Postgrest] Reference fields incorrectly included in UPDATE and DELETE queries: The behavior was only correct for INSERT, but failing for others. All we had to do was to cover Patch and Delete.
[Postgrest] Fixed enums serialised as integers: To avoid breaking existing data, this is something users must opt-in with ClientOptions.SerializeEnumsAsStrings.

I also did a lot of triage on all the repositories. Between the fixes/improvements and clearing outdated issues, 14 issues were solved/removed.

And all of this is now accessible for customers! 🎉 I published new versions for our entire SDK suite, the first one since a little while (addressing the dependency issues we mentioned in the previous post):

Supabase v1.2.0
Supabase.Functions v2.1.1
Supabase.Gotrue v6.1.0
Supabase.Postgrest v4.2.0
Supabase.Realtime v7.2.1
Supabase.Storage v2.4.2
Supabase.Core v1.1.0 That being said, the current release process is quite painful. I can't wait to move to a monorepo, with a single Release button 😅 It's a mandatory move if I want to speed up the pace of releases.

This week will follow the same trajectory: fixing existing issues, release them to customers, and keep sanitizing repositories before moving towards a monorepo.

Have a a great day, and keep coding!

Supabase .NET DevLog #1

Guillaume Faas — Mon, 13 Jul 2026 07:07:26 +0000

Welcome to the first entry of our weekly log for the Supabase .NET SDK! 🎉

Being still a new joiner in the company, I' still ramping up. I've been working on a plan to set up the direction of the SDK and prioritise what needs to be done first. I'm far from my full velocity, but there's a lot to catch up on.

I started with critical fixes, as the SDK was broken in some places:

[GoTrue] Auth kept dead sessions alive: when a refresh token got rejected, the client only cleared the session in one specific case.
[GoTrue] Email OTP sign-in and password reset were broken: SignInWithOtp and ResetPasswordForEmail had the PKCE verifier and challenge swapped (the SHA-256 hash was sent as the raw value, and vice-versa).
[PostgREST] Negation dropped in predicates: a silent issue where conditions like x => !(x.Name == "foo") were dropping the negation on Where, Update, and Delete. *** [PostgREST] Truncated DateTime:** reading dropped sub-second precision and UTC offset. Any round-trip was failing.
[PostgREST] Where improvements: ids.Contains(x.Id) now translates into an in filter rather than throwing, boolean columns (ex: x.IsActive) can be used directly, and comparing two columns to each other throws a clear error explaining why PostgREST can't do that.

It's worth to note that all of these changes are yet unreleased.

I will ship more critical fixes, and an improvement on the SDK's telemetry, before releasing a clean version this week. This will be a good opportunity to align dependencies, as the SDK doesn't reference all the latest versions of its sub-packages at the moment.

Once we stabilize the usage, the first milestone will be to migrate to a monorepo. Hopefully, soon.

Have a great day, and keep coding!

Supabase .NET DevLog #0

Guillaume Faas — Thu, 09 Jul 2026 11:50:56 +0000

Quick context if you haven't seen the latest news: I recently joined Supabase as .NET SDK Engineer.

Their .NET SDK is moving from community maintenance to official support, and I'm the main contributor moving forward 🎉

Especially with SDKs, I've always liked being engaged with developers: keeping them in the loop, but also collecting feedback.

So, I'm starting a weekly log!

Every week, I'll publish a short post about what happened on the SDK and where it's heading. Nothing fancy: just a few bullet points, some context when a decision deserves an explanation. That's it.

Fair warning: what I plan for a week won't always get delivered... because Life happens. Priorities move, issues show up, unexpected stuff, etc. So, don't take the plan for a promise.

If you're building with Supabase on .NET, this is also for you: tell me what's broken, what's missing, what's annoying. I have my own thoughts on that, but real pain points are better than assumptions.

Stay tuned and Happy coding ✌️

How I Removed 1,500 Lines of Boilerplate with a Source Generator

Guillaume Faas — Tue, 08 Jul 2025 08:53:41 +0000

In my previous blog post, I explained why I rely so heavily on the Builder pattern. It facilitates the creation of my requests, guiding developers when creating objects.

This wasn't just a personal preference. I ended up there because Builders ticked all the boxes:

Predictable object creation
Control over validation failure
Support for both mandatory and optional parameters
A way to guide users with a Fluent API

But implementing those builders came with a heavy cost: boilerplate code. Each builder added 50+ lines of code on average; for simple/repetitive ones, and much more for complex ones.
That doesn't scale well: multiply this by 30+ use cases, and you get a lot of code that you have to write and maintain.

Let's address that particular problem.

What do we need?

The problem is not the builder itself. It's how much (repetitive) code it takes to get there, especially when a lot of them are very similar.

What we want is a way to:

Declare which requests require a builder
Declare mandatory and optional properties
Add validation rules
Return a Result upon creation, that will represent either a Request or a failure

In short, we want the same benefits, but with zero boilerplate.

Of course, we will not be able to apply this everywhere; some builders are quite specific, with internal behaviors. The goal is to remove the basic ones, the majority of them.

What are source generators?

Source Generators let you write code that runs at compile-time and generates other code.

In our case, we can write a class to make the generator:

Detect specific attributes
Create a builder dynamically
Generate a .g.cs file with all the code

For us, it means fewer files to maintain, less code to write. We also keep a consistent pattern across the codebase.
Also, adding a new builder is completely transparent; all we have to do is to create a new class with the rightattributes, and "voilà".

The Basics

If you want to build something similar, here are the foundational steps you'll need to follow:

Create a new Class Library project for the Generator
Create a Generator class that implements IIncrementalGenerator
Use Roslyn's syntax/semantic model to detect classes and their attributes
Generate new .cs file using SourceProductionContext

Here's a minimal example of what the setup looks like:

[Generator]
public class BuilderGenerator : IIncrementalGenerator
{
    public void Initialize(IncrementalGeneratorInitializationContext context)
    {
        var structDeclarations = IdentifyBuilders(context);
        context.RegisterSourceOutput(structDeclarations,
            (productionContext, structSymbols) =>
            {
                structSymbols.ToList().ForEach(symbol => GenerateSourceCode(symbol, productionContext));
            });
    }

    private static void GenerateSourceCode(INamedTypeSymbol structSymbol, SourceProductionContext productionContext)
    {
        var generatedCode = ... // Generate the builder's code
        var fileName = $"{structSymbol.Name}Builder.g.cs";
        productionContext.AddSource(fileName, SourceText.From(generatedCode, Encoding.UTF8));
    }
}

We'll walk you through the building blocks in the next section.

Under the Hood

Here's how I structured the generator.

I have four attributes:

"Builder" which will decorate a struct, marking them as requiring builder.
"Mandatory" which will decorate a property, marking it as mandatory.
"Optional" which will decorate a property, marking it as optional.
"Validation" which will decorate a method, used to validate the request.

The generator will find all structs marked with Builder...

private static bool HasBuilderAttribute(SyntaxNode node) =>
    node is StructDeclarationSyntax declaration && declaration.AttributeLists
        .SelectMany(syntax => syntax.Attributes)
        .Any(syntax => syntax.Name.ToString() == BuilderAttribute);

private static IncrementalValueProvider<ImmutableArray<INamedTypeSymbol>> IdentifyBuilders(
    IncrementalGeneratorInitializationContext context) =>
    context.SyntaxProvider
        .CreateSyntaxProvider(
            static (node, _) => HasBuilderAttribute(node),
            static (context, _) => GetStructSymbol(context)
        )
        .Where(symbol => symbol is not null)
        .Select((symbol, _) => symbol)
        .Collect();

And fetch properties marked as Mandatory or Optional.

private static IEnumerable<MandatoryProperty> GetMandatoryProperties(INamedTypeSymbol structSymbol) =>
    GetMembersForAttribute(structSymbol, MandatoryProperty.AttributeName).Select(MandatoryProperty.FromMember);

private static IEnumerable<IPropertySymbol> GetMembersForAttribute(INamedTypeSymbol structSymbol,
    string attributeName) =>
    structSymbol.GetMembers().OfType<IPropertySymbol>()
        .Where(member =>
            member.GetAttributes().Any(attribute => attribute.AttributeClass?.Name == attributeName));

When all the data is gathered, we proceed to create our Builder, line by line:

Our using statements
The namespace
Interface declarations
Our builder
etc...

We're essentially creating the entire file ourselves, as a string:

public string GenerateCode()
{
    var code = string.Concat(this.GenerateUsingStatements(),
        this.GenerateNamespace(),
        this.GenerateInterfaceDeclarations(),
        this.ExtendTypeWithPartial(),
        this.GenerateBuilder()
    );
    return FormatCode(code);
}

private string GenerateUsingStatements()
{
    var builder = new StringBuilder();
    builder.AppendLine("using Vonage.Common.Client;");
    builder.AppendLine("using Vonage.Common.Monads;");
    builder.AppendLine("using Vonage.Common.Validation;");
    var parameters = type.GetAttributes()
        .First(attr => attr.AttributeClass!.Name == "BuilderAttribute")
        .ConstructorArguments;
    if (parameters.Any())
    {
        parameters.First().Values.Select(value => value.Value?.ToString()).ToList()
            .ForEach(value => builder.AppendLine($"using {value};"));
    }

    return builder.ToString();
}

private string GenerateNamespace() =>
    string.IsNullOrEmpty(type.ContainingNamespace?.ToDisplayString())
        ? string.Empty
        : $"namespace {type.ContainingNamespace.ToDisplayString()};\n\n";

private string GenerateInterfaceDeclarations() =>
    string.Concat(this.GetBuilderInterfaces().Select(builderInterface => builderInterface.BuildDeclaration()));

// ...

Example: from Request to Builder

You'll find below an example: VerifyCodeRequest, which allows us to verify a 2FA code with our [Verify (https://developer.vonage.com/en/verify/overview) API.

This is the code from my initial request:

namespace Vonage.VerifyV2.VerifyCode;

[Builder] // This request requires a builder
public readonly partial struct VerifyCodeRequest : IVonageRequest
{
    [Mandatory(1)] // Code is mandatory, and second property to set
    public string Code { get; internal init; }

    [JsonIgnore]
    [Mandatory(0)] // RequestId is mandatory, and first property to set
    public Guid RequestId { get; internal init; }

    ...

    [ValidationRule] // ValidationRule for our builder
    internal static Result<VerifyCodeRequest> VerifyCodeNotEmpty(
        VerifyCodeRequest request) =>
        InputValidation
            .VerifyNotEmpty(request, request.Code, nameof(request.Code));

    [ValidationRule] // ValidationRule for our builder
    internal static Result<VerifyCodeRequest> VerifyRequestIdNotEmpty(
        VerifyCodeRequest request) =>
        InputValidation.VerifyNotEmpty(request, request.RequestId, nameof(request.RequestId));
}

And this is the builder (VerifyCodeRequestBuilder.g.cs), generated by our source generator:

using Vonage.Common.Client;
using Vonage.Common.Monads;
using Vonage.Common.Validation;

namespace Vonage.VerifyV2.VerifyCode;
public interface IBuilderForRequestId
{
    IBuilderForCode WithRequestId(System.Guid value);
}

public interface IBuilderForCode
{
    IBuilderForOptional WithCode(string value);
}

public interface IBuilderForOptional : IVonageRequestBuilder<VerifyCodeRequest>
{
}

public partial struct VerifyCodeRequest
{
    public static IBuilderForRequestId Build() => new VerifyCodeRequestBuilder();
}

internal struct VerifyCodeRequestBuilder : IBuilderForRequestId, IBuilderForCode, IBuilderForOptional
{
    private System.Guid requestid;
    private string code;
    public VerifyCodeRequestBuilder()
    {
        this.requestid = default;
        this.code = default;
    }

    public IBuilderForCode WithRequestId(System.Guid value) => this with
    {
        requestid = value
    };
    public IBuilderForOptional WithCode(string value) => this with
    {
        code = value
    };
    public Result<VerifyCodeRequest> Create() => Result<VerifyCodeRequest>.FromSuccess(new VerifyCodeRequest { RequestId = this.requestid, Code = this.code, }).Map(InputEvaluation<VerifyCodeRequest>.Evaluate).Bind(evaluation => evaluation.WithRules(VerifyCodeRequest.VerifyCodeNotEmpty, VerifyCodeRequest.VerifyRequestIdNotEmpty));
}

You probably noticed a couple of other things:

Our builder is in the same namespace as our request (Vonage.VerifyV2.VerifyCode), making it transparent for people who uses our code. They don't know, and they don't need to know, that the builder has been automatically generated.
We also extend our partial Request to add a static method Build() to initialize the builder with Request.Build()

Finally, here's a usage example:

var request = VerifyCodeRequest.Build()
    .WithRequestId(Guid.Parse("68c2b32e-55ba-4a8e-b3fa-43b3ae6cd1fb"))
    .WithCode("123456789")
    .Create()

In my case, my builders were already thoroughly tested before I introduced source generators. I used my test suite to guarantee that no builder's public api changed in the process, making sure that not a single breaking change was introduced.

Testing

Talking about testing, it's relatively straightforward.

You need to initialize your source generator (BuilderGenerator is the generator we created earlier), run the generation and compare the result with your expectation:

private static string GenerateCode(string inputCode)
{
    var compilation = CSharpCompilation.Create(TestNamespace, [CSharpSyntaxTree.ParseText(inputCode)],
        [MetadataReference.CreateFromFile(typeof(object).Assembly.Location)],
        new CSharpCompilationOptions(OutputKind.DynamicallyLinkedLibrary)
    );
    var driver = CSharpGeneratorDriver.Create(new AttributesGenerator(), new BuilderGenerator());
    driver.RunGeneratorsAndUpdateCompilation(compilation, out var outputCompilation, out _);
    return outputCompilation.SyntaxTrees.Last().ToString().Trim();
}

[Theory]
[InlineData("...")]
[InlineData("...")]
[InlineData("...")]
[InlineData("...")]
[InlineData("...")]
public void VerifyCodeGeneration(string sample)
{
    var inputCode = File.ReadAllText($"Files/{sample}_Input.txt").Trim();
    var expectedGeneratedCode = File.ReadAllText($"Files/{sample}_Expected.txt").Trim();
    Assert.Equal(NormalizeLineBreaks(expectedGeneratedCode), NormalizeLineBreaks(GenerateCode(inputCode)));
}

Each test data focuses on a specific feature.
For example, here's my input file when testing a mandatory property with a validation rule:

namespace Vonage.TestProduct.TestRequest;
using Vonage.Common.Validation;

[Builder]
public readonly partial struct MyRequest : IVonageRequest
{
    [Mandatory(0)]
    public string Name { get; internal init; }

    [ValidationRule]
    internal static Result<MyRequest> VerifyName(MyRequest request) =>
        InputValidation.VerifyNotEmpty(request, request.Name, nameof(request.Name));
}

And here's the expected output that I will compare to the generator's output:

using Vonage.Common.Client;
using Vonage.Common.Monads;
using Vonage.Common.Validation;

namespace Vonage.TestProduct.TestRequest;
public interface IBuilderForName
{
    IBuilderForOptional WithName(string value);
}

public interface IBuilderForOptional : IVonageRequestBuilder<MyRequest>
{
}

public partial struct MyRequest
{
    public static IBuilderForName Build() => new MyRequestBuilder();
}

internal struct MyRequestBuilder : IBuilderForName, IBuilderForOptional
{
    private string name;
    public MyRequestBuilder()
    {
        this.name = default;
    }

    public IBuilderForOptional WithName(string value) => this with
    {
        name = value
    };
    public Result<MyRequest> Create() => Result<MyRequest>.FromSuccess(new MyRequest { Name = this.name, }).Map(InputEvaluation<MyRequest>.Evaluate).Bind(evaluation => evaluation.WithRules(MyRequest.VerifyName));
}

Resources

Everything I shared above is publicly available.

Whether you'd like to verify I'm not lying, see the entire implementation or take some code, please yourself; it's all open-source code.

SourceGenerator project: https://github.com/Vonage/vonage-dotnet-sdk/tree/main/Vonage.SourceGenerator
SourceGenerator test project: https://github.com/Vonage/vonage-dotnet-sdk/tree/main/Vonage.SourceGenerator.Test
VerifyCodeRequest: https://github.com/Vonage/vonage-dotnet-sdk/blob/main/Vonage/VerifyV2/VerifyCode/VerifyCodeRequest.cs
VerifyCodeRequest tests: https://github.com/Vonage/vonage-dotnet-sdk/blob/main/Vonage.Test/VerifyV2/VerifyCode/RequestBuilderTest.cs

Wrapping up

With source generators, I was (so far) able to remove roughly 1'500 lines of repetitive code without making compromises on functionalities, nor any change in my builder's public api. It is also much easier to add new builders now: a couple attributes on a request, and we're ready to roll.

The next step is to iterate on my source generator to support more advanced use cases.I already handle more specific use cases that I didn't detailed above, like

Optional Booleans which defines a default value and exposes an explicit method to change the state, like default is true, and "Disable" sets the value to false. This improves the experience overall by making the intent explicit, instead of relying on true/false values.
Optional values with default which allows setting default values for Optional properties.

For sure, I won't be able to replace all my builders; but being able to substitute standard ones is already a big win.

I hope you learned something today.
Happy coding, and see you soon!

During presentations of "Throw exceptions... away from your codebase", I've been asked a lot "Why I use so much on the Builder pattern?". So, I just wrote a post about it. On the menu: Immutability, Parsing, Validation, and Fluent APIs.

Guillaume Faas — Mon, 17 Feb 2025 06:11:05 +0000

Guillaume Faas

Feb 13 '25

Why I use (and abuse) the Builder pattern

#dotnet #monads #design #programming

7 min read