What are the current Release Plans

[iang0ld]

Mukesh,

Are you able to tell us you current release plans and features for the new version?

Thanks
Ian

[iammukeshm]

@iang0ld the documentation is up and running - https://fullstackhero.net/
What's pending the is the NuGet package for installing the templates.
Apart from that, I currently consider all the features done and completed.
Any new features needed will be considered as a feature request for the next version.
Feel free to clone the repo and test out the Kit and let me know!

[iang0ld]

The updated doc are new. I'm already using it which is why I was asking about setting. I love it. Compared to other options is well structured, vertical, modern and not overly complex. Thank you.

[iammukeshm]

Can you give more requirements about the settings module you asked for?

[gokhanwork]

Hi Mukesh, let’s say we’ve developed a project using this template. Later, when changes and updates are made to this project, how can we retrieve those updates? Is there a solution for this? Does the fsh update CLI command handle this?

@iang0ld the documentation is up and running - https://fullstackhero.net/ What's pending the is the NuGet package for installing the templates. Apart from that, I currently consider all the features done and completed. Any new features needed will be considered as a feature request for the next version. Feel free to clone the repo and test out the Kit and let me know!

[iang0ld]

You can update your git repository using an upstream

git remote add upstream https://
git fetch upstream

Then pull from upstream:

git pull upstream

[iang0ld]

For the settings modules this is what I was thinking. Something simple but effective,

Summary

Create a new Settings module in the modular monolith to manage application settings. The module must provide an endpoint for retrieving UI-safe settings and an internal cached service for retrieving server-side settings.

Background

The application requires a centralised way to manage configurable settings across modules such as UI, workflow, integrations, emailing, storage, and quoting.

Settings should support:

System-level defaults
Tenant-level overrides
User-level overrides
Cached server-side access
A safe API for frontend UI settings

Server-only settings must not be exposed to the browser.

Implementation idea of the core functionality. Does not include create/update/delete of settings.

Key values examples ...

ui.theme
ui.logoUrl
ui.dateFormat
ui.defaultGridPageSize
features.quoteBuilder.enabled
features.workflowDesigner.enabled
server.email.maxRetries
server.storage.maxUploadMb
server.workflow.defaultDelayDays

public class SettingValue
{
    public int Id { get; set; }
    public string Key { get; set; } = default!;
    public string ValueJson { get; set; } = default!;
    public string DataType = 'string' 
    public SettingScope Scope { get; set; }
    public string? TenantId { get; set; }
    public string? UserId { get; set; }
    public bool IsUiVisible { get; set; }
    public DateTime UpdatedUtc { get; set; }
}

public enum SettingScope
{
    System = 1,
    Tenant = 2,
    User = 3
}

Reader to keep to implementation away from the modules.

public interface ISettingsReader
{
    Task<T> GetAsync<T>(
        string key,
        string? tenantId,
        string ? userId,
        T defaultValue,
        CancellationToken ct = default);
}

Lookup order...

User setting
Tenant setting
System setting
Default value from code

UI endpoint

GET /api/settings/ui

Returning settings matching IsUiVisible, using DataType to create json values

{
  "settings": {
    "ui.theme": "light",
    "ui.logoUrl": null,
    "ui.defaultGridPageSize": 50,
    "features.quoteBuilder.enabled": true
  }
}

Server Retreival

From database/cache storage return a DTO.

public interface ISettingsReader
{
    Task<T> GetAsync<T>(
        string key,
        string? tenantId,
        CancellationToken ct = default);
}

public async Task<T> GetAsync<T>(
    string key,
    string? tenantId,
    CancellationToken ct = default)
{
    var cacheKey = $"settings:{tenantId ?? "system"}:{key}";

    return await _cache.GetOrCreateAsync(cacheKey, async entry =>
    {
        entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);

        var row = await _repository.GetResolvedSettingAsync(key, tenantId, ct);

        if (row is null)
            throw new InvalidOperationException($"Setting '{key}' is not defined.");

        var json = row.ValueJson ?? row.DefaultValueJson;

        return JsonSerializer.Deserialize<T>(json)
            ?? throw new InvalidOperationException($"Setting '{key}' could not be deserialized.");
    })!;
}

[kallievz]

For the settings modules this is what I was thinking. Something simple but effective,

Summary

Create a new Settings module in the modular monolith to manage application settings. The module must provide an endpoint for retrieving UI-safe settings and an internal cached service for retrieving server-side settings.

Background

The application requires a centralised way to manage configurable settings across modules such as UI, workflow, integrations, emailing, storage, and quoting.

Settings should support:

System-level defaults
Tenant-level overrides
User-level overrides
Cached server-side access
A safe API for frontend UI settings

Server-only settings must not be exposed to the browser.

Implementation idea of the core functionality. Does not include create/update/delete of settings.

Key values examples ...

ui.theme
ui.logoUrl
ui.dateFormat
ui.defaultGridPageSize
features.quoteBuilder.enabled
features.workflowDesigner.enabled
server.email.maxRetries
server.storage.maxUploadMb
server.workflow.defaultDelayDays

public class SettingValue
{
    public int Id { get; set; }
    public string Key { get; set; } = default!;
    public string ValueJson { get; set; } = default!;
    public string DataType = 'string' 
    public SettingScope Scope { get; set; }
    public string? TenantId { get; set; }
    public string? UserId { get; set; }
    public bool IsUiVisible { get; set; }
    public DateTime UpdatedUtc { get; set; }
}

public enum SettingScope
{
    System = 1,
    Tenant = 2,
    User = 3
}

Reader to keep to implementation away from the modules.

public interface ISettingsReader
{
    Task<T> GetAsync<T>(
        string key,
        string? tenantId,
        string ? userId,
        T defaultValue,
        CancellationToken ct = default);
}

Lookup order...

User setting
Tenant setting
System setting
Default value from code

UI endpoint

GET /api/settings/ui

Returning settings matching IsUiVisible, using DataType to create json values

{
  "settings": {
    "ui.theme": "light",
    "ui.logoUrl": null,
    "ui.defaultGridPageSize": 50,
    "features.quoteBuilder.enabled": true
  }
}

Server Retreival

From database/cache storage return a DTO.

public interface ISettingsReader
{
    Task<T> GetAsync<T>(
        string key,
        string? tenantId,
        CancellationToken ct = default);
}

public async Task<T> GetAsync<T>(
    string key,
    string? tenantId,
    CancellationToken ct = default)
{
    var cacheKey = $"settings:{tenantId ?? "system"}:{key}";

    return await _cache.GetOrCreateAsync(cacheKey, async entry =>
    {
        entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);

        var row = await _repository.GetResolvedSettingAsync(key, tenantId, ct);

        if (row is null)
            throw new InvalidOperationException($"Setting '{key}' is not defined.");

        var json = row.ValueJson ?? row.DefaultValueJson;

        return JsonSerializer.Deserialize<T>(json)
            ?? throw new InvalidOperationException($"Setting '{key}' could not be deserialized.");
    })!;
}

I created a setting per module, in form of Tenant aware [Module]Setting, seeding default from appsetting file on startup. Ie. Max filesize for tenant root may be 1gb, for other say 15mb, one may prefer sendgrid, other smpt for email, now configurable per tenant by module

[iang0ld]

The benefit of a separate module is

1. You can hide the implementation behind a interface. In this case a single db Table supported by CRUD is the source of truth. Improvement are done in one place and available to everyone. For example adding a dropdown datatype.
2. You you can mange the settings in one place. You can then search for all setting for a module and display the settings in the UI automatically by looping over the json, or let the user search for settings.