DEV Community: Artur Kedzior

From 20+ Years of Building Software to ShipDotnet 🚀

Artur Kedzior — Thu, 04 Sep 2025 15:23:59 +0000

Over the last two decades, I've worked on more projects than I can count. Each new one was an improvement over the last sometimes because I learned from mistakes, other times because new tools or patterns became available.

But no matter how much experience I had, every project came with its own quirks. Different requirements, different client needs, different libraries, and platforms that kept evolving (or disappearing).

The Authentication Saga

Take authentication, for example. We knew early on it wasn't worth reinventing the wheel.

We started with IdentityServer, which was great until it became a licensed product and disappeared from the open-source space.

Then came ASP.NET Identity, but it quickly grew bloated with features we didn't need.

We tried Azure AD, but setting it up was a pain and supporting Apple ID logins was in the preview at that time.

Later, we moved to Firebase Auth, which worked until it didn't. When it went down for 6 hours last month, my clients lost 6 hours of sales. That's not the kind of reliability you can build a business on.

Another Pain Point: Spaghetti Business Logic

Another thing I kept seeing: developers scattering business logic everywhere. Massive services, unnecessary abstractions, code that didn't belong where it was. Debugging or extending features became a treasure hunt.

The Breakthrough

On every new project, I made small, incremental improvements. Over time, I pushed those improvements back into older projects too.

What I noticed made me very happy:

A rigid but sensible structure prevented over-engineering.

Developers stopped putting code in the wrong place.

The team spent less time on boilerplate and more time building actual features.

The result? Productivity shot up, and everyone was happier.

The Culmination: ShipDotnet

All those lessons, improvements, and scars from past projects led me to build:

... a proven foundation that today powers multiple multi-million-dollar companies.

It's not just code. It's a product-ready starter kit with the boring stuff already done, so you can focus on what makes your app unique.

Out of the box, ShipDotnet comes with:

✅ Authentication & Authorization

✅ Payments

✅ Multi-tenancy support

✅ Dashboard, Landing Page & Docs site

✅ Built-in CQRS + DDD patterns (easy to grasp in practice)

✅ AI integration

✅ Real-time data

✅ Dynamic roles

✅ Scalability from day one — grow without painful refactors

I wanted to build something I wish I had when I started all those years ago.

If you're an experienced dev, it gives you a battle-tested foundation so you don't waste time on setup.

If you're a fresh developer, it gives you a real-world look at how production software is built, you'll learn modern patterns, architecture, and best practices just by working with it.

👉 Check it out here: shipdotnet.com

If you enjoyed this post and want to stay updated, follow me on Twitter for the latest updates and check out my projects on GitHub.

Feel free to reach out with any questions or feedback.

Svelte and SvelteKit Explained

Artur Kedzior — Wed, 15 May 2024 20:57:32 +0000

I often read questions on Reddit such as:

How Svelte compares to X, Y, Z?

What do I need SvelteKit for?

How do I use it without SvelteKit?, I have my own existing backend!

In this article I will try to explain it all.

How Svelte compares to X, Y, Z?

First of all this is very subjective. I can only share my personal experience through a very long career building production stuff primarily in backend (C#) and front-end (Vanilla JS, jQuery, Angular, Vue, React and Svelte).

I always look for simplicity first because that's what makes me more productive.

My preference is Vanilla JS aka pure JavaScript for its performance, direct control over the code, deeper understanding of JavaScript fundamentals, simplicity, no dependency management, broad browser compatibility, educational value, and the extensive community and resources available.

Vanilla JS doesn't give me the power of reactivity. The more project grows the harder it becomes.

Angular, Vue, React and Svelte do!

My choice is Svelte because it is the closest to Vanilla JS out of all of the above while still offering amazing features out of the box.

Svelte is also compiled and it doesn't use Virtual DOM.

What do I need SvelteKit for?

SvelteKit is a framework built on Svelte, offering features like server-side rendering, static site generation, and seamless integration for building complex web applications.

In other words, SvelteKit lets you easily build, run, and test your Svelte application. There are many ways to build it:

Client + Server

You write your client code and server code in the same project, benefiting from using the same language. You get server-side rendering by default (SSR) and can host it in a single Node server instance (for example).

You choose where the code should be executed. For example, to execute the code exclusively on the server, you append the file name with server, i.e., +page.server.js.

You can also mark your server pages as static by configuring them to prerender. You can read more about it here.

To deploy it, you need:

A Linux server
A web server of your choice, i.e., Nginx, Caddy
Node.js

Static Client + API

You write your client code that talks to an API of your choice. This is perfect for things that do not need SEO, like admin portals, dashboards, etc.

All that is needed is a single-line config file where we tell SvelteKit to build the whole site as static. SvelteKit will produce an HTML+JS+CSS combo. Here, you need to host two sites: one with your API and another with your static site.

To deploy it, you need:

A Linux server
A web server of your choice, i.e., Nginx, Caddy
Whatever powers your API (e.g., mine runs on .NET 8)

Client + Server + API

This is the same approach as in point 1, except that you can still use the API of your choice instead of writing server code in JavaScript.

All that is needed is a single-line config file where we tell SvelteKit to use the node adapter.

Under the hood, something like this happens:

To deploy it, you need:

A Linux server
A web server of your choice, i.e., Nginx, Caddy
Node.js
Whatever powers your API

Here is a live example of this last method:

https://shipdotnet.com

Thank you for reading!

If you enjoyed this post and want to stay updated, follow me on Twitter for the latest updates and check out my projects on GitHub.

Feel free to reach out with any questions or feedback.

May the code be with you!

Building .NET 10 APIs with Zero-Setup CQRS and Vertical Slice Architecture

Artur Kedzior — Mon, 08 Jan 2024 22:54:20 +0000

The goal of this article is to introduce you to developer friendly way of building Web APIs and Azure Functions with .NET 10 applying CQRS and Vertical Slice Architecture.

After years of dealing with all sorts of systems Vertical Slice Architecture has become our only way of building web applications.

We will be exploring the open source library MinimalCQRS which purpose is to provide zero-setup / out of the box integration.

Let's jump right into an example and create MinimalApi endpoint that fetches order by id in 3 steps:

Install and register MinimalCQRS (formerly AstroCQRS) in MinimalAPI

dotnet add package MinimalCqrs

builder.Services.AddMinimalCqrs();

Create an endpoint

app.MapGetHandler<GetOrderById.Query, GetOrderById.Response>
("/orders/{id}");

Create a query handler:

public static class GetOrderById
{
    public class Query : IQuery<IHandlerResponse<Response>>
    {
        public string Id { get; set; } = "";
    }

    public record Response(OrderModel Order);

    public record OrderModel(string Id, string CustomerName, decimal Total);

    public class Handler : QueryHandler<Query, Response>
    {
        public Handler()
        {
        }

        public override async Task<IHandlerResponse<Response>> ExecuteAsync(Query query, CancellationToken ct)
        {
            // retrive data from data store
            var order = await Task.FromResult(new OrderModel(query.Id, "Gavin Belson", 20));

            if (order is null)
            {
                return Error("Order not found");
            }

            return Success(new Response(order));
        }
    }
}

In a single file we have everything it is required to know about this particular feature:

request
response
handler

You could easily skip Response and do:

public class Query : IQuery<IHandlerResponse<OrderModel>>
{
    public string Id { get; set; } = "";
}

app.MapGetHandler<GetOrderById.Query, GetOrderById.OrderModel>
("/orders/{id}");

However I like wrapping response model into Response root model as later I can easily add new properties without modifying the endpoint and changing much on the client consuming that API.

Ok so what the hell is IHandlerResponse?

It serves two purposes:

It enforces consistency with returning either Success or Error.
Internally it provides a way for callers such as Minimal API and Azure Functions to understand the response from a handler and pass it through.

Anyway, going back to the main subject:

Now let's say you want to do the same but with Azure Functions. All you need is a single line:

public class HttpTriggerFunction
{
    [Function(nameof(HttpTriggerFunction))]
    public async Task<HttpResponseData> Run([HttpTrigger(AuthorizationLevel.Anonymous,"get")] HttpRequestData req)
    {
        return await AzureFunction.ExecuteHttpGetAsync<GetOrderById.Query, GetOrderById.Response>(req);
    }
}

Yes, your handler doesn't and shouldn't care who calls it!

Now let's see how we would do order creation:

app.MapPostHandler<CreateOrder.Command, CreateOrder.Response>
("/orders.create");

public static class CreateOrder
{
    public sealed record Command(string CustomerName, decimal Total) : ICommand<IHandlerResponse<Response>>;
    public sealed record Response(Guid OrderId, string SomeValue);

    public sealed class CreateOrderValidator : Validator<Command>
    {
        public CreateOrderValidator()
        {
            RuleFor(x => x.CustomerName)
                .NotNull()
                .NotEmpty();
        }
    }

    public sealed class Handler : CommandHandler<Command, Response>
    {
        public Handler()
        {
        }

        public override async Task<IHandlerResponse<Response>> ExecuteAsync(Command command, CancellationToken ct)
        {
            var orderId = await Task.FromResult(Guid.NewGuid());
            var response = new Response(orderId, $"{command.CustomerName}");

            return Success(response);
        }
    }
}

Here additionally we use built-in Fluent Validation.

What about testing?

Ok let's now unit test GetOrderById. You can completely skip firing up API or Azure Functions, setting up http client , deal with authorization and start slapping your handler directly left and right 💥.

[Fact]
public async Task GetOrderById_WhenOrderFound_ReturnsOrder()
{

    var query = new GetOrderById.Query { Id = "1" };
    var handler = new GetOrderById.Handler();

    var expected = new OrderModel("1", "Gavin Belson", 20)();
    var result = await handler.ExecuteAsync(query);

    Assert.NotNull(result.Payload.Order);
    Assert.Equal(expected.Id, result.Payload.Order.Id);
    Assert.Equal(expected.CustomerName, result.Payload.Order.CustomerName);
    Assert.Equal(expected.Total, result.Payload.Order.Total);
}

Check more examples here:
https://github.com/kedzior-io/minimal-cqrs/tree/main/samples

I'm using it in production here:

shipdotnet.com
Fiz: Groceries in minutes
Bilbayt (currently migrating to it)

Meta vs WhatsApp: A Tale of Internal Conflicts

Artur Kedzior — Fri, 03 Nov 2023 11:45:03 +0000

The reason for this post is make some of you cautious about using services from these two companies. I had an extremely bad experience when trying to deal with an integration between to.

Our objective:

At Fiz we deliver groceries in minutes and we have a compensation system that rewards the customer with a promo code if we are not delivering on promised time. That promo code is delivered via Whatsapp message by the customer service. We wanted to automate that and send this message from our backend.

We signed up with Twilio
We tried to linked it Meta Business Suite (previously known as Facebook Business) with no success.
We had to remove Whatsapp account and re-register it via Meta Business Suite which we did.
Twilio got integrated ok and we were ready to send Whatsapp messages via their API! Hurrey.

Here is when the problem started. When registering on the device we were welcomed with:

We contacted Whatsapp Support which basically told us: "Not my problem talk to Meta". We contacted Meta Support which told us "Not my problem contact Whatsapp Support".

We repeated this 5 times and 24 later we are still not able to use our phone number for Customer Service.

Meta: "It's not me, it's them!"

Whatsapp: "It's not me! it's them!"

Seems there is an internal conflict between both teams and no proper leadership.

Now their logo makes more sense to me:

as I'm experiencing this Infinite Loop of Absurdness.

The story is not over, wish me luck!

Most Common Mistakes in C# Interview Pull Requests

Artur Kedzior — Thu, 21 Sep 2023 17:01:10 +0000

I often hire C# developers on different positions. One of the part of the interview is a technical code challenge in the form of a pull request. I ask the candidate to write a simple feature that usually involves fetching some data using Entity Framework.

Here is some recompilation of the most common mistakes and best practices I recommend when reviewing them.

LINQ First() vs Single()


var order = await DbContext.Orders
    .Where(x => x.Id == orderId)
    .FirstOrDefault(ct);

This one is very common mistake one should avoid. The main issue is the misleading intent.

Is more than one order expected with the particular orderId? In most case it is straight no.

What you want to do always is:

var order = await DbContext.Orders
    .Where(x => x.Id == orderId)
    .SingleOrDefault(ct);

Can't this be static?

Let's say you want to filter out some orders based on certain filters.

var visibleOrders = new List<OrderStatus>()
{
    OrderStatus.InProgress,
    OrderStatus.Shipped,
    OrderStatus.Delivered,
    OrderStatus.Confirmed
};

var orders = await DbContext.Orders
    .Where(x => visibleOrders .Contains(x.Status))
    .Where(x => x.UserId == userId)
    .ToListAync(ct);

Even experienced developers miss this out, visibleOrders should be static which allows all class instances share the exact copy of it.

private static visibleOrders = new List<OrderStatus>()
{
    OrderStatus.InProgress,
    OrderStatus.Shipped,
    OrderStatus.Delivered,
    OrderStatus.Confirmed
};

Are you going to update that entity?

So here we are getting an order. Are you going to update that order here?


var order = await DbContext.Orders
    .Where(x => x.Id == orderId)
    .SingleOrDefault(ct);

If the answer is "No". You should always add:

var order = await DbContext.Orders
    .AsNoTracking()
    .Where(x => x.Id == orderId)
    .SingleOrDefault(ct);

This makes sure that entities returned will not be cached in the DbContext or ObjectContext.

This is a good practice as it improves query performance.

Is that thing empty or null or does it have anything?

Let's check if the string is not empty:


if (string.IsNullOrEmpty(phoneNumber))
{

}

It's a good practice to never use this and instead use:


if (string.IsNullOrWhiteSpace(phoneNumber))
{

}

The method IsNullOrWhiteSpace covers IsNullOrEmpty, but it also returns true if the string contains only white space characters making it the true empty string checker!

Just updating a few records here and there?

Let's say we want to update several records at the same time:

var orders = await DbContext.Orders
    .Where(x => x.UserId == userId)
    .Take(50)
    .ToListAync(ct);

foreach (var order in orders)
{
    order.Status = OrderStatus.Confirmed;
    order.ModifiedDateUtc = DateTime.UtcNow;

    await DbContext.SaveChangesAsync(ct);
}

This is one of the biggest performance sins! You would never save changes inside the loop. Saving inside a loop in our example creates 50 requests to the database.

var orders = await DbContext.Orders
    .Where(x => x.UserId == userId)
    .Take(50)
    .ToListAync(ct);

foreach (var order in orders)
{
    order.Status = OrderStatus.Confirmed;
    order.ModifiedDate = DateTime.Now;
}

await DbContext.SaveChangesAsync(ct);

Here is much faster approach as the Entity Framework will send all 50 updates once.

Good luck!

and..

"May your coffee be strong and your bugs be weak!"

How I moved from React to Svelte

Artur Kedzior — Mon, 28 Aug 2023 22:43:11 +0000

In today's ever-evolving front-end landscape, React has been the crown jewel for many developers, including me. Its component-based structure, the efficiency of the Virtual DOM, and the vast community support made it a clear favorite.

Another thing called Svelte reached my ears. So I jumped into messing around with it and here is what I found:

1. Why Svelte?

Before diving into the transition, it's important to understand why one might consider moving. Svelte brings:

Simplicity: No Virtual DOM, less boilerplate, and straightforward syntax.

Performance: Svelte compiles components to vanilla JavaScript at build time, making it incredibly fast.

Reactivity: Reactive statements make data binding a breeze.

2. Initial Steps

The first thing I did was set up a Svelte project using Svelte's official template. Then, I spent some quality time with the official Svelte tutorial, which provides hands-on experience with the framework's core concepts.

3. Translating Components

Moving components from React to Svelte involved understanding the subtle differences:

JSX vs Svelte's Template Language: Instead of JSX, Svelte uses its HTML-like syntax, which made templates much more readable.

State Management: In Svelte, mutable state is handled with simple variables, and reactivity is achieved with a mere $: before a statement.

4. Event Handling

While React uses synthetic events, Svelte employs native event listeners. Transitioning meant:

Replacing onClick with on:click.

Eliminating event.persist() since Svelte uses native events.

5. Lifecycle Methods

React's lifecycle methods such as componentDidMount or componentWillUnmount got translated to Svelte's onMount and beforeDestroy.

6. Styling

Moving from CSS-in-JS (or any other React styling paradigm) to Svelte's scoped styles was refreshing. Each Svelte component gets its own encapsulated style, reducing the fear of global styles interfering with component-specific designs.

7. State Management on Steroids

While React has Context or Redux or Zustand for global state management, Svelte offers stores. These writable and readable stores made state management straightforward and less verbose.

8. Integrations & Plugins

Transitioning also meant looking for equivalent Svelte plugins and integrations or creating custom solutions when needed. Luckily, the Svelte community is robust and growing, offering ample resources.

9. Community and Support

I won't lie; the React community is vast. But the Svelte community, although smaller, is enthusiastic and rapidly expanding. Platforms like Discord, Reddit, and Stack Overflow provided ample support during my transition.

10. Conclusion

The journey from React to Svelte was awesome. While both have their strengths and use cases, Svelte's simplicity, speed, and clean syntax it's all I wanted.

All my new projects this year were built with Svelte. Here is my last one (a solo adventure):

https://shipdotnet.com - .NET 9 and Svelte 5 Starter Kit 🚀

On another project (full blown e-commerce) I encouraged my team of experienced React developers to try it out and they loved it and yes we have almost finished it using Svelte.

That said I doubt I will go back to React. ⚰️

In another words Svelte ruined React for me just as The Expanse ruined every other space science fiction.

🔥

Have you tried Svelte yet?

Share your experiences and thoughts below and thank you for reading!

If you enjoyed this post and want to stay updated, follow me on Twitter for the latest updates and check out my projects on GitHub.

May the code be with you!

The fastest & cheapest way to host your React + .NET 7 API.

Artur Kedzior — Tue, 13 Jun 2023 15:58:37 +0000

I have always look at the simplest way to host my indie projects that is also cheap.

Typically there are two elements to host:

Database
Application

If you are build a SaaS and using framework such as React there are actually three elements:

Database
API
Front-end

Going with any of the big cloud providers makes this setup expensive in monthly payments, especially when you are boot strapping indie project now and then.

I found that the fastest & cheapest way to ship things is to use a combination of a cheap VM from Droplet or Hetzner + Firestore with Firebase.

Service	Price	Function
Droplet	$6/m	Host React static app & .net API
Hetzner	$4.8/m	same as above
Firestore	Free*	NoSQL database
Firebase	Free*	identity solution

Firebase & Firestore have a generous free tier which is more than enough to spin up your project fast that will hopefully get successful quickly and it can scale easily.

But what do they do?

Firebase - takes care of your authentication part. You setup the service and they provide you with a npm package to easily integrate your react client code. What does it give you: email + password, gmail, facebook, twitter, github, apple logins out of the box. What you end up storing in your database (user related) is Firebase User ID (UID).

Firestore - is a NoSQL database. Great to start with when you are still shaping your data. It's a good candidate when your data is simple as there is no concept of tables but documents which are basically JSON objects. Given the nature of NoSQL there are some great advantages but also some disadvantages of it. I'm not going to go into details of it here.

Above combo is my favourite when I start with a new indie project. I have basic setup ready within 1 hour.

Let me show here I how set this all up.

Let's start with setting up your .NET API:

Program.cs

        services
            .AddAuthentication(cfg =>
            {
                cfg.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                cfg.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            .AddJwtBearer(options =>
            {
                options.Authority = $"https://securetoken.google.com/{firebaseSettings.ProjectId}";
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateIssuer = true,
                    ValidIssuer = $"https://securetoken.google.com/{firebaseSettings.ProjectId}",
                    ValidateAudience = true,
                    ValidAudience = firebaseSettings.ProjectId,
                    ValidateLifetime = true
                };
            });

        services.AddAuthorization(options => options.DefaultPolicy = new AuthorizationPolicyBuilder(JwtBearerDefaults.AuthenticationScheme)
            .RequireAuthenticatedUser()
            .Build());

        var firebaseJson = JsonSerializer.Serialize(firebaseSettings);

        FirebaseApp.Create(new AppOptions
        {
            Credential = GoogleCredential.FromJson(firebaseJson)
        });

// ...

app.UseAuthorization();
app.UseAuthentication();

🔥 That's all you need for your API! 🔥

But wait, what's firebaseSettings ?

Well you need some way to be able to talk to Firebase.

You need to use this
https://www.nuget.org/packages/FirebaseAdmin

That is letting your API to talk to Firebase and add claims to the token issued by Firebase. For example you might want to store thing like user role.

How this can be set up?

When you get to register with Firebase you will have a section where you can download Service Account json file. Just copy values from it to this class. Alternatively you can use appsettings.json for it.

public class FirebaseSettings
{
    public static FirebaseSettings CreateDevelopment() => new
    (
        "projectId",
        "653464563435645",
        "-----BEGIN PRIVATE KEY-----\privateKey\n-----END PRIVATE KEY-----\n",
        "aaaaaaaaaaaaaa",
        "https://www.googleapis.com/robot/v1/metadata/x509/firebase-adminsdk-9heco%40GP-72daa.iam.gserviceaccount.com",
        "firebase-adminsdk-yourspecificid.iam.gserviceaccount.com"
    );


    public FirebaseSettings(string projectId, string privateKeyId, string privateKey, string clientId, string clientX509CertUrl, string clientEmail)
    {
        ProjectId = projectId;
        PrivateKeyId = privateKeyId;
        PrivateKey = privateKey;
        ClientId = clientId;
        ClientX509CertUrl = clientX509CertUrl;
        ClientEmail = clientEmail;
    }

    [JsonPropertyName("project_id")]
    public string ProjectId { get; init; }

    [JsonPropertyName("private_key_id")]
    public string PrivateKeyId { get; init; }

    [JsonPropertyName("private_key")]
    public string PrivateKey { get; init; }

    [JsonPropertyName("client_id")]
    public string ClientId { get; init; }

    [JsonPropertyName("client_x509_cert_url")]
    public string ClientX509CertUrl { get; init; }

    [JsonPropertyName("client_email")]
    public string ClientEmail { get; init; }

    [JsonPropertyName("type")]
    public string Type => "service_account";

    [JsonPropertyName("auth_uri")]
    public string AuthUri => "https://accounts.google.com/o/oauth2/auth";

    [JsonPropertyName("token_uri")]
    public string TokenUri => "https://oauth2.googleapis.com/token";

    [JsonPropertyName("auth_provider_x509_cert_url")]
    public string AuthProviderx509CertUrl => "https://www.googleapis.com/oauth2/v1/certs";
}

All you need now is to create an endpoint that is authorized and your Firebase user ID would be within the token. Your Firebase user ID can serve as to map with your internal user ID if your really want to.

[Authorize]
public sealed class GetUser : EndpointBaseAsync
    .WithoutRequest
    .WithActionResult<UserModel>
{

    [HttpGet]
    public override async Task<ActionResult<UserModel>> HandleAsync(CancellationToken cancellationToken = default)
    {
        var firebaseUserId = HttpContext.GetFirebaseId()      
    }
}


public static class HttpContextExtensions
{
    public static string GetFirebaseId(this HttpContext context)
        => context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value ?? throw new Exception("Missing name identifier claim on current user");
}

Now the client part!

You will need firebase npm package .

import firebase from 'firebase/compat/app';
import { firebaseConfig } from '../config';


const login = (email, password) => firebase
      .auth()
      .signInWithEmailAndPassword(email, password)
      .then(() => {
        // After signing with firebase you might want to sign in with your .NET API
        axios.post(`${process.env.REACT_APP_API}/users.signin`).then((response)=> {
          setProfile(response.data);             
        });
      }); 

  const loginWithGoogle = () => {
    const provider = new firebase.auth.GoogleAuthProvider();
    return firebase.auth().signInWithPopup(provider);
  };

  const loginWithFaceBook = () => {
    const provider = new firebase.auth.FacebookAuthProvider();
    return firebase.auth().signInWithPopup(provider);
  };

  const loginWithTwitter = () => {
    const provider = new firebase.auth.TwitterAuthProvider();
    return firebase.auth().signInWithPopup(provider);
  };

  const register = (email, password, firstName, lastName) => 
     firebase
      .auth()
      .createUserWithEmailAndPassword(email, password)
      .then(() => {      
        // After registering with firebase you might want register using your .NET API
        axios.post(`${process.env.REACT_APP_API}/users.signup`, { firstName, lastName, email } )
        .then((response) => {
          setProfile(response.data);
        });         
      });  

  const logout = async () => {
    await firebase.auth().signOut();
};


// That's the config that is obtained from Firebase Console. 

export const firebaseConfig = {
  apiKey: process.env.REACT_APP_FIREBASE_API_KEY,
  authDomain: process.env.REACT_APP_FIREBASE_AUTH_DOMAIN,
  databaseURL: process.env.REACT_APP_FIREBASE_DATABASE_URL,
  projectId: process.env.REACT_APP_FIREBASE_PROJECT_ID,
  storageBucket: process.env.REACT_APP_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.REACT_APP_FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.REACT_APP_FIREBASE_APPID,
  measurementId: process.env.REACT_APP_FIREBASE_MEASUREMENT_ID
};

🔥 That's all you need for your client code! 🔥

Well not, you need to build your forms and use those methods. If you want to skip it all along you can also use FirebaseUI which provides you with already made login form.

Drop me any comment if you get stuck or there is something unclear.

Good luck and ....

Made The Code Be with You!

3 things to avoid when implementing Domain-Driven Design (DDD)

Artur Kedzior — Wed, 07 Jun 2023 17:08:09 +0000

The reason of this post is due to the fact I often see developers trying to follow Domain-Driven Design (DDD) approach but make very questionable decisions during the implementation.

Here is a summary of things which should be avoided:

1. Public setters

Let's look at this simplified entity (skipped other properties):

public class Order
{
   public PaymentMethod PaymentMethod { get; set; }
   public decimal Total { get; set; }
}

What's wrong with it?: The entity should encapsulate both data and behaviour. Having a setter means anyone can modify the property which allows to change its state.

Let's check this example with few enforced rules:

Order can't exist without payment method or order total
We can't place order with 0 or negative total
We can't place cash orders for orders with total value over 100 (whatever the currency)

public class Order
{
    public PaymentMethod PaymentMethod { get; private set; }
    public decimal Total { get; private set; }

    private static decimal CashOrderMaxTotal = 100;

    public Order(PaymentMethod paymentMethod, decimal orderTotal)
    {
        if (orderTotal == 0 || orderTotal < 0)
        {
            throw new ArgumentException(String.Format("{0} can't be 0 or negative", orderTotal), "orderTotal");
        }

        if (paymentMethod.Cash && orderTotal > CashOrderMaxTotal)
        {
            throw new ArgumentException(String.Format("Unable to order total {0}, cash order cannot total more than {1}", orderTotal, CashOrderMaxTotal), "orderTotal");
        }

        Total = orderTotal;
        PaymentMethod = paymentMethod;

    }
}

To enforce rule 1 - we use a constructor to set properties and to enforce rule 2 and 3 we add validation.

2. Lack of rules validation

Let's take a look again:

public class Order
{
    public decimal Total { get; private set; }

    public Order(decimal orderTotal)
    {
        Total = orderTotal;
    }
}

What's wrong with it?: As seen on the previous example, lack of validation rules means anyone can set this order to some unwanted values which is not good and can make its way to big fireworks of bugs. Always code defensively and never let the entity to go into invalid state.

Here is an example how one would make sure our order total is valid. For this purpose I use an amazing library called GuardClauses which is just shorter way of throwing an argument exception if the condition is not met.

public class Order
{
    public decimal Total { get; private set; }

    public Order(decimal orderTotal)
    {
        Guard.Against.NegativeOrZero(orderTotal);
        Total = orderTotal;
    }
}

The important part here is, the code that creates order or modifies it in any sense should be validated and rejected on any bad intention.

2. Adding Persistence Logic

Now let's persist our order:

[Table("Orders")]
public class Order
{
    public decimal Total { get; private set; }
}

What's wrong with it: By adding [Table("Orders")] which is Entity Framework data annotation we are mixing persistence stuff within entities, we're violating the Single Responsibility Principle and we could lead to tightly coupled code that's harder to maintain and test.

This post doesn't focus on the design. Domain-Driven Design covers more concepts such us defining the domain, aggregate roots, value objects and using ubiquitous language. I might cover it in the next post. 🔥

To read more about Domain Driven Design I recommend the best book out there:

Domain Driven Design by Eric Evans.

Deploy React web application with Next.js and .NET API on Linux Host

Artur Kedzior — Mon, 29 May 2023 16:19:29 +0000

React.js is a great front-end frameworks and I have been combining it a lot with .NET API written in C#.

It is one of my favourite duos.

So far we have used react to build internal application such as dashboards, admin panels etc. for which things like SEO don't matter at all.

However for anything publicly available, SEO is important specially if you are building a SaaS and you want it to be findable by Google and others.

I started working on a small project which required server side rendering and so Next.js had to step in.

The challenge was to set it all up with Azure Pipelines (aka Github Actions aka Team City) and deploy it on a Linux hosted with Droplets.

I got very confused about the process of building and deployment because whenever I reached out to the Next.js community I was told to run next build on my production server which I found a bit crazy.

Additionally nobody seem to know the answer: https://stackoverflow.com/questions/76121837/how-can-i-run-next-js-with-self-hosted-node-js

Why I found it crazy? Well it is a first time I was told to build the project on the production server. This is not how it is supposed to be done. The way it is supposed to be done is that you commit the code to your repo, pipelines pulls it and builds the whole thing for you and all it has to be done is the transfer of the production build to the production server. Why on Earth I would build things on the production server?

After some research I discovered something called standalone output which also had its issues:
https://stackoverflow.com/questions/76294578/cannot-find-module-next-server-font-manifest-json

Finally I managed to figure this out and so I'm sharing it here for those who are lost as I was once:

Set output to standalone

const nextConfig = {
  reactStrictMode: true,
  output: 'standalone'
}

module.exports = nextConfig

Here is the pipeline **build **setup. I will use a sudo code to give an idea of what needs to be done. I add the complete file at the end of the this post.

# SM.Web is my root of the web project

yarn install

# overwrite your .env with environment specific stuff

echo "NEXT_PUBLIC_API_BASE_URL=https://api.yourawesomeapp.com" >> src/SM.Web/.env

yarn build

cp -R src/SM.Web/public "src/SM.Web/.next/standalone/public"

cp -R src/SM.Web/.next/static" src/SM.Web/.next/standalone/.next/static"

zip src/SM.Web/.next/standalone SM.Web.zip

# publish SM.Web.zip s artefact

Here is **deployment **pipeline:

Download the artefact on to your Linux box using SSH key connection. I won't go here into a details.
Replace current application with the artefact content

rm  -rf /var/apps/sm/staging-app/*

unzip -o /var/apps/sm/staging-app-build/SM.Web.zip -d /var/apps/sm/staging-app 

rm  /var/apps/sm/staging-app-build/SM.Web.zip

# for this command to work you need to setup `sm-staging` first
# go to /var/apps/sm/staging-web/
# and run: pm2 start "node server.js" --name "sm-staging"

pm2 reload sm-staging

Here is the complete azure-pipelines.yaml:

trigger:
  - main

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: "Release"

steps:
  - task: CmdLine@2
    displayName: "[app] yarn install staging"
    inputs:
      script: "yarn install"
      workingDirectory: "src/SM.Web/"

  - task: Bash@3
    displayName: "[app] add build version"
    inputs:
      targetType: "inline"
      script: |
        touch src/SM.Web/.env
        echo "NEXT_PUBLIC_API_BASE_URL=https://api.yourawesomeapp.com" >> src/SM.Web/.env
        cat src/SM.Web/.env

  - task: CmdLine@2
    displayName: "[app-staging] yarn build"
    inputs:
      script: "yarn build"
      workingDirectory: "src/SM.Web/"

  - task: CopyFiles@2
    displayName: "[app-staging] copy public"
    inputs:
      SourceFolder: "src/SM.Web/public" 
      Contents: '**' 
      TargetFolder: "src/SM.Web/.next/standalone/public"

  - task: CopyFiles@2
    displayName: "[app-staging] copy static"
    inputs:
      SourceFolder: "src/SM.Web/.next/static" 
      Contents: '**' 
      TargetFolder: "src/SM.Web/.next/standalone/.next/static"

  - task: ArchiveFiles@2
    displayName: "[app-staging] create artifact"
    inputs:
      rootFolderOrFile: "src/SM.Web/.next/standalone"
      includeRootFolder: false
      archiveType: "zip"
      archiveFile: "$(Build.ArtifactStagingDirectory)/sm-web/SM.Web.zip"

  - task: UseDotNet@2
    displayName: "[api] use dotnet 7"
    inputs:
      packageType: "sdk"
      version: "7.0.x"
      performMultiLevelLookup: true

  - task: DotNetCoreCLI@2
    displayName: "[api] restore"
    inputs:
      command: "restore"
      projects: "src/SM.Api/SM.Api.csproj"
      feedsToUse: "select"

  - task: DotNetCoreCLI@2
    displayName: "[api] build"
    inputs:
      command: "build"
      projects: "src/SM.Api/SM.Api.csproj"
      arguments: "--configuration $(BuildConfiguration)"

  - task: DotNetCoreCLI@2
    displayName: "[api] publish"
    inputs:
      command: "publish"
      publishWebProjects: true
      arguments: "-c $(buildConfiguration) -o $(Build.ArtifactStagingDirectory)/sm-api"

  - task: PublishPipelineArtifact@1
    displayName: "publish artifact"
    inputs:
      targetPath: "$(Build.ArtifactStagingDirectory)"
      artifactName: "sm"

What does your Linux box need?

Nodejs
PM2

🚀 Good luck! 🚀

My C# Code Conventions and Style Guide

Artur Kedzior — Sat, 13 May 2023 14:17:24 +0000

I like to follow "Modern Microsoft" conventions and styles for C# and dotnet; these are the conventions typically found in modern Microsoft GitHub repos like .NET, EF, etc. They are generally also the defaults within Visual Studio.

I go for standard Microsoft conventions as they would be most popular in the community and would generally be more familiar to new developers joining the team.

1. Boolean Evaluations

😀 DO prefer expression operator short-hand syntax.

var success = true;

if (success)
{
    // do if true
}

if (!success)
{
    // do if not true
}

Why: Consistent with Microsoft’s .NET Framework and makes code simpler, more concise, and easier to read.

😡 DO NOT use long form operator syntax:

var success = true;

if (success == true)
{
    // do if true
}

if (success == false)
{
    // do if not true
}

2. Abbreviation Casing

😀 DO prefer PascalCase for a abbreviations of any length found within member names:

public DateTime CreatedUtc { get; set; }
public string SqlConnection { get; set; }

😡 DO NOT UPPERCASE abbreviations:

public DateTime CreatedUTC { get; set; }
public string SQLConnection { get; set; }

Why: Consistent with Microsoft’s .NET Framework and easier to read.

3. Conditional and Loop Brackets

😀 DO always include brackets around single-line conditional and loop statements:

if (true)
{
    DoSomething():
}

😡 DO NOT omit brackets:

if (true)
    DoSomething();

Why: It makes the scope of the statements clearer and avoids future issues if those statements are expanded.

4. Var Keyword

😀 DO always prefer using the var keyword instead of the
explicit type:

var option = new CookieOptions();

😡 DO NOT use the explicit type:

CookieOptions option = new CookieOptions();

Why: It simplifies the code and isn’t any less understandable.

5. LINQ Single vs Where

😀 DO always prefer using the Where function instead of the Single :

var order = await DbContext.Orders
   .Where(x => x.Id == id)
   .Where(x => x.Status == OrderStatus.Created)
   .Where(x => x.Customer.Id == customerId)
   .SingleAsync(cancellationToken);

😡 DO NOT use the explicit type:

var order = await DbContext.Orders
  .SingleAsync(x => x.Id == id && x.Status == OrderStatus.Created && x.Status == OrderStatus.Created, cancellationToken);

Why: It improves readability of the code.

Thank you for reading!

If you enjoyed this post and want to stay updated, follow me on Twitter for the latest updates and check out my projects on GitHub.

May the code be with you!

Easiest way to build the fastest REST API in C# and .NET 7 using CQRS

Artur Kedzior — Tue, 25 Apr 2023 21:25:40 +0000

Sometime ago I stumbled upon this amazing library built by amazing people: https://fast-endpoints.com

It was also featured on this platform https://dev.to/djnitehawk/building-rest-apis-in-net-6-the-easy-way-3h0d (written by the author).

I gave it a go and I was impressed how easy and fast it was to set it all up. Since I'm not a big fan of REPR pattern almost all my projects are using CQRS pattern with a help of MediatR ](https://github.com/jbogard/MediatR) I immediately started going over something similar that Fast Endpoints offer which is a command bus.

So I put the project together with certain goals:

Keep everything in command/query handlers
Keep API as thin as possible
Execute handlers within Azure Functions (keeping them thin as well)
Make handlers easily unit testable

I put all this up on Github FastArchitecture 🔥

You can see it in action on a real-world project Salarioo.com 🔥

The API endpoint ended up being a single line:

public class GetOrdersEndpoint : ApiEndpoint<GetOrders.Query, GetOrders.Response>
{
    public override void Configure()
    {
        Get("orders/list");
        AllowAnonymous();
        ResponseCache(60);
    }

    public override async Task HandleAsync(GetOrders.Query query, CancellationToken ct) => await SendAsync(query, ct);
}

The Query handler in a self contained class that contains:

Query definition (the input)
Query response (the output)
Handler (stuff that happens within execution)

public static class GetOrders
{
    public sealed class Query : IQuery<IHandlerResponse<Response>>
    {
    }

    public sealed class Response
    {
        public IReadOnlyCollection<OrderListModel> Orders { get; private set; }

        public Response(IReadOnlyCollection<Domain.Order> orders)
        {
            Orders = orders.Select(OrderListModel.Create).ToList();
        }
    }

    public sealed class Handler : QueryHandler<Query, Response>
    {
        public Handler(IHandlerContext context) : base(context)
        {
        }

        public override async Task<IHandlerResponse<Response>> ExecuteAsync(Query query, CancellationToken ct)
        {
            var orders = await DbContext
                .Orders
                .ToListAsync(ct);

            return Success(new Response(orders));
        }
    }
}

Here is an example of Command handler with built-in Fluent Validation and fire and forget style:

public static class ConfirmAllOrders
{
    public sealed class Command : ICommand
    {
        public string Name { get; set; } = "";
    }

    public sealed class MyValidator : Validator<Command>
    {
        public MyValidator()
        {
            RuleFor(x => x.Name)
                .MinimumLength(5)
                .WithMessage("Order name is too short!");
        }
    }

    public sealed class Handler : Abstractions.CommandHandler<Command>
    {
        public Handler(IHandlerContext context) : base(context)
        {
        }

        public override async Task<IHandlerResponse> ExecuteAsync(Command command, CancellationToken ct)
        {
            var orders = await DbContext
                   .Orders
                   .ToListAsync(ct);

            orders.ForEach(x => x.SetConfrimed());

            await DbContext.SaveChangesAsync(ct);

            return Success();
        }
    }
}

Handlers allow 3 possible responses:

Response without content:

return Success()

Response with some content:

return Success(responseObj)

An error*:

return Error("I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.")

*soon to be implemented

Here is an example of running it from Azure Functions:

public class ConfirmAllOrdersFunction : FunctionBase<ConfirmAllOrdersFunction>
{

    public ConfirmAllOrdersFunction(ILogger logger) : base(logger)
    {
    }

    [Function(nameof(ConfirmAllOrdersFunction))]
    public async Task Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req)
    {
        var command = new ConfirmAllOrders.Command();

        await ExecuteAsync<ConfirmAllOrders.Command>(command, req.FunctionContext);
    }
}

🔥 Interested?
🔥 Checkout the complete source code on Github FastArchitecture

Simple .NET Core and Cloud Firestore setup

Artur Kedzior — Fri, 03 Dec 2021 21:28:19 +0000

... Cloud Firestore is a flexible, scalable database for mobile, web, and server development from Firebase and Google Cloud. Like Firebase Realtime Database, it keeps your data in sync across client apps through realtime listeners and offers offline support for mobile and web so you can build responsive apps that work regardless of network latency or Internet connectivity...

Sounds cool, so how do I set it up with .Net Core (dotnet)?
It's very simple.

I won't go into detail on how to setup firebase using console, there are plenty of tutorials out there. What we will need is the service account json file.

Let's start with the important part and create FirebaseProvider for generic use.

Firebase Provider

Ah yeah and make sure you have this nuget package installed:

<PackageReference Include="Google.Cloud.Firestore" Version="2.4.0" />

public class FirestoreProvider
{
    private readonly FirestoreDb _fireStoreDb = null!;

    public FirestoreProvider(FirestoreDb fireStoreDb)
    {
        _fireStoreDb = fireStoreDb;
    }

    public async Task AddOrUpdate<T>(T entity, CancellationToken ct) where T : IFirebaseEntity
    {
        var document = _fireStoreDb.Collection(typeof(T).Name).Document(entity.Id);
        await document.SetAsync(entity, cancellationToken: ct);
    }

    public async Task<T> Get<T>(string id, CancellationToken ct) where T : IFirebaseEntity
    {
        var document = _fireStoreDb.Collection(typeof(T).Name).Document(id);
        var snapshot = await document.GetSnapshotAsync(ct);
        return snapshot.ConvertTo<T>();
    }

    public async Task<IReadOnlyCollection<T>> GetAll<T>(CancellationToken ct) where T : IFirebaseEntity
    {
        var collection = _fireStoreDb.Collection(typeof(T).Name);
        var snapshot = await collection.GetSnapshotAsync(ct);
        return snapshot.Documents.Select(x => x.ConvertTo<T>()).ToList();
    }

    public async Task<IReadOnlyCollection<T>> WhereEqualTo<T>(string fieldPath, object value, CancellationToken ct) where T : IFirebaseEntity
    {
        return await GetList<T>(_fireStoreDb.Collection(typeof(T).Name).WhereEqualTo(fieldPath, value), ct);
    }

    // just add here any method you need here WhereGreaterThan, WhereIn etc ...

    private static async Task<IReadOnlyCollection<T>> GetList<T>(Query query, CancellationToken ct) where T : IFirebaseEntity
    {
        var snapshot = await query.GetSnapshotAsync(ct);
        return snapshot.Documents.Select(x => x.ConvertTo<T>()).ToList();
    }
}

Usage

Inject it to your whatever it's going to use it.

private readonly FirestoreProvider _firestoreProvider;

public SampleEndpoint(FirestoreProvider firestoreProvider)
{
    _firestoreProvider = firestoreProvider;
}

... and here is how you would actually use it:

// Add or Update

var user = new User("Artur");
await _firestoreProvider.AddOrUpdate(user, cancellationToken);  

// Get by Id

var user = await _firestoreProvider.Get<User>("306f19a85136414b868ff7ba56c3f0a8", cancellationToken);

// Get all (use it wisely*)

var allUsers = await _firestoreProvider.GetAll<User>(cancellationToken);

// Query by first name (for example)

var users = await _firestoreProvider.WhereEqualTo<User>(nameof(Api.Data.User.FirstName), "Artur", ct);

Data model

Now the boooooring part.

Our simplified data model:


[FirestoreData]
public class User : IFirebaseEntity
{
    [FirestoreProperty]
    public string Id { get; set; }

    [FirestoreProperty]
    public string FirstName { get; set; }

    public User()
    {
    }

    public User(string firstName)
    {
        Id = Guid.NewGuid().ToString("N");
        FirstName = firstName;
    }
}

The interfaces that forces to create Id which would be used as document id. We will use string version of Guid for that purpose.

public interface IFirebaseEntity
{
    public string Id { get; set; }
}

Provider registration

services.AddSingleton(_ => new FirestoreProvider(
    new FirestoreDbBuilder 
    { 
        ProjectId = firebaseSettings.ProjectId, 
        JsonCredentials = firebaseJson // <-- service account json file
    }.Build()
));

Firebase service account json

If you want a quick and dirty way of loading one without json files floating around your solution you can just hard code them into a class:

public class FirebaseSettings
{
    [JsonPropertyName("project_id")]
    public string ProjectId => "that-rug-really-tied-the-room-together-72daa";

    [JsonPropertyName("private_key_id")]
    public string PrivateKeyId => "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

    // ... and so on
}

In Startup.cs within ConfigureServices.

var firebaseJson = JsonSerializer.Serialize(new FirebaseSettings());

... and you are done!

If you want to have plural names for your collections just modify FirestoreProvider so that collection gets s:

_fireStoreDb.Collection($"{typeof(T).Name}s")

Thank you for reading!

If you enjoyed this post and want to stay updated, follow me on Twitter for the latest updates and check out my projects on GitHub.

May the code be with you!