Fluent is basically damaged
The extra I take advantage of the Fluent ORM framework the extra I understand how laborious it’s to work with it. I am speaking a couple of specific design problem that I additionally talked about within the way forward for server aspect Swift article. I actually do not like the concept of property wrappers and summary database fashions.
What’s the issue with the present database mannequin abstraction? To begin with, the non-compulsory ID property is complicated. For instance you do not have to supply an identifier whenever you insert a document, it may be an nil worth and the ORM system can create a novel identifier (below the hood utilizing a generator) for you. So why do we’ve an id for create operations in any respect? Sure, you may say that it’s potential to specify a customized identifier, however actually what number of occasions do we want that? If you wish to establish a document that is going to be one thing like a key, not an id subject. 🙃
Additionally this non-compulsory property could cause another points, when utilizing fluent you’ll be able to require an id, which is a throwing operation, alternatively you’ll be able to unwrap the non-compulsory property should you’re positive that the identifier already exists, however this isn’t a protected method in any respect.
My different problem is expounded to initializers, should you outline a customized mannequin you all the time have to supply an empty init() {} methodology for it, in any other case the compiler will complain, as a result of fashions must be courses. BUT WHY? IMHO the rationale pertains to this problem: you’ll be able to question the database fashions utilizing the mannequin itself. So the mannequin acts like a repository that you should utilize to question the fields, and it additionally represents the the document itself. Is not this in opposition to the clear ideas? 🤔
Okay, one final thing. Property wrappers, subject keys and migrations. The core members at Vapor informed us that this method will present a protected option to question my fashions and I can ensure that subject keys will not be tousled, however I am really fighting versioning on this case. I needed to introduce a v1, v2, vN construction each for the sphere keys and the migration, which really feels a bit worse than utilizing uncooked strings. It’s over-complicated for positive, and it feels just like the schema definition is combined up with the precise question mechanism and the mannequin layer as properly.
Sorry people, I actually admire the trouble that you have put into Fluent, however these points are actual and I do know you can repair them on the long run and make the developer expertise so much higher.
Easy methods to make Fluent a bit higher?
On the brief time period I am attempting to repair these points and luckily there’s a good method to separate the question mechanism from the mannequin layer. It’s referred to as the repository sample and I would like to present an enormous credit score to 0xTim once more, as a result of he made a cool reply on StackOverlow about this subject.
Anyway, the primary concept is that you just wrap the Request object right into a customized repository, it is normally a struct, then you definitely solely name database associated queries inside this particular object. If we check out on the default venture template (you’ll be able to generate one through the use of the vapor toolbox), we will simply create a brand new repository for the Todo fashions.
import Vapor
import Fluent
struct TodoRepository {
var req: Request
init(req: Request) {
self.req = req
}
func question() -> QueryBuilder<Todo> {
Todo.question(on: req.db)
}
func question(_ id: Todo.IDValue) -> QueryBuilder<Todo> {
question().filter(.$id == id)
}
func question(_ ids: [Todo.IDValue]) -> QueryBuilder<Todo> {
question().filter(.$id ~~ ids)
}
func checklist() async throws -> [Todo] {
strive await question().all()
}
func get(_ id: Todo.IDValue) async throws -> Todo? {
strive await get([id]).first
}
func get(_ ids: [Todo.IDValue]) async throws -> [Todo] {
strive await question(ids).all()
}
func create(_ mannequin: Todo) async throws -> Todo {
strive await mannequin.create(on: req.db)
return mannequin
}
func replace(_ mannequin: Todo) async throws -> Todo {
strive await mannequin.replace(on: req.db)
return mannequin
}
func delete(_ id: Todo.IDValue) async throws {
strive await delete([id])
}
func delete(_ ids: [Todo.IDValue]) async throws {
strive await question(ids).delete()
}
}
That is how we’re can manipulate Todo fashions, any longer you do not have to make use of the static strategies on the mannequin itself, however you should utilize an occasion of the repository to change your database rows. The repository could be hooked as much as the Request object through the use of a typical sample. The most straightforward method is to return a service each time you want it.
import Vapor
extension Request {
var todo: TodoRepository {
.init(req: self)
}
}
After all it is a very fundamental answer and it pollutes the namespace below the Request object, I imply, you probably have a number of repositories this could be a drawback, however first let me present you find out how to refactor the controller through the use of this easy methodology. 🤓
import Vapor
struct TodoController: RouteCollection {
func boot(routes: RoutesBuilder) throws {
let todos = routes.grouped("todos")
todos.get(use: index)
todos.publish(use: create)
todos.group(":todoID") { todo in
todo.delete(use: delete)
}
}
func index(req: Request) async throws -> [Todo] {
strive await req.todo.checklist()
}
func create(req: Request) async throws -> Todo {
let todo = strive req.content material.decode(Todo.self)
return strive await req.todo.create(todo)
}
func delete(req: Request) async throws -> HTTPStatus {
guard let id = req.parameters.get("todoID", as: Todo.IDValue.self) else {
throw Abort(.notFound)
}
strive await req.todo.delete(id)
return .okay
}
}
As you’ll be able to see this fashion we have been capable of eradicate the Fluent dependency from the controller, and we will merely name the suitable methodology utilizing the repository occasion. Nonetheless if you wish to unit check the controller it isn’t potential to mock the repository, so we’ve to determine one thing about that problem. First we want some new protocols.
public protocol Repository {
init(_ req: Request)
}
public protocol TodoRepository: Repository {
func question() -> QueryBuilder<Todo>
func question(_ id: Todo.IDValue) -> QueryBuilder<Todo>
func question(_ ids: [Todo.IDValue]) -> QueryBuilder<Todo>
func checklist() async throws -> [Todo]
func get(_ ids: [Todo.IDValue]) async throws -> [Todo]
func get(_ id: Todo.IDValue) async throws -> Todo?
func create(_ mannequin: Todo) async throws -> Todo
func replace(_ mannequin: Todo) async throws -> Todo
func delete(_ ids: [Todo.IDValue]) async throws
func delete(_ id: Todo.IDValue) async throws
}
Subsequent we’ll outline a shared repository registry utilizing the Software extension. This registry will enable us to register repositories for given identifiers, we’ll use the RepositoryId struct for this function. The RepositoryRegistry will be capable of return a manufacturing unit occasion with a reference to the required request and registry service, this fashion we’re going to have the ability to create an precise Repository primarily based on the identifier. After all this entire ceremony could be averted, however I needed to give you a generic answer to retailer repositories below the req.repository namespace. 😅
public struct RepositoryId: Hashable, Codable {
public let string: String
public init(_ string: String) {
self.string = string
}
}
public remaining class RepositoryRegistry {
personal let app: Software
personal var builders: [RepositoryId: ((Request) -> Repository)]
fileprivate init(_ app: Software) {
self.app = app
self.builders = [:]
}
fileprivate func builder(_ req: Request) -> RepositoryFactory {
.init(req, self)
}
fileprivate func make(_ id: RepositoryId, _ req: Request) -> Repository {
guard let builder = builders[id] else {
fatalError("Repository for id `(id.string)` isn't configured.")
}
return builder(req)
}
public func register(_ id: RepositoryId, _ builder: @escaping (Request) -> Repository) {
builders[id] = builder
}
}
public struct RepositoryFactory {
personal var registry: RepositoryRegistry
personal var req: Request
fileprivate init(_ req: Request, _ registry: RepositoryRegistry) {
self.req = req
self.registry = registry
}
public func make(_ id: RepositoryId) -> Repository {
registry.make(id, req)
}
}
public extension Software {
personal struct Key: StorageKey {
typealias Worth = RepositoryRegistry
}
var repositories: RepositoryRegistry {
if storage[Key.self] == nil {
storage[Key.self] = .init(self)
}
return storage[Key.self]!
}
}
public extension Request {
var repositories: RepositoryFactory {
utility.repositories.builder(self)
}
}
As a developer you simply must give you a brand new distinctive identifier and prolong the RepositoryFactory along with your getter to your personal repository sort.
public extension RepositoryId {
static let todo = RepositoryId("todo")
}
public extension RepositoryFactory {
var todo: TodoRepository {
guard let consequence = make(.todo) as? TodoRepository else {
fatalError("Todo repository isn't configured")
}
return consequence
}
}
We are able to now register the FluentTodoRepository object, we simply must rename the unique TodoRepository struct and conform to the protocol as an alternative.
public struct FluentTodoRepository: TodoRepository {
var req: Request
public init(_ req: Request) {
self.req = req
}
func question() -> QueryBuilder<Todo> {
Todo.question(on: req.db)
}
}
app.repositories.register(.todo) { req in
FluentTodoRepository(req)
}
We’re going to have the ability to get the repository by the req.repositories.todo property. You do not have to alter the rest contained in the controller file.
import Vapor
struct TodoController: RouteCollection {
func boot(routes: RoutesBuilder) throws {
let todos = routes.grouped("todos")
todos.get(use: index)
todos.publish(use: create)
todos.group(":todoID") { todo in
todo.delete(use: delete)
}
}
func index(req: Request) async throws -> [Todo] {
strive await req.repositories.todo.checklist()
}
func create(req: Request) async throws -> Todo {
let todo = strive req.content material.decode(Todo.self)
return strive await req.repositories.todo.create(todo)
}
func delete(req: Request) async throws -> HTTPStatus {
guard let id = req.parameters.get("todoID", as: Todo.IDValue.self) else {
throw Abort(.notFound)
}
strive await req.repositories.todo.delete(id)
return .okay
}
}
The very best a part of this method is you can merely change the FluentTodoRepository with a MockTodoRepository for testing functions. I additionally like the truth that we do not pollute the req.* namespace, however each single repository has its personal variable below the repositories key.
You’ll be able to give you a generic DatabaseRepository protocol with an related database Mannequin sort, then you would implement some fundamental options as a protocol extension for the Fluent fashions. I am utilizing this method and I am fairly pleased with it up to now, what do you assume? Ought to the Vapor core workforce add higher assist for repositories? Let me know on Twitter. ☺️
