javier
dc6b22e648
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>
38 lines
1.6 KiB
Swift
38 lines
1.6 KiB
Swift
import Foundation
|
|
|
|
/// A backend that resolves localized strings for an explicit locale and reports the languages it serves.
|
|
///
|
|
/// This is the seam that decouples ``Localize`` and ``LanguageList`` from *how* localizations are stored
|
|
/// and resolved. The shipping implementation, ``StringCatalog``, reads a raw `.xcstrings` catalog so it
|
|
/// behaves identically on Darwin and Linux. A future backend — for example one built on
|
|
/// `String(localized:)` for a native Apple app that needs plural and device variations — can conform
|
|
/// without changing any caller.
|
|
///
|
|
/// Resolution never fails: an implementation returns the key itself when it has no localization for it,
|
|
/// mirroring Foundation's `String(localized:)`. This is the contract both a dictionary lookup and the
|
|
/// native API can honour, since the native API cannot distinguish a missing key from a translation that
|
|
/// happens to equal the key.
|
|
protocol CatalogResolving: Sendable {
|
|
|
|
// MARK: Properties
|
|
|
|
/// The source (development) language, used as the final fallback when a locale has no localization.
|
|
var sourceLanguage: String { get }
|
|
|
|
/// Every language the backend can resolve strings for, including the source language.
|
|
var languages: Set<String> { get }
|
|
|
|
// MARK: Methods
|
|
|
|
/// Resolves a catalog key in the given locale.
|
|
/// - Parameters:
|
|
/// - key: the catalog key to look up.
|
|
/// - locale: the locale to resolve the key in.
|
|
/// - Returns: the localized string, falling back to the source language, then to the key itself.
|
|
func string(
|
|
for key: String,
|
|
in locale: Locale
|
|
) -> String
|
|
|
|
}
|