I am new to Web Monetization, but a seasoned full-stack developer. I've started by digging the documentation thoroughly.
Bear with me, this posts is long but if you are into web development you wont be disappointed.
As you may already know, the example implementation considers some exclusive content, that would be revealed only to paid users using Web Monetization API.
A more advanced implementation relies on a system of receipt. I am still trying to grasp it but I get a rough idea of the architecture.
It turns out that I've studied extensively the use case of exclusive content, from the web developer perspective.
This is because you need to figure out if the user is paid everytime you display the page.
Client-side you can use the Web Monetization API, server-side you need to process each request to check for payment.
I've designed a pattern named "Segmented Rendering", which rely on static rendering instead.
You render at build time a paid version and a free version of your page, once for all
You select which version to display using a tiny redirection server. Hosts like Vercel and Netlify have edge runtimes that are a perfect fit for this.
This article describes an implementation with Next.js: https://blog.vulcanjs.org/render-anything-statically-with-next-js-and-the-megaparam-4039e66ffde
This article from Plasmic also describe a similar approach for A/B testing: https://www.plasmic.app/blog/nextjs-ab-testing
I've got an article waiting for publication that precisely targets the use case of exclusive content within a web page.
The main takeaway is that this architecture is more performant and most probably more energy efficient than traditional client-side rendering SSR.
I say most probably because I am an honest person: we lack empirical study to definitely prove this, a lot of factors are involved in real life. But the mathematics says it does less computations.
With CSR/SSR, the same exclusive content delivered to 1 billion people means 1 billion expensive computations.
With Segmented Rendering, for 1 billion people, you have only 1 expensive computation, done in advance at build-time.
You still need a redirection for each request.
Now, I have a few question:
- Can Web Monetization be used during server-side rendering?
As far as I understand, the HTTP request might contain information that I can in turn use server-side to confirm that the user is a paid user, and then serve the content? It's not the easiest part of the architecture so if anyone has open source code samples of this even in other programming language it would help a lot.
- If yes, can Web Monetization be used using only HTTP requests server-side?
- Where's the crypto???
This architecture only makes sense if Web Monetization isn't itself consuming tons of energy, to the point that my rendering issue would be insignificant.
When reading Web Monetization documentation, my brain screams "at which step are they going to sell me some crypto crap"?? It's a caricature but you get the point: is the ecological impact of Web Monetization as it is currently implemented already known or measured, at least in terms of energy consumption? are there expensive computations involved or does it require its own nuclear plant to properly work? is it better or worse than current architectures (advertisment based business models for instance)? etc.
Thanks in advance for your answers, references and feedbacks, so far I've been enthusiastic about what I've discovered when reading Web Monetization. I hope to be able to produce a cool Next.js implementation if everything goes as I expect.