As a developer, what do you do when inspiration hits? How do you plan out your side projects? What do you do when things get hard? When should you quit? These are some of the questions I always ask myself whenever I work on my side projects as a self-taught developer. I don’t really know the correct answer but I often find being able to see the workflow of other people is extremely helpful to my own workflow — being able to pick up bits and pieces to add to my own repertoire is always fun. This article is a reflection on one of the recent projects that I was working on. In showing my own workflow and reasonings throughout the project, I hope to start a discussion on thinking about our own workflow as developers.
The Inspiration Hits
I watch lots and lots of shows, movies, and anime with my friends through the internet using two main applications: Teleparty and Discord. Teleparty is a chrome extension that syncs up the video players from streaming services such as Netflix. Discord is… well who doesn’t know Discord. I love it when inspiration is derived from my own daily experience. In this case, I wanted to take inspiration from both of these technologies and take what I like about each of them to build a screen share app that I would prefer to use.
The Idea
After inspiration hits, I started to think about the features that I want my application to have. Often, this is based on how I want my own experience with the application to be. For this project, I liked the element of how you can obtain a room invite link from Teleparty and share it with your friends. However, I don’t like the real-time syncing which actively modifies the play state of each video player in the room — this leads to quite a bad user experience in my opinion because I would notice that I would be about 1 or 2 seconds ahead or behind my friends.
This time lag issues is fixed when we started to use Discord to stream our movie time sessions. This is also great because if you don’t have access to a particular streaming service but your friends do then you can also watch that with them. The one thing I don’t like about this is that I don’t use Discord that much so it is mildly inconvenient for me to navigate to Discord every it’s movie time (such a big problem I know).
With this, I know I wanted to be able to stream and be able to provide a unique link I can click on to start watching the stream immediately.
The honeymoon phase
This should be easy
- Says every developer before they realize how involved the project is
So what’s the plan? Well, first you need to somehow start the streaming from your computer and then create a unique link that you can give to your friends to join your stream. A Chrome extension is probably the fastest way to go from not streaming to streaming so I decided to go with that. It’s a 2-part process, figure out how to stream your desktop and then integrate that into a Chrome extension. Easy peasy, right?
From my own experience, a detailed plan in the beginning never makes it past the first few articles I read about the subject. However, you still want some kind of plan because your project can go off course really quickly if you don’t have the plan. It’s a difficult situation especially when you don’t know the capabilities of the technologies that you want to integrate together. Your research process can also drag on and on. Often times this is because you are working on a project with technologies that are completely new to you and it really doesn’t help that there are thousands of technologies to solve the same problem.
That said, I have compiled a list of resources that I heavily relied upon in this project here in case anyone wants to check it out themselves.
- MDN screen capture API — a great resource to learn about how to start a screen share stream and put that stream into a video element to be displayed onto the browser
- Web Dev Simplified WebRTC tutorial — I love video tutorials, for some reason I have a hard time with how things are put together when I’m reading. Being a visual learner, I think that I pick up things and am able to adapt them as soon I see how it is done visually. This is a great video by Kyle from Web Dev Simplified explaining how to make a video chat app using peerjs and socket.io
- Peerjs documentation — great documentation and project but became the ultimate bottle-neck in this project
- Coding Train Chrome Extension Tutorial — great video series on how to create Chrome extensions but is a little outdated. Great to use in conjunction with the official Chrome extension documentation
- Official Chrome extension documentation — great to use once you understand a little bit about the chrome extension structure and how messages are passed around
The “I hate this” phase
This is the stage when things don’t go as how you for them to be and you have to use your problem-solving abilities to navigate through.
The screen capture and mediastream was actually fairly simple to understand — you need to create a media stream by prompting the user to allow screen recording and then you can add that stream to a source in a video element. In a software project, it’s not always clear cut when to work on what because things in software are interconnected, for example, I was able to create a screen capture app but how do I store the media stream object using the chrome extension API. I found out that it becomes a normal object once I store it into the sync storage API. This situation sucked because it could have been an easy implementation with the background page which was available in v2 instead of service workers which becomes the standard in v3.
So what are the solutions that I came up with? Well I needed a way to store the information long term and there were only a couple of storage options
1. Storing the information in sync storage
I can’t store it in sync because the information is lost (Maybe there was a way but I wasn’t too sure how to do this)
2. Keep the memory in memory in the content script
This is a possible solution but leads to a few more issues. We cannot use the current page’s script since that would be bad UX because the user can close it at any time and the stream would end immediately. The workaround for this is that we can create a “master tab” that is used to store long-term info. I got the inspiration from the Workona pinned tab which keeps an extension tab always open.
Using this, we can keep the stream stored in a global variable inside the page script within the master tab and the problem is solved.
This however forces the window to navigate away from the current tab (which is likely the tab that the user wants to share in the first place). For a good UX experience, once the user finishes allowing screen sharing, we should go back to the tab that they were at.
Finally, the master tab should close once the user ends the stream because we don’t want to clog up the user’s browser.
The “is this even worth it?” phase
From early on in the project, I decided that I was not going to use a signaling server at least in the MVP which would make the project more complicated. Since as long as another user is able to get their unique id to another peer (the id is passed on in the generated link) you don’t need a server to relay this id to the other client which was important with 2-way communication.
This created some unique problems that were particularly difficult to debug. Calling using peerjs only works if the initiator is calling the browser that wants to connect — I think this was just some bug that exists with peers. This would have been an easy fix if I had a signaling server running but I didn’t (I did solve this problem in the end).
At one point, the screen sharing feature in my app actually worked but then the next day it refused to work. Through lots and lots of debugging, including setting up the peerjs server I refuse to set up in the beginning, nothing worked. In the end, I found out that there was a problem when trying to establish a connection with the peerjs’s default ICE and STUN servers. At this point, I didn’t want to spend more time setting up my own STUN server or to try to create my own peerjs implementation so I decided that I’m going to end this project.
Conclusion
In the end, this was a failed project (for now). If you want to take a crack at it, here is the GitHub repo to the project. Do I think it is a wasted effort? Nah! Even though I failed the project, I still learned a ton about chrome extension development which give me a deeper understanding of how they work behind the scene. Knowing when to abandon a project is also something that I actively work towards — on one hand I don’t want to abandon projects too prematurely but on the other hand sometimes extra efforts wouldn’t add much to my learning. In this case, I believe I ended the project at the right time.
So that was my process of approaching a side project — what is your process? What is your favorite shows anime? What do you think about the article? I would like to hear your thoughts below :)
