Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
SavedObjectsRepository code cleanup (#157154)
## Summary Structural cleanup of the `SavedObjectsRepository` code, by extracting the actual implementation of each API to their individual file (as it was initiated for some by Joe a while ago, e.g `updateObjectsSpaces`) ### Why doing that, and why now? I remember discussing about this extraction with Joe for the first time like, what, almost 3 years ago? The 2.5k line SOR is a beast, and the only reason we did not refactor that yet is because of (the lack of) priorization of tech debt (and lack of courage, probably). So, why now? Well, with the changes we're planning to perform to the SOR code for serverless, I thought that doing a bit of cleanup beforehand was probably a wise thing. So I took this on-week time to tackle this (I know, so much for an on-week project, right?) ### API extraction All of these APIs in the SOR class now look like: ```ts /** * {@inheritdoc ISavedObjectsRepository.create} */ public async create<T = unknown>( type: string, attributes: T, options: SavedObjectsCreateOptions = {} ): Promise<SavedObject<T>> { return await performCreate( { type, attributes, options, }, this.apiExecutionContext ); } ``` This separation allows a better isolation, testability, readability and therefore maintainability overall. ### Structure ``` @kbn/core-saved-objects-api-server-internal - /src/lib - repository.ts - /apis - create.ts - delete.ts - .... - /helpers - /utils - /internals ``` There was a *massive* amount of helpers, utilities and such, both as internal functions on the SOR, and as external utilities. Some being stateless, some requiring access to parts of the SOR to perform calls... I introduced 3 concepts here, as you can see on the structure: #### utils Base utility functions, receiving (mostly) parameters from a given API call's option (e.g the type or id of a document, but not the type registry). #### helpers 'Stateful' helpers. These helpers were mostly here to receive the utility functions that were extracted from the SOR. They are instantiated with the SOR's context (e.g type registry, mappings and so on), to avoid the caller to such helpers to have to pass all the parameters again. #### internals I would call them 'utilities with business logic'. These are the 'big' chunks of logic called by the APIs. E.g `preflightCheckForCreate`, `internalBulkResolve` and so on. Note that given the legacy of the code, the frontier between those concept is quite thin sometimes, but I wanted to regroups things a bit, and also I aimed at increasing the developer experience by avoiding to call methods with 99 parameters (which is why the helpers were created). ### Tests Test coverage was not altered by this PR. The base repository tests (`packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts`) and the extension tests (`packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.{ext}_extension.test.ts`) were remain untouched. These tests are performing 'almost unmocked' tests, somewhat close to integration tests, so it would probably be worth keeping them. The new structure allow more low-level, unitary testing of the individual APIs. I did **NOT** add proper unit test coverage for the extracted APIs, as the amount of work it represent is way more significant than the refactor itself (and, once again, the existing coverage still applies / function here). The testing utilities and mocks were added in the PR though, and an example of what the per-API unit test could look like was also added (`packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/apis/remove_references_to.test.ts`). Overall, I think it of course would be beneficial to add the missing unit test coverage, but given the amount of work it represent, and the fact that the code is already tested by the repository test and the (quite exhaustive) FTR test suites, I don't think it's worth the effort right now given our other priorities. --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Loading branch information