Let’s talk about Barback’s stack!
First: overall its a pretty weird, overcomplicated thing. I’ll preface everything with that. The app itself is pretty vanilla, but the infrastructure I’ve built around it is pretty strange. That is somewhat intentional: most of the choices were motivated more by hey, what would be fun to do here? than what would be the quickest and most reasonable solution?.
Let’s dive in!
Campari is the actual data engine for the entire thing — basically a big converter that transforms the raw YAML recipes I write into JSON (for the app), Markdown (for the website), and SQLite (for manual use).
This means I can write stuff like this:
- name: "Brandy Old Fashioned" source: http://www.jeffreymorgenthaler.com/2012/brandy-old-fashioned/ emoji: 💐 ingredients: - 6cl Brandy (or Cognac) - Angostura bitters (Two dashes) - Sugar cube - Orange wedge - Cherry directions: "T In a chilled old fashioned glass, muddle the sugar, bitters, orange wedge and cherry into a thick paste, careful not to work the orange peel. Add brandy or Cognac, stir, and fill glass with crushed ice and serve." garnish: “” glassware: old fashioned information: “Jeffery Morganthaler has the [definitive](http://www.jeffreymorgenthaler.com/2012/brandy-old-fashioned/) take on a Brandy Old Fashioned, which is an entirely different beast than the classic Old Fashioned you may be used to.”
And have it transformed into the various formats that I need everywhere else. I write the recipes in YAML because its the easiest to write in (specifically things like ingredients, which I can write in near-plaintext and transform them into objects down the line.)
This has grown a little more frustrating as the amount of recipe metadata that I’m tracking grows: I could see this eventually moving full-time to an SQLite database that gets a bunch of post-processing.
The entire thing is just a big Python script. The only PIP dependencies are
Angostura is the static site that lives on
getbarback.com. It runs on Hugo which, after having used it for both my personal site and this, I think is an interesting but flawed solution. The main thing Hugo offers is performance but at the cost of UX and good templating design.
Fernet is the marketing platform, which is a kind way to say “we have a bunch of RSS feeds from which we treat random articles every hour”. It’s doing somewhat well — @getbarback is sitting at around 300 followers for like, an afternoon’s worth of scripting work and three months of waiting — but could be better.
Some stuff here that can be improved, in no specific order:
- Expanding past Twitter into other social networks (namely Tumblr and Pinterest)
- Actually linking to
- Better filtering of posts for timeliness: we have a couple St. Patrick’s Day cocktail posts that get tweeted in the autumn, stuff like that.
Rye (which is a term that doesn’t actually exist within the codebase yet) is the app itself! It’s the main thing, written originally in Objective C and migrated to Swift 2.
This is the codebase that I think I’ve hacked on personally for the longest period of time — counting the 1.0 version of the app, which was written in Objective-C and discarded whole-cloth, I’ve worked on Manhattan for around eighteen months. It’s gone from a gross Objective C app to a gross Swift app to a fairly ungross but also extremely untested Swift app, and while there are definitely a lot of pieces that still need to be polished I’m happy with where it’s at.
There are a bunch of moving parts and interesting things here in terms of design decisions made, but the big one is that we use Realm for data storage. I’ll write more about that later, since I have a lot to say about the tradeoffs between that, Parse, and Core Data.