Database setup for the Website service (#13)

This PR contains the work done to introduce a _Fluent_-based persistence layer for the Website service, selectable at runtime alongside the existing in-memory default, plus the local dev tooling and docs to support it. To provide further details about the work: * Persistence package * The `Driver` and `TLS` enumerations * The `Configuration` type * The `Service` factory that builds the service * `PrepareDB` for migrations registration * The `Probe` for readiness checks. * App integration * Builds the driver, registers migrations, and attaches `Fluent` to the service lifecycle so it starts/stops with the HTTP server. * Migrate-on-boot is gated to the in-memory backend; MySQL/MariaDB is migrated out of band via --database-migrate so shared databases never race on startup. * The `ConfigReader+Properties` extension maps database.* config keys onto the driver. * Library * Added database configuration constants. * The `HealthController` controller gains a readiness probe: `GET /health/ready` checks whether the database is reachable, separate from the existing liveness check. * Others * Updated the `docker-compose` files to support a database service behind a database profile, and hardened for local development * New database targets on the `Makefile` file and overall documentation updated * Updated the `.env.local`, `Dockerfile`, and `README` files to document the persistence workflow, config keys, and local DB commands Reviewed-on: rock-n-code/loud-amsterdam#13 Co-authored-by: Javier Cicchelli <javier@rock-n-code.com> Co-committed-by: Javier Cicchelli <javier@rock-n-code.com>
2026-07-11 09:15:58 +00:00
parent 9774454bba
commit dc6b22e648
45 changed files with 1791 additions and 254 deletions
@@ -0,0 +1,61 @@
+import Foundation
+
+/// A reusable, bundle-bound localizer that resolves String Catalog entries for an explicit locale.
+///
+/// A server has no single "current" locale, so each lookup must name the locale to use. An instance
+/// is bound to the bundle whose catalog holds the strings, then invoked like a function to resolve a
+/// key in a chosen locale.
+public struct Localize: Sendable {
+
+    // MARK: Properties
+
+    /// The backend that resolves keys against the catalog.
+    private let resolver: any CatalogResolving
+
+    // MARK: Initializers
+
+    /// Creates a localizer backed by the String Catalog in the given bundle.
+    /// - Parameters:
+    ///   - bundle: the bundle whose String Catalog contains the keys to resolve.
+    ///   - table: the name of the String Catalog resource, without the `.xcstrings` extension.
+    public init(
+        bundle: Bundle,
+        table: String = "Localizable"
+    ) {
+        self.init(resolver: StringCatalog(
+            bundle: bundle,
+            table: table
+        ))
+    }
+
+    /// Creates a localizer backed by the given resolver.
+    ///
+    /// The seam for tests and alternative backends; the public API resolves against a bundled catalog.
+    /// - Parameter resolver: the backend that resolves keys to localized strings.
+    init(
+        resolver: any CatalogResolving
+    ) {
+        self.resolver = resolver
+    }
+
+    // MARK: Methods
+
+    /// Resolves a catalog key in the given locale.
+    ///
+    /// Invoked by calling the instance directly, for example `localize("index.title", locale: locale)`.
+    /// - Parameters:
+    ///   - key: the String Catalog key to look up.
+    ///   - locale: the locale to resolve the key in.
+    /// - Returns: the localized string for the locale, the source-language string when the locale has no
+    ///   entry, or the key itself when the catalog has no entry for it.
+    public func callAsFunction(
+        _ key: String,
+        locale: Locale
+    ) -> String {
+        resolver.string(
+            for: key,
+            in: locale
+        )
+    }
+
+}