ExtPay VS Alpine.js

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).

Alpine.js for reactive frontend

✨ In recent months, I have been developing web projects using GOTTHA stack: Go + Templ + Tailwind CSS + htmx + Alpine.js. As soon as I'm ready to talk about all the subtleties and pitfalls, I'll post it on my social networks.

> But honestly, torn towards htmx but undecided.

We are in the middle of migrating from our monster react application into server rendered pages (with jinja2). The velocity at which we are able to ship and the reduction of complexity has been great so far.

Managing client side state for simple things like (is the dropdown open/closed), listening to keyboard events and such can be done with something like alpine-js [1] without all the baggage that something like react brings.

It appears this is already the trend with JS frameworks too - with server side rendering being the new norm.

[1] https://alpinejs.dev/

Sure, you can use any number of JS-avoidance libraries. I'm a fan of Turbo, and there's also htmx, Unpoly, Alpine, hyperscript, swup, barba.js, and probably others.

Direct DOM, but with a library. Specifically AlpineJS since it follows Vue closely in design practices allowing me to scale into a full web application if necessary (basically swapping to Vue takes minimal work). The Morph plugin is specifically what I like using.

If you want more details on the initial setup I encourage you to take a look at the Part I that covers more of the initial implementation. For this portion, I added Prisma as an ORM, a frontend style library called Tachyons, and AlpineJS to handle any client-side interactions. I did this to avoid needing to add a client-side bundler to the build and instead just rely on plain old module imports to compose the frontend. This is now the default for Rails and it is quite nice to not need any additional build tools for the client.

- [swallow-pywebview](https://github.com/rangwea/swallow-pywebview)： Base on [pywebview](https://pywebview.flowrl.com/) using Python，the frontend base on [alpinejs](https://alpinejs.dev/) and [tailwindcss](https://tailwindcss.com/)。

If you’ve followed our other tutorials, you might be familiar with Alpine.js. It’s a lightweight JavaScript library that allows you to add interactivity to your site without writing a single line of JavaScript. It’s incredibly easy to use, and we’ll show you how to make the animation trigger when the user scrolls to it.

The approach is not new, essentially a variation of Knockout, Alpine, and similar "JS-in-HTML" approaches.