I really want to add this to our stack but it’s quite married to specific frameworks (next.js / react). I’m trying to fit this into astro.build.
Hey @safe_sturgeon, did you get a chance to integrate it with the suggestions here? https://plasmiccommunity.slack.com/archives/C0128PVPESU/p1666279760385079?thread_ts=1666233985.013129&cid=C0128PVPESU
That works, but fetchPages doesn’t seem like a performant way of loading HTML via slug / pathname
Anyway, I’m noticing a potential privacy issue. You’re collecting metrics and page view events and storing them into your own analytics server (posthog). Seems a bit odd & strange.
With that said, we were planning to cache pages and noticed your pricing is based off page views. So using your service but caching & not hitting your servers at all still triggers page views?
Hi @safe_sturgeon, some quick answers:
fetchPages is cached on the AWS Cloudfront CDN, but yes, caching data locally will always yield the highest performance, including for Plasmic data.
We collect analytics and errors, both within Plasmic Studio as well as in generated pages, as it lets us learn and improve the platform, and it also relates to features like AB testing. We are also about to expose your analytics to you in a new built-in analytics portal. Besides analytics, another runtime dependency is image optimization. The analytics are not cookied by default.
We tier pricing on page views in order to support Plasmic as a business. But if your team has specific needs, I can help you via DM, or you can ping sales@plasmic.app. Or if you have feedback on the pricing scheme, I can also relay that to our product marketing team.