Krud components follow a structured approach to ensure clean separation of concerns. The architecture is divided into several layers, each with a specific role, promoting maintainability and scalability:
Routing Layer: This is the entry point for all incoming requests. Routes define the endpoints available in the Krud server, directing requests to the appropriate Service Layer based on the request path and method.
Service Layer: Services act as the intermediary between the route handlers and the repository layer. This layer contains business logic and rules, request validation, and orchestration of data operations.
Repository Layer: At the core of data management, the repository layer interacts with the database. It abstracts the data access, providing a collection of methods for retrieving and storing data.
The Ktor framework is designed to enable asynchronous operations within its routing system by leveraging Kotlin's suspend functions.
This facilitates efficient, non-blocking I/O, optimizing resource use and enhancing concurrent handling of numerous requests
simultaneously without requiring extensive resources.
Krud leverages Ktor's asynchronous nature through suspendable functions in all Service Layers, allowing seamless operations within an asynchronous context.
Conversely, Repository Layers employ intentionally standard non-suspendable functions for transaction management simplicity, avoiding issues that can arise from coroutine-based transactions, such as challenges with nested transactions, rollbacks, or scenarios where repositories may need to invoke other repositories. This approach ensures straightforward transaction processing, with repositories designed to be accessed only from within suspendable Service Layer methods.