Description
What?
Move Sobek entirely out of the business logic.
Why?
- Prevent Sobek data races.
- Better type-safety using native Go constructs.
- Developer productivity increase.
- Separation of concerns.
- Moving Sobek handling to the mapping layer will make the code easy to reason about, reduce the business logic's Sobek dependency, and simplify the business logic code and tests.
- Having Sobek in the business logic requires constant encoding and decoding.
Desobekifying Sobek transformation
Besides moving the calling of Sobek option parsing in the business logic, we also plan to move the Sobek-dependent option parsing part out of the business logic. Once we finish doing the same with the rest of the option parsing, we can entirely remove the Sobek dependency from the business logic.
We currently parse Sobek values into our business logic types, but the parsing dependency is in an unrelated package (common). To enhance maintainability, we move the parsing process and keep related components together (in the mapping layer). Additionally, we could implement a Validate method for the business types (in the common package) to check their validity separately from the Sobek transformation.
Moreover, we use pointers quite liberally, which is not good in terms of reduced performance and also because of many nil-pointer panics. Also, since our module is highly current, it's dangerous to have so many pointers around. So, another goal would be to get rid of as many pointer-ed options as possible to boost stability even more.
See grafana/xk6-browser#1510 for an example.
