An extension should:

1. Have a specific, targeted purpose.

• At some point in the future there may be a "general" dashboard, but that hasn't been built and would probably come from taking the best 1-2 parts of each targeted extension.

2. Practice DRY (Don't Repeat Yourself) + build re-usable common code when possible

• The current way that libraries are being implemented is a bit hacky. CommonLib has scripts to push the libs out to the individual Extensions. So the workflow is: Make the desired change in CommonLib -> run the script to push it out.

• Linking to an external script source seems to be questionable for a Chrome background page (security concerns). It also would make the Extension reliant on external (non-packaged) resources. Kind of a pain for development to have to switch that out.

3. Be respectful of data sources and try to be a good citizen.

• Without data we've got nothing. Don't spam or excessively load servers that we interact with.
• Keep in mind that what we make may have thousands of users in the future (of course if it doesn't and we design for that, that's ok too).
• Cache. Consider the datasource and how frequently it realistically should be updated with an actual call. This probably starts locally, but I've been considering have a single scraper posting raw data to the Github page and then everyone pulls those in. We could include an option to disable this and scrape + cache locally.
• Hoping for "tick by tick" or near real time performance is probably unrealistic and unproductive. 5-15 minute trends is what I believe we can reasonably hope for in terms of time granularity. Moreover, I'd argue that if your trading strategy revolves around sub-minute data you're probably just LARPing as the worlds worst high frequency algorithm.

---

Dashboards vs tabs of webpages

Currently a lot of our functionality is just opening pages that are useful for some purpose for a specific company. This is both easy and reasonably effective. As we go forward it makes sense to begin taking the data from those pages and putting together our own page. This involves more time and design work though, so still a work in progress.

---

General Structure (currently just my thoughts based on a week of work on the extensions. Desired, not currently all in place)

1. constant.js

• Define the constants your extension uses.

2. cache.js

• Handle interaction with our caching mechanism (chrome storage? Issues with size limits on that?)

3. datafetch.js

• Should consult the cache, may scrape or pull from an external cache based on its defined data staleness policy.

4. \lib\

• Our CommonLib contents get put in this directory (currently lib.js, jquery.min.js).

5. Your application logic