Multi tenancy support

[motss]

Is your feature request related to a problem? Please describe.
It would be great if Brisa supports multi tenancy out of the box where a single system is used by multiple tenants or domains where each tenant will have their own configurations fetched from external services from app runtime config to i18n config. Not sure if this is supported already but the the docs has yet to have any info about this.

Describe the solution you'd like
While app runtime config can be fetched dynamically as it is not tightly coupled with Brisa, i18n is not as it requires to read the i18n config file src/i18n.ts where we need to statically declare all supported locales. It'd be great to make the i18n a middleware function where we can fetch and update the i18n config for each tenant on the fly.

Describe alternatives you've considered
None yet.

[aralroca]

We are supporting domains in i18n:

export default {
  locales: ["en-US", "fr", "nl-NL"],
  defaultLocale: "en-US",
  domains: {
    "example.com": {
      defaultLocale: "en-US",
    },
    "example.nl": {
      defaultLocale: "nl-NL",
      protocol: "http", // by default is https
      dev: true, // by default is false
    },
  },
};

Is this what you mean or what do you think is missing? Thank you @motss

Ref: https://brisa.build/building-your-application/routing/internationalization#domain-routing

[motss]

@aralroca thanks for pointing this approach. I'm aware of this static approach and what I am looking for is a dynamic approach. The use case is that locales can be updated by the users at any point of time for each tenant in a multi tenancy application. With the static approach it basically means that it is necessary to redeploy the entire application every time the tenant locales get changed, e.g. users update the locale for their own tenant and users do not have to inform us devs to redeploy our application. Hope this explains the use case.

[aralroca]

I understand that it can be done even if it is not “out of the box”. It can be controlled with a middleware and the BRISA_LOCALE cookie, also, you can load the keys dynamically using overrideMessages. @motss I would like to know what suggestions you have in mind to make this process easier or if there is anything we are missing? The idea of the route-map for 1.0 is to finish creating it together with the community, so it's a perfect time to suggest new APIs and things that you think would make your life easier. 😊