ExtPay VS webextensions

I've been using SQLite/Litestream for https://extensionpay.com for about 3 years now! Serves about 120m requests per month (most of those are cached and don't hit the db), but it's been great!

I was convinced that SQLite could be a viable db option from this great post about it called Consider SQLite: https://blog.wesleyac.com/posts/consider-sqlite

Using SQLite with Litestream helped me to launch the site quickly without having to pay for or configure/manage a db server, especially when I didn't know if the site would make any money and didn't have any personal experience with running production databases. Litestream streams to blackblaze b2 for literally $0 per month which is great. I already had a backblaze account for personal backups and it was easy to just add b2 storage. I've never had to restore from backup so far.

There's a pleasing operational simplicity in this setup — one $14 DigitalOcean droplet serves my entire app (single-threaded still!) and it's been easy to scale vertically by just upgrading the server to the next tier when I started pushing the limits of a droplet (or doing some obvious SQLite config optimizations). DigitalOcean's "premium" intel and amd droplets use NVMe drives which seem to be especially good with SQLite.

One downside of using SQLite is that there's just not as much community knowledge about using and tuning it for web applications. For example, I'm using it with SvelteKit and there's not much written online about deploying multi-threaded SvelteKit apps with SQLite. Also, not many example configs to learn from. By far the biggest performance improvement I found was turning on memory mapping for SQLite.

I made a couple browser extensions that make over $500/month each. The key seems to be naming your extension after high-volume search terms and getting good reviews on the chrome store (and obviously having an extension that works well and solve a common problem on major websites). I monetized them with my own service, https://extensionpay.com. Feels so good to eat your own dog food :)

Neat! I'm serving around 120m requests per month for https://extensionpay.com from a 2GB VPS running a single-threaded nodejs process and SQLite as the db. Most of the requests are cached, but still, it's amazing how far you can get with cheap hardware.

I use SQLite/Litestream for https://extensionpay.com! Serves about 120m requests per month (most of those are cached and don't hit the db), but it's been great!

I have no affiliation with Litestream but I was convinced that SQLite could be a viable db option from this great post about it called Consider SQLite: https://blog.wesleyac.com/posts/consider-sqlite

Using SQLite with Litestream helped me to launch the site quickly without having to pay for or configure/manage a db server, especially when I didn't know if the site would make any money and didn't have any personal experience with running production databases. Litestream streams to blackblaze b2 for literally $0 per month which is great. I already had a backblaze account for personal backups and it was easy to just add b2 storage. I've never had to restore from backup so far.

There's a pleasing operational simplicity in this setup — one $14 DigitalOcean droplet serves my entire app (single-threaded still!) and it's been easy to scale vertically by just upgrading the server to the next tier when I started pushing the limits of a droplet. DigitalOcean's "premium" intel and amd droplets use NVMe drives which seem to be especially good with SQLite.

One downside of using SQLite is that there's just not as much community knowledge about using and tuning it for web applications. For example, I'm using it with SvelteKit and there's not much written online about deploying multi-threaded SvelteKit apps with SQLite. Also, not many example configs to learn from. By far the biggest performance improvement I found was turning on memory mapping for SQLite.

Happy to answer any questions you might have!

I made https://extensionpay.com to monetize my own browser extensions and between that and free distribution on the extension stores it’s really easy to try making extensions that make money. So far devs have made over $300k with ExtensionPay. That said, it still take some skill to find a niche that works.

Just want to put a plug in for https://extensionpay.com/ - I've used it in extensions in the past. It takes away the headache of setting up a backend for payment. They do take an extra 5%, but it's worth it especially. for smaller projects

Have a go at looking at this: https://extensionpay.com,

That's fair. Right now my payment processor (ExtensionPay) doesn't support multiple pricing tiers. However, in the future I'm considering rolling out my own logic so that I can provide a lifetime license option for some users.

Oh nice! Maybe you'd be interested in the tool I built to take payments in extensions: https://extensionpay.com

If your concern is about security of the extension, you may right click on top of the extension's icon and select "Inspect popup". Select the "Network" tab and type CTRL-R to force a reload of the extension. Verify there are no external network requests (except to extensionpay.com for paid features).

I've edited my comment to also include a link to the Chrome docs, but that FAQ entry also has the link to an issue in the webextensions repository indicating it's a limitation of MV3: https://github.com/w3c/webextensions/issues/112

Google outlawing dynamic code in Web Extensions/mv3 is a travesty of high order. There's no place I want to be able to be more alive than my agents. Yet my agents must all be dead. For shame, ye villains.

https://github.com/w3c/webextensions/issues/139

This post definitely was quite a technical explanation. The opening framing, to me, means the world.

The other big change of mv3 that gets no coverage but which is dear to me is that mv3 outlaws any kind of dynamic code. The whole app has to be statically defined. This makes it much easier to know what's running, since an extension can no longer go pull in extra code, but it greatly reduces what you can do as an extension too. Extensions have to have all behaviors predefined. I can't dial home & load my behaviors. Here's the issue, https://github.com/w3c/webextensions/issues/139

For a while it meant that userscripts didn't have any way to run. So Google introduced a new API for user scripting. But those extensions only run in "developer" mode. I'm guessing that means when devtools are open?

I agree a lot with your premise. It sure seems like Google is targeting everyone with these changes, but that better real affordances & escape hatches need to be builtin to not maim the lives of power users. It took a long long time to come up with a userscript solution, and it seems like an awful doesnt-work-for-me workaround (I use userscripts not to dev but to modify everyday experiences). Chrome just hasn't been taking their obligation to user agency seriously.

> the extension APIs are standardised enough that this is actually possible a lot of the time

A bit off topic, but as a co-chair of the WebExtensions Community Group[1] (WECG) I'm a bit touchy about the calling WebExtensions "standardized." A few years back the Browser Extensions Community Group[2] created a spec for WebExtensions, but it never reached a state that we'd normally refer to as a web standard. (Technically W3C community groups can only produce "Reports" and these documents are not on the standards track.[3])

FWIW, I'm very bullish about specifying and (hopefully) standardizing the WebExtensions platform. I'm especially excited about having a good chunk of dedicated time to sit with browser folks at TPAC 2023[4] and try to work out some open questions about where we're going and how we're going to get there.

[1]: https://github.com/w3c/webextensions/

While I was trying to find out what Firefox's limits are I came across this interesting issue on the W3C's webextensions repo: https://github.com/w3c/webextensions/issues/319

4 days ago the Chromium developers proposed upping the limit for certain types of declarativeNetRequest rules based on data AdGuard provided on real world rule lists.

Manifest v3 is used for Chrome's extensions system. The proposal appears to limit what extensions have access to, and what they can do in Chrome. It is proposed as a W3C standard by Google. It is being tracked at the W3C at https://github.com/w3c/webextensions/issues/44.

Google is not even close to finishing MV3: "On the userScripts API, the proposal has been merged into the WECG but the engineering work has not started yet." https://github.com/w3c/webextensions/blob/f8f430f1904c2a6fa8...

MV2 is sticking around until at least 2024.

Some, but not all, limitations are highlighted in this thread: https://github.com/w3c/webextensions/issues/72

Somewhat tangentially, I've been pushing for a popup/overlay API that allows to specify the position and size, and doesn't require any origin permissions.

https://github.com/w3c/webextensions/issues/307