Skip to main content

1.2 Goals & Comparison

why does this exist?

Design Goals​

Suppose you have a domain (example.com) and a "shortened" domain (ex.co), and you don't feel particularly comfortable paying out of your ass to get bitly/rebrandly's features, or you just want to control the data and want to host it yourself.

So you look for an open-source alternative that you can self-host. Currently, the only "feature-full" one is https://kutt.it, but you hesitate to use it for several reasons:

  1. It uses neo4j for its database even though link shorteners really are just supposed to be key-value stores (ex.co/foo => example.com/bar). This happened because it tried to cram in the actual link shortener with the analytics part, and the end result is that it is makes hosting unnecessarily difficult and/or expensive. It's $current_year; hosting SQL databases have become a science, whereas neo4j... yeah.
  2. Maybe you don't like the UI or the content of the analytics. It is actually pretty basic for what it offers, plus it offers no flexibility in querying. You want analytics more akin to what bitly provides.
  3. It's actually rather heavy, especially for what it does. And again, because it jams in analytics to the link shortener... the server always gets a hit for every request to the shortened domain (ex.co), so you'd need to manually scale the server/database when you suddenly get a surge in traffic.

That's why blink exists, with the goals of:

  1. Simplifying deployment: it's just a node server + a SQL database (my choice is pg). At $current_year, everyone and their mother offer some way of hosting that for you. All you should have to do is to literally just click the Heroku button (see the install section). Even hosting it yourself would be simple, as there are fewer moving parts. And since the server gets essentially no load no matter how the traffic is (see point number 3 below), you don't have to worry about things like scaling, freeing your time.
  2. Decoupling analytics: by decoupling the analytics component from the link shortener server, we achieve several things. For one, this allows for a "basic" install where you only install the link shortener part (without the CDN), which makes deployments & maintenance brain-dead simple. For another, you can use whatever analytics solutions you want, as the link analytics is actually based on access logs, the thing all servers/CDNs have (well, unless you use Cloudflare)!
  3. Using CDNs: thanks to the decoupling of analytics and the link shortener, we can put CDNs in front of our server to aggressively cache redirect responses so that the server eventually has to do literally zero work (this is the "secret sauce") as all requests will be served by the CDN, while making the link shortener effectively globally distributed (and thus lower response times). In addition, we can use the CDN's access logs for analysis, and at $current_year, clickstream analysis on access logs is essentially a solved problem, which I don't have to reinvent (plus, you can choose your own)!

Universal App/Isomorphism​

A side goal for this project (and its core dependencies, including https://github.com/JaneJeon/objection-authorize), is to keep it universal. This means actually reusing code between the frontend and the backend, such as the validation (all based on standards-compliant JSON schema), or the access control (the same ACL can be integrated into the frontend while it is made transparent thru the use of objection-authorize on the backend - see policies/).

In fact, this project is essentially a "proving ground" for such a concept, which would allow for rapid development for future applications and would result in fewer places to break due to the (mis)coordination between frontend and the backend teams.