Although Researchly is not yet ready for launch (its feature-set is still too limited and underdeveloped for it to be commercially viable), I feel that now's a good time to pause and reflect on the project as I'd spent more than a month working on it.

Researchly is a Chrome extension that allows you to save links to a shared collection. In other words, it's a collaborative bookmark manager in the same way Google Docs is a collaborative Microsoft Word.

I came up with this idea while researching different ideas with my friend. We had been pasting links to various articles of different categories in our chat conversation, and it became increasingly difficult to track which articles belonged to which projects. It was also difficult to track which articles either party had seen, so it was important for the user to mark an article as "Read".

How it works

  1. Make sure you're using Chrome, Edge or Opera.
  2. Go to this link and click "Add to Chrome".
  3. Pin the extension next to the address bar after installing it.
  4. Open the extension and click on sign up.

After signing up, open the extension again. You should see something like this.

Click on the "+ New" button to create a new collection.

You can then invite your friends (by copying the invite link) and start saving links to that collection.

Click the green checkmark to mark the article as read, or click the red trash icon to remove the article. Your friend would be able to see links in the collection being updated in realtime.

How I built this

  • The chrome extension was built using React and configured using Webpack. I used this boilerplate as a starting point when building the extension.
  • For the login and signup pages, I used Next.js.
  • The API, socket gateways and backend services were built using Nest JS.
  • I used MongoDB for my database because its cloud has a generous free-tier. I also didn't want to spend too much time designing the schema.
  • I used Turborepo to package the apps in a monorepo.
  • I used Tailwind.css to style my React components.

Challenges

As it was my first time building a Chrome Extension, I felt that my biggest challenges were familiarizing myself with the concept and applications of "message passing" and the Chrome Extension API.

Getting used to the development workflow was also a challenge, because I had to keep multiple browser windows open- 1 for service worker logs, another for content-script logs, another to reload the background script, another to leave the extension popup open, and another just for reading docs.

The most frustrating part of this setup was inspecting logs from the popup. In order to inspect popup logs, I had to right click the popup window and click inspect. However, whenever I switched tabs, the popup would close and so would the console. Every time this happens, I'd have to reopen the popup window to right click the popup again to inspect it, and I'd have to be extra careful in what I click to not close the popup.

Suffice to say, I did not really enjoy chrome extension development compared to website development. That said, it might have had to do with using a flawed (and under-maintained) boilerplate, and I'm sure I could have spent more time looking into how to optimize this workflow.

In terms of technical challenges, I'd say message passing took up the most time for me. Message passing is how the Extension API controls data flow between various application contexts, and there were many instances where this was necessary in Researchly.

For instance, performing authentication is done on a website, but authentication data has to be transmitted to the popup, which operates in an entirely different context. This is performed using a background script - a worker that runs in the background and listens to events at all times (if awake). After the user successfully logs in on the website, a message is passed to the background script, which then passes the message to the popup.

Every user action in the popup also has to go through message passing, because API connections have to be done in the background script. In Researchly, socket events are also handled in the background script. For instance, if user B saves a link, user A should see a new link being saved in real time: a result of a message being passed.

Caching and passing cached "messages" is also especially important, because when opened, the popup has to know whether the user is logged in or not, and if logged in, the user information needs to instantly be shown. If the data is always being fetched every time the user opens the popup, the app will start to feel very clunky.

Learnings

There were many things that I learned while working on this project. My biggest takeaways were the following:

If you're going to build something that solves a personal pain, make sure you're using the product as a tool.

In the beginning, I thought it'd be a good idea to work on this project because I had encountered a pain point while collaborating with my friend. However, I soon no longer had the need for such an extension because we stopped brainstorming and collaborating. As a result, product direction and development motivation suffered. Should I continue working on Researchly, I'd make sure to constantly use the extension as a tool.

Development always takes longer than anticipated.

During this project, I learned a lot about building a chrome extension, as it was my first time doing so. However, this took up a lot of time that I simply did not account for when I set out to build this product. I planned to build and launch the product within a short, limited time period. As a result, the MVP didn't prove to be useful to its intended target audience.