feat: write backup files when streaming

[kwasniew]

About the changes

Changes:

• Extract shared backup functionality - Moved file saving logic from ToggleFetcher to new BackupFileWriter class for reuse between polling and streaming modes

Important files

Discussion points

[kwasniew]

extracted from toggle_fetcher so that we can share it between polling and streaming

[rarruda]

Bikeshedding: This might be better served / mode idiomatic by using MixIns in Ruby.

Here is an example:

https://blog.appsignal.com/2021/01/13/using-mixins-and-modules-in-your-ruby-on-rails-application.html

or

Using include with Modules (Mixins):
The include keyword is used to add a module's methods as instance methods to a class. This is a common way to achieve "mixin" behavior, sharing functionality across unrelated classes.

module Greetable
  def greet_instance
    puts "Hello from the instance!"
  end
end

class MyOtherClass
  include Greetable # Adds greet_instance as an instance method
end

my_instance = MyOtherClass.new
my_instance.greet_instance # Output: Hello from the instance!

[kwasniew]

Questions I asked myself:

• do I need to access object state from a mixin method?
• do I want save file operation in fetcher API and streaming processor API?
• is toggle fetcher and streaming event processor a backup file writer (IS-A) or does it use (HAS-A) a backup file writer?
• is this code readable for somone maintaining 5 other SDKs on a daily basis?

It lead me to the current solution.

[sighphyre]

is this code readable for somone maintaining 5 other SDKs on a daily basis

❤️

I think this solution is fine honestly. If I were going to fuss, it'd be in the direction of making this explicitly stateless rather than the tacit connection that a MixIn brings here. I vote we leave it alone, I think it's a nice improvement to the code structure

[rarruda]

Your points make sense! Go for it!

[sighphyre]

Awesome, thank you!

[sighphyre]

is this code readable for somone maintaining 5 other SDKs on a daily basis

❤️

I think this solution is fine honestly. If I were going to fuss, it'd be in the direction of making this explicitly stateless rather than the tacit connection that a MixIn brings here. I vote we leave it alone, I think it's a nice improvement to the code structure