puckpuck
commented
7 months ago Another idea is to specify pre, start, end, and post hooks for each business logic function. The hooks are implemented using empty functions in a separate code file meant to be implemented by forks.
pre - before the span is created/started for business logic start - after the span is started but before any business logic is run end - before the span is ended but after all business logic is run post - after the span is ended
Not all services and business logic areas can implement all 4 of the above hooks, but they should be able to do a start/end or pre/post set of hooks.
The OpenTelemetry demo has 3 stated goals:
The second goal, building a base for vendors and tooling authors to expand and showcase their capabilities, relies heavily on forking this repository and modifying the fork with long-standing modifications without the intent to upstream the changes.
In its current state, this repository offers only a few areas for forks to add modifications while still being able to maintain sync with the base repo. Fork-friendly for the OpenTelemetry demo would mean separating aspects of the services' logic, so forks can add modifications freely without merging the modified files when syncing upstream.
Separating the request handling from business logic for each service can aid this effort. One code file provides an entry point into the service for request handling. Other code file(s) are used to host the business logic, which is called by the request handlers. Forks would be expected to modify the smaller and more succinct business logic code files. Some services like the checkout service, have multiple business logic functions, which could be broken down into multiple logical files.