Thanks for the mention @chrislarry! Can't believe I miss this post. Turns out many wants to figure out WM on Jamstack sites too!
First of all - Welcome to the community Eric! 👋 Just noticed you joined very recently!
I love your take on how computing at once at build time and only rely on redirect to serve paid content since that kind of efficiency is really my thing - which is something that I really dig in my project ProgNovel. I also was exploring premium content on static data previously, but since receipt verification server was too slow for production I settled only with hiding premium content with JavaScript. I will try exploring deeper on this later after new WM spec rolls out once the API becoming more stable.
As for my findings when exploring premium content in Jamstack environment, I'll try recall them:
Like Alex Lakatos said, currently, you can only know which paid users client-side, once the real money starts streaming. So more traditional redirects between paid and free contents in form of JSON or any returned data from backend/serverless might be more useful than picking a redirect between two different version of web pages in Netlify/Vercel edge handlers. Better yet: pick between two different static JSON in client-side and fetch them directly from CDN without having to set up any backend would do the trick just fine.
Another alternative from redirecting is just render it once but encrypt some of the content for free users, then send the key to unlock it once we already confirm the user is a WM subscriber. Or render contents in a page separately and only ships the rest once the payment is verified. This method is useful since we don't need to wait for verifying payment to start showing some of the content. (Maybe create unlock banner for subscibers to like how Medium does while we're at it)
Speaking of waiting for payment to verify, as I mention this before, the place I think needs more attention to is the the receipt verification server. I tried using the public receipt server but it was too slow for production back when I tried it. Hosting the receipt verification server myself might yield better result but I doubt it will fast enough to make users have to patiently wait for it. Focusing on how to strategize UI/UX around the gap created when receipt is being verified might be better for overall perceived performance.
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the mention @chrislarry! Can't believe I miss this post. Turns out many wants to figure out WM on Jamstack sites too!
First of all - Welcome to the community Eric! 👋 Just noticed you joined very recently!
I love your take on how computing at once at build time and only rely on redirect to serve paid content since that kind of efficiency is really my thing - which is something that I really dig in my project ProgNovel. I also was exploring premium content on static data previously, but since receipt verification server was too slow for production I settled only with hiding premium content with JavaScript. I will try exploring deeper on this later after new WM spec rolls out once the API becoming more stable.
As for my findings when exploring premium content in Jamstack environment, I'll try recall them: