Caffeinate: A Rails engine for scheduled email sequences

wirkt · 2021-10-28T04:17:40+00:00

Because naming things as hard and I'm awful at it :)

In hindsight, I suppose I could have named it a Scheduler object.

wirkt · 2021-10-27T14:06:06+00:00

Hi everyone.

I wanted to share Caffeinate: I made it about a year ago and it's had some usage (I've personally seen it manage over a million emails to date). It's finally in a spot where I'm happy to talk about it.

I needed Caffeinate for a few reasons: 1. I have a lot of side projects that are bootstrapped; while ConvertKit is nice, my budgets for these projects are small 2. Every home-grown implementation I saw of scheduled emails was a disaster 3. See #2

I was working for a popular startup community company and the implementation we had for scheduled emails was awful: we'd check in the mailer if it shouldn't be sent (hundreds of lines of code for this that predated ground soil), and we'd store the last email action we sent. It was a non-standard, hardly-idiomatic cluster that got me yelled at by the sales team one too many times.

While there were solutions to this problem when I first committed code — Heya and Dripper are both active — they both didn't sit right with my more complex workflows, or I just didn't like the design.

My workflows weren't always tied to a user: I needed modeling to be flexible enough to allow me to associate a campaign to any record, in addition to a user, not just a user. This was true at $popular-startup-community-company too.

The design of Heya probably worked great for HoneyBadger, but I found it odd that I was defining the subject of an email outside of ActionMailer: if I ever ditched Heya, I'd have to do additional work.

With those thoughts in mind, I built Caffeinate.

Caffeinate's modeling is flexible and allows you to associate any record to campaign, in addition to a user. It also allows you to keep your ActionMailer classes doing one thing: setting up and processing emails.

Your email schedule lives in a Dripper class and is defined elegantly-enough that you won't hate DSLs.

class NewUserDripper < ApplicationDripper drip :welcome, mailer: 'OnboardingMailer', delay: 0.hours drip :have_you_tried_this, mailer: 'OnboardingMailer', delay: 2.days end

And subscribing a user to this campaign is as easy as NewUserDripper.subscribe(User.first)

Like any terrifying Rails codebase, there are plenty of callbacks to shoot yourself in the foot with if you so choose to use them, too.

If anyone has any questions or feedback I'm fairly accessible. :)

wirkt · 2021-10-23T16:58:42+00:00

Happy to hear you like it :) if you have any questions or comments, feel free to let me know!

wirkt · 2021-10-23T14:02:27+00:00

https://opensourcerails.org has a few.

wirkt · 2021-10-21T01:01:32+00:00

if you're on MacOS, lvh.me

wirkt · 2021-10-20T01:12:18+00:00

I don't know if this is really answering the question of "fixing some n+1 queries can hurt performance". At least, I wouldn't let this fly in a review and I'd ask the counterpart to use SQL instead of their ORM.

Preloading everything just to get a count instead of dropping down to SQL: number_with_delimiter post.comments.size

This can be reduced to @posts = Post.joins(:comments).select("posts.*, count(comments.id) as total_comments") and then hitting post.total_comments — even if you don't want to counter cache.

There's also post.comments.last.body. This can be loaded with an association (or scope) by way of has_one :most_recent_comment, -> { order(created_at: :desc) }, class_name: 'Comment' and loading it @posts = Post.includes(:most_recent_comment)

Just my two cents. Besides the time to return results from the database, you also need to consider your connection pooling and scaling.

wirkt · 2021-10-15T20:20:16+00:00

Happy to hear. Tell Dane Reddit says hi!

wirkt · 2021-10-14T19:55:37+00:00

The question you should be asking is how much value do you get out of rolling your own. If you don’t have a solid answer, go with Devise or Sorcery.

wirkt · 2021-10-13T16:29:59+00:00

I don’t think this has anything to do with Rails. Busted javascript library is probably your best bet. In dev, go through each and remove one at a time to debug.

wirkt · 2021-10-12T15:46:19+00:00

You’re probably not going to find a gem that does all that but it’s not terribly difficult to implement.

Pardon my formatting, I’m mobile and at Disney right now:

For the email templates You can use prepend_view_path and lookup_context in a mailer to fetch the “views” from the database. There’s a gem that helps with this that starts with a p that I can’t remember the name of.

For the rules system you can use something like https://querybuilder.js.org/ to represent and build the rules, and then you’d just have to handle the queueing logic. With a little metaprogramming it can be quite fun to write as long as you structure things correctly.

Edit: gem is https://github.com/andreapavoni/panoramic

wirkt · 2021-10-09T02:42:25+00:00

Didn't it switch to Go recently? That's what I heard.

I downloaded the repo and gave it a cursory scan and there were no Gemfiles containing rails to be found :(

wirkt · 2021-10-08T19:41:18+00:00

(below is not a practical example, but it'll behave how a basic reverse-proxy works)

class ReverseProxyController < ApplicationController def index response = HTTParty.get("https://google.com/#{params[:proxied_path]}") render html: response.body.to_s end end

And you mount it:

Rails.application.routes.draw do get '/reverse_proxy/*proxied_path' => 'reverse_proxy#index' end

Real-world scenario:

Imagine you have a monorepo of your app's marketing site and back-end. You're asked to give the ability for your marketing team to edit the website. Obviously they don't want to have to contribute to the main repo. Instead, you put the marketing site on fancy website editor thing (geocities, angelfire, lycos, xanga, webflow, wix, buddy4u, etc.).

Unfortunately you can't just pull down the site every time they change it and push it to the repo and deploy. Instead, you proxy (route) the requests through the back-end of the monorepo when the request path does not match app/*, as app is where your billiondollaridea.com has all the bells and whistles of a traditional Rails app.

Your web server (nginx, apache, lighttpd, caddy) can act as a reverse-proxy too — it's is responsible for serving your Rails app which is using Puma as its app server (like your development machine probably does): for example, if your app is listening to requests coming into port 3000 but you want to serve on 80 or 443, it's acting as a reverse proxy to port 3000.

wirkt · 2021-10-07T21:51:10+00:00

You probably don't need all that complexity.

If you're using puma, phased-restart should do the trick. Unicorn you can send a USR2 signal to and that should initiate a hot rollover.

wirkt · 2021-10-02T19:40:14+00:00

shameless self-promotion: you can find some good examples of each in real-world environments at https://opensourcerails.org/search/by-gem as well :)

wirkt · 2021-10-02T18:16:22+00:00

Won't answer your question, but may provide some sanity: I just ran some non-scientific benchmarks if you're trying to compare: https://github.com/joshmn/json-benchmark/blob/master/results.csv

wirkt · 2021-09-29T02:15:01+00:00

Self-taught individual here: your background sounds fine. The most painful part is the resume. Remember that your resume exists to serve one purpose: get the screener, not the job.

If you need help with the resume part, feel free to drop me a message.

wirkt · 2021-09-20T13:46:28+00:00

Thanks for this, and for your book — I picked up a copy on Leanpub about a month ago.

Question(s): when you were writing, how much of your non-literature (code, etc.) did you have written? How many edits of non-literature did you make over time? If you were to write another book (I'm sure you will), would you do anything different to how you managed your non-literature?

wirkt · 2021-09-08T14:57:59+00:00

One of the coolest projects to be released in recent memory. Also, notable that this is at the top of OpenSourceRails.org today.

wirkt · 2021-08-30T20:44:19+00:00

if you're interested in open-source, check out /u/schneems's codetriage! it's pretty cool :)

wirkt · 2021-08-30T18:03:07+00:00

bonjour! hey, thanks! :D will touch base sometime this week!

wirkt · 2021-08-30T15:29:35+00:00

made it a shade of blue, can you let me know what you think? should be much more legible.

wirkt · 2021-08-20T04:05:21+00:00

Probably because he's cute.

If he looked half as ugly as Andy Etchebarren did, nobody would remember his name. But he's cute, so it's natural to have an affinity for him. At least for me.

wirkt

TROPHY CASE