René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Factor out storage key generation logic, to eliminate code duplication","articleBody":"This is a small-ish refactoring chore. See https://github.com/gojek/feast/pull/360#discussion_r362778747\r\n\r\nCurrently there is some code duplication between ingestion and serving for the generation and parsing of Redis keys. We multiplied this in the course of implementing Cassandra storage (#360), as it is already a large change set we didn't want to introduce additional Redis refactoring to it and thus decided to log it as a follow-up.\r\n\r\nThis could be done for Redis independent of and before integrating the Cassandra implementation though, and Cass implementation can be updated to follow the pattern if so.\r\n\r\n_Update_: The below storage modularization was realized through #529 and subsequent PRs that implemented its interfaces. This issue remains for tech debt of code duplication that still remains, enumerated in https://github.com/gojek/feast/issues/402#issuecomment-623264345\r\n\r\n~~In the interest of storage modularization to minimize dependency headaches in the future (something I believe we'll hash out in further RFC issues), I propose something like this:~~\r\n\r\n~~1. A `storage-api` module, which defines an interface something like `KeyUtil`~~\r\n~~1. A `storage-redis` implementation module which implements `KeyUtil` for Redis~~\r\n\r\n~~I'm open to better naming suggestions, structure is more my focus here.~~\r\n\r\n~~The `KeyUtil`s could ideally be `static` so that unit testing them is trivially simple and the unit tests can serve as a good spec/documentation of the key format.~~","author":{"url":"https://github.com/ches","@type":"Person","name":"ches"},"datePublished":"2020-01-03T11:44:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/402/feast/issues/402"}