Version 3 Roadmap

[joshmn]

Between launching RubyOnRails.jobs and being funemployed I've had some ideas as to what I want to make for V3. Please comment or react to the comments below:

1. API Mode Version 3 Roadmap #21 (comment)
2. Standalone appliance: Version 3 Roadmap #21 (comment)
3. Remove dependency of ActionMailer::Base: Version 3 Roadmap #21 (comment)

[joshmn]

API Mode

This would compliment caffeinate-webui

[joshmn]

Standalone appliance

This is a bit more involved, but effectively, I want to use Caffeinate to allow non-technical users to build campaigns and emails. I had the idea (and an MVP) a while ago, but perhaps I make it open-core.

[joshmn]

Remove dependency of ActionMailer::Base

Call any action that responds to a certain set of parameters. Proof of concept here: #14

Edit: Proposed #24

[jon-sully]

Hey @joshmn 👋

Just wanted to reach out and offer interest in helping with this gem/project if you're looking for some! I've spent the last couple of weeks integrating Caffeinate into a rails app I lead, including making our own Texter wrapper that spoofs the ActionMailer API so that Caffeinate is actually firing off both email drips and text drips for us (which is killer!). As such, I've spent lots of time reading through the Caffeinate internals and docs 😆 (PS, I don't think the docs actually mention the every: / perpetual option?)

Anyway, just wanted to reach out!

[joshmn]

Hi @jon-sully!

Ah! Flattered! If you want I'd be happy to put the logo in the readme! That Texter class — so sorry! #14 could help it... :)

I'm open to all ideas! Feel free to make an issue and tag it with the Idea tag and we can discuss there :)

(PS I think you're right — I haven't used it myself yet so I don't know how well it works.... hehe)

[jon-sully]

We almost used it once I discovered it, but since it doesn't allow for any "jitter" we decided to just use a custom setup more like this:

class LongTermDripper < ApplicationDripper
  20.times do |idx|
    drip :random_long_term, mailer: ClientMailer, on: -> { subscriber.morning_delivery((idx * 2).weeks.from_now + rand(0..2).days) + rand(0..180).minutes }
  end
end

Which is like: every 2 weeks at the user's 9am mark, but with up to 2 days and 3 hours of 'jitter' (makes the message seem more organic, less like it's on a schedule). Although that's not quite working yet because each drip call uses the same action name and thus overrides the prior 😅. Working on a PR for you now for that.

Though, now that I type all that out, maybe it'd be better suited to just have a PR that adds 'jitter' functionality to the every: flag!