mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-05 16:10:43 +00:00
Patrick Sullivan
c97db7b29f
## Summary This PR only refactors code and should not result in any behavioral changes. This PR divides our folder code into distinct "HTTP Layer" and "Service Layer"s - where the "HTTP Layer" contains only logic and models related to serializing/deserializing for the REST HTTP API, and the "Service Layer" contains only domain models/logic and is agnostic to the REST HTTP API. Specifically, the following changes are made to the code... 1. Move all HTTP responses out of the `service` module and and into the `http/request` module. 2. Introduce a new `FolderError` in the `service` module to model all types of "domain logic" errors that occur when interacting with folders. 3. Introduce new `...Response` and `...Request` types in the `http/request/models` module whose role is specifically to define serialization/deserialization definitions for the REST HTTP API. 4. Remove the `service/db/folders` module since, after the migration of folders from the `meta` table to the `folders` table, this module mostly just acted as a wrapper around the `infra/table/folders` module. ## Overall design goals The design goal here is to create a clearer divide between the "HTTP Layer" and "Service Layer" of the application and to decouple the models in these layers so that models in one layer can change without introducing breaking changes to models in the other layer. Changes to a model in one layer only need to be accompanied with appropriate changes to the translation functions between that model and others.  ## Immediate motivation and next steps I would like to replicate this pattern with Dashboards as well as Alerts and Reports. Implementing this pattern in Folders seems like a reasonable place to start since Folders are much less complicated that Dashboards or Alerts, and Dashboards (and soon-to-be Alerts) are dependent on Folders since each Dashboard belongs to a parent Folder. With Dashboards, I have an immediate need to divide "HTTP Layer" and "Service Layer" models because as parts of #5198 and #5196 I need to change the data structure of dashboards that are returned by `ListDashboards` so that they are different from the `Dashboard` data structure defined in the "Service Layer" - specifically I need each "dashboard" returned by `ListDashboards` to contain the parent folder's name and ID, and I need each "dashboard" returned by `ListDashboards` to exclude the details inside the `v1`,...,`v5` fields. Additionally, when implementing the migration of dashboards from the `meta` table to the `dashboards` table, I ran into a lot of avoidable bugs because our "HTTP Layer", "Service Layer", and "DB Layer" models for dashboards are all coupled together - reusing the same structure and serialization/deserialization logic. Therefore, when I changed the model in which we stored dashboards in the DB, this also accidentally introduced a breaking change (with no compiler error) to the way dashboards are serialized/deserialized in the HTTP API. Maintaining separate models and translation functions for these 3 layers would have prevented these issues. Therefore, when I start migrating alerts to there own table, I would like to start by dividing our models for alerts into "HTTP Layer", "Service Layer", and "DB Layer" models to avoid the same problems I faced while migrating dashboards. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced new data models for folder management in the API, enhancing request and response structures. - Added an asynchronous function to check for folder existence by ID. - **Improvements** - Enhanced error handling with a new `FolderError` enum for better clarity in folder management operations. - Improved type safety by specifying request body types for folder creation and updates. - Refactored folder management API endpoints for clearer response structures. - **Bug Fixes** - Updated folder management API endpoints to ensure more accurate responses and error handling. - **Documentation** - Updated OpenAPI documentation to reflect new folder management schemas and remove outdated components. <!-- end of auto-generated comment: release notes by coderabbit.ai -->