I’ve written a number of articles about manufacturing unit design patterns on my weblog and this time I might like to speak a couple of particular one, which you’ll encounter when you work with Vapor. This is somewhat recap about my manufacturing unit design sample weblog posts, all written in Swift:
Now let’s dive in to the “Fluent sample”. In an effort to perceive this structure, first we must always study the associated Swift packages first. There may be the FluentKit library and a number of other Fluent database driver implementations (SQLite, PostgreSQL, MySQL, and so forth.), all based mostly on the FluentKit product. Additionally there’s one package deal that connects Fluent with Vapor, this one is just referred to as: Fluent. 📀
- FluentKit – comprises the summary interface (with out Vapor, utilizing SwiftNIO)
- Fluent[xy]Driver – comprises the implementation outlined in FluentKit
- Fluent – connects FluentKit with Vapor, by extending Vapor
That is the bottom construction, the FluentKit library supplies the next summary interfaces, which you must implement if you wish to create your individual driver implementation. Sadly you will not have the ability to discover correct documentation for these interfaces, so I will clarify them a bit:
- Database – Question execution and transaction associated features
- DatabaseContext – Holds the config, logger, occasion loop, historical past and web page measurement restrict
- DatabaseDriver – A manufacturing unit interface to create and shutdown Database cases
- DatabaseID – A singular ID to retailer database configs, drivers and cases
- DatabaseError – A generic database associated error protocol
- DatabaseConfiguration – A protocol to create DatabaseDriver objects
- DatabaseConfigurationFactory – A box-like object to cover driver associated stuff
- Databases – Shared config, driver and operating occasion storage
As you may see there are a lot of protocols concerned on this structure, however I will attempt to stroll you thru the whole driver creation move and hopefully you’ll perceive how the items are associated, and the way can construct your individual drivers and even Vapor parts based mostly on this.
Fluent is written as a service for Vapor utilizing the underlying shared storage object, that is what shops a reference to the Databases occasion. This object has two hash maps, for storing configurations and operating driver cases utilizing the DatabaseID as a key for each. 🔑
Once you ask for a driver, the Databases object will test if that driver exists, if sure, it’s going to merely return it and story over. The attention-grabbing half occurs when the motive force doesn’t exists but within the Databases storage. First the system will test for a pre-registered driver implementation.
app.databases.use(.sqlite(.file("db.sqlite")), as: .sqlite)
This line above registers a brand new driver configuration for the shared Databases. The .sqlite() technique is a static perform on the DatabaseConfigurationFactory which creates a brand new SQLite particular configuration and hides it utilizing the init(make:) name. The SQLite related configuration implements the DatabaseConfiguration protocol, so it may be used as a sound config when the system creates the precise database context.
The config object can also be accountable for creating the particular driver object utilizing the Databases object if wanted. At this level we have a configuration and a driver occasion registered within the databases storage. What occurs if somebody asks for a database occasion?
Relying on the context, you may ask for a Database implementation via the app.db or req.db properties. That is outlined within the FluentProvider code and behind the scenes all the pieces may be traced again to the Databases class. Because you solely wish to have a single shared storage for all of the drivers, however you additionally wish to keep away from the singleton sample, it’s best to hook this service as much as the Utility class. That is how the Vapor of us did it anyway. 🤓
let db: Database = req.db
let db: Database = req.db(.sqlite)
let db: Database = app.db
let db: Database = app.db(.sqlite)
Once you ask for a database, or a database with an specific identifier, you might be basically calling a make technique contained in the Databases class, which goes search for a registered configuration and a driver implementation utilizing the hashes and it will name the motive force’s make technique and move across the logger, the occasion loop and the present database configuration as a database context object.
We are able to say that after you ask for an summary Database driver, a brand new DatabaseDriver occasion reference (related to a given DatabaseID) can be saved contained in the Databases class and it will all the time make you a brand new Database reference with the present DatabaseContext. If the motive force already exists, then it’s going to be reused, however you continue to get new Database references (with the related context) each time. So, it is very important be aware that there’s just one DatabaseDriver occasion per configuration / database identifier, however it could possibly create a number of Database objects. 🤔
Okay, I do know, it is fairly sophisticated, however here is an oversimplified model in Swift:
last class Databases
var configs: [DatabaseID: DatabaseConfiguration] = [:]
var drivers: [DatabaseID: DatabaseDriver] = [:]
func make(
_ id: DatabaseID,
logger: Logger,
on eventLoop: EventLoop
) -> Database
let config = configs[id]!
if drivers[id] == nil
drivers[id] = config.make(self)
let context = DatabaseContext(config, logger, eventLoop)
return drivers[id]!.make(context)
func use(_ config: DatabaseConfiguration, for id: DatabaseID)
configs[id] = config
And the Vapor service extension could possibly be interpreted considerably like this:
extension Utility
var databases: Databases
get
if storage[DatabasesKey.self] == nil
storage[DatabasesKey.self] = .init()
return storage[DatabasesKey.self]
set
self.storage[MyConfigurationKey.self] = newValue
var db: Database
databases.make(
.default,
logger: logger,
eventLoop: eventLoopGroup.subsequent()
)
You possibly can apply the identical ideas and create an extension over the Request object to entry a Database occasion. After all there’s much more taking place underneath the hood, however the objective of this text is to get a fundamental overview of this sample, so I am not going into these particulars now. 🙃
Truthfully I actually like this strategy, as a result of it is elegant and it could possibly utterly conceal driver particular particulars via these abstractions. I adopted the very same ideas after I created the Liquid file storage driver for Vapor and realized loads through the course of. Though, it’s best to be aware that not all the pieces is an effective candidate for being carried out an “summary Vapor service manufacturing unit” design sample (or no matter we name this strategy). Anyway, I actually hope that this fast tutorial will enable you to to create your individual Vapor parts, if wanted. 🤷♂️
