Why use the json file?

[rallisf1]

I understand it only loads once and you can cache it or whatever but still that can get pretty large and slow.

I'd rather have an API endpoint on primo-server (just primo now), that can give me:

• All available page ids, titles, slugs and hierarchy per language, so I can build a menu
• Sitewide html/css and fields
• Per page html/css/fields/components

You current example addresses the need of adding a small blog or landing page to a larger sveltekit project. My need is templating a sveltekit project, thus the actual content will be loaded from elsewhere and I only need the Primo components to use as wrappers. Currently I use Primo as a draft tool and copy over the components manually to my sveltekit projects.

[mateomorris]

Yeah this is mostly just to get the ball rolling in that direction and show how you could use Primo headless with the current functionality if you wanted to.

What you're describing would be more ideal though - querying the server directly. I'd imagine you could fetch an endpoint like '/about.json' and get just that page, possibly pass in query params to specify what page data to get. Another option is to publish smaller json files instead of one big primo.json and consume them from GitHub the same way.

But I'm not sure what you mean by "using the Primo components as wrappers" - do you mean querying the actual component code & rendering it from SvelteKit instead of querying the data? ie using Primo just as an IDE/component library?

[rallisf1]

do you mean querying the actual component code & rendering it from SvelteKit instead of querying the data? ie using Primo just as an IDE/component library?

Yes! Ultimately I want to use Primo for building all the static staff (front-page, contact page etc) and just as a template for dynamic pages likes categories, products, posts etc

Thus I can pre-render all the static stuff and load the other pages' content from wherever: another db, shopify API etc.

OFC if and when primo starts supporting cloud workers that would be obsolete.

[mateomorris]

I'd imagine you could do that more from Primo without involving SvelteKit (so long as you don't need SSR) by using query params for the dynamic pages. How would the cloud workers play in?

[rallisf1]

I'd imagine you could do that more from Primo without involving SvelteKit (so long as you don't need SSR) by using query params for the dynamic pages. How would the cloud workers play in?

2 reasons: 1) query params are not appropriate for SEO, so you need some kind of dynamic routing, 2) I wanna fetch data from 3rd party APIs without exposing my API keys

[mateomorris]

For 1) Do you mean because the content isn't static HTML? Because as far as I can tell, the google bot can see content that gets loaded by JS right after page load. 2) Gotcha yeah would be a great use of cloud functions. They could either return the dynamic content after page load or SSR the whole page.