Saturday, August 13, 2022
HomeiOS DevelopmentThe repository sample for Vapor 4

The repository sample for Vapor 4


Fluent is basically damaged


The extra I take advantage of the Fluent ORM framework the extra I understand how arduous it’s to work with it. I am speaking a few explicit design subject that I additionally talked about within the way forward for server facet Swift article. I actually don’t love the concept of property wrappers and summary database fashions.


What’s the issue with the present database mannequin abstraction? To start with, the elective ID property is complicated. For instance you do not have to supply an identifier once you insert a report, it may be an nil worth and the ORM system can create a singular identifier (beneath the hood utilizing a generator) for you. So why do now we have an id for create operations in any respect? Sure, you would possibly say that it’s potential to specify a customized identifier, however actually what number of instances do we want that? If you wish to determine a report that is going to be one thing like a key, not an id subject. 🙃


Additionally this elective property may 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 elective property should you’re certain that the identifier already exists, however this isn’t a secure strategy in any respect.


My different subject 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 need to be courses. BUT WHY? IMHO the explanation pertains to this subject: you’ll be able to question the database fashions utilizing the mannequin itself. So the mannequin acts like a repository that you should use to question the fields, and it additionally represents the the report itself. Is not this in opposition to the clear ideas? 🤔


Okay, one last item. Property wrappers, subject keys and migrations. The core members at Vapor informed us that this strategy will present a secure method to question my fashions and I can make certain that subject keys will not be tousled, however I am truly fighting versioning on this case. I needed to introduce a v1, v2, vN construction each for the sphere keys and the migration, which truly feels a bit worse than utilizing uncooked strings. It’s over-complicated for certain, and it feels just like the schema definition is blended up with the precise question mechanism and the mannequin layer as properly.


Sorry people, I actually recognize the trouble that you have put into Fluent, however these points are actual and I do know which you can repair them on the long run and make the developer expertise rather a lot higher.


Methods to make Fluent a bit higher?


On the quick time period I am making an attempt to repair these points and happily there’s a good strategy to separate the question mechanism from the mannequin layer. It’s referred to as the repository sample and I might 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 thought is that you simply wrap the Request object right into a customized repository, it is often a struct, you then solely name database associated queries inside this particular object. If we check out on the default mission template (you’ll be able to generate one by utilizing 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, to any extent further you do not have to make use of the static strategies on the mannequin itself, however you should use an occasion of the repository to change your database rows. The repository could be hooked as much as the Request object by utilizing a typical sample. The most straightforward approach is to return a service each time you want it.


import Vapor

extension Request {
    
    var todo: TodoRepository {
        .init(req: self)
    }
}


After all this can be a very primary resolution and it pollutes the namespace beneath the Request object, I imply, when you have a lot of repositories this is usually a downside, however first let me present you how one can refactor the controller by utilizing 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 manner we had been in a position to remove 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 now we have to determine one thing about that subject. 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 will outline a shared repository registry utilizing the Utility extension. This registry will permit us to register repositories for given identifiers, we’ll use the RepositoryId struct for this goal. The RepositoryRegistry will have the ability to return a manufacturing facility occasion with a reference to the required request and registry service, this manner we’re going to have the ability to create an precise Repository based mostly on the identifier. After all this complete ceremony could be prevented, however I needed to provide you with a generic resolution to retailer repositories beneath 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: Utility
    personal var builders: [RepositoryId: ((Request) -> Repository)]

    fileprivate init(_ app: Utility) {
        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)` will not be 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 Utility {

    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 need to provide you with a brand new distinctive identifier and lengthen the RepositoryFactory together with your getter on your personal repository kind.


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 will not be configured")
        }
        return consequence
    }
}


We will now register the FluentTodoRepository object, we simply need to 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 way of the req.repositories.todo property. You do not have to vary 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
    }
}


One of the best a part of this strategy is which you can merely exchange 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 beneath the repositories key.


You’ll be able to provide you with a generic DatabaseRepository protocol with an related database Mannequin kind, then you possibly can implement some primary options as a protocol extension for the Fluent fashions. I am utilizing this strategy and I am fairly proud of it up to now, what do you suppose? Ought to the Vapor core workforce add higher assist for repositories? Let me know on Twitter. ☺️




RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular