Day 193: Browserflow Master Plan

engineering

Alright, I’m gonna lay it all out here. I might’ve written about this before, but I feel like I’ve been on a treadmill so this is a good exercise to remind myself of the bigger picture for Browserflow.

For the past 50 days, I’ve been working on Browserflow and I (still!) haven’t launched. This might be a classic case of the Pareto principle — I feel like I created 80% of what I have right now in the first 2 weeks (I mean, this demo is basically what I have today), and I’ve been grinding on the last 20% for the rest of the time. I guess that makes sense given that I spent two weeks or so refactoring and then refactoring the refactor by moving everything over to Redux.

I got really, really, really excited a few weeks ago because I saw that Puppeteer is moving towards creating an environment-agnostic version that doesn’t depend on Node.

If you don’t know what Puppeteer is, it’s a “library which provides a high-level API to control Chrome”. If that sounds a lot like what Browserflow does, you’re absolutely right. You can break down Browserflow’s functionality into two areas:

  • Creating flows
  • Replaying flows

Creating flows involves recording users’ actions and making it easy to write scripts and select elements to interact with.

Replaying flows involves reliably performing those actions exactly as the user intended.

Puppeteer would make the second task much, much easier. So far, I’ve been writing a bunch of low-level code to replay users’ actions in the browser. For example, in order to simulate a key press, I was working with individual commands and events in order to emit keydown, keypress, beforeinput, input, keyup. I had to look at what kind of key was being pressed, whether it was being pressed with other keys, and a bunch of boring stuff that I don’t really want to think about. With Puppeteer, I can just write keyboard.type('YO YO YO') and Puppeteer will take care of everything for me!

On one hand, it’s kind of a bummer that a lot of my work will become obsolete since it overlaps with a lot of what Puppeteer does. On the other hand, I’d much rather use a popular, well-designed library to handle a bunch of these tasks rather than implement them myself.

The best part about moving everything over to Puppeteer is that it enables running flows in the server! If someone wants to monitor a specific keyword on Twitter and receive an email every morning with the top 5 results, I can simply run Puppeteer commands in a server to enable that functionality without them having to do anything locally.

So, the master plan:

  1. Create the dopest recording + editing experience for creating and running flows locally
  2. Replace all of my “playback” functionality with Puppeteer
  3. Create a platform to run flows in the cloud
  4. ???
  5. PROFIT

Result: People can create and run flows locally, and with a click of a button, choose to have it run automatically in the cloud at their desired interval

Unfortunately, Puppeteer isn’t quite yet environment-agnostic (and there’s no timeline for when that work would be complete), but I’m stoked that it’s in the works.