Create SPA sample template

[hishamco]

It would be nice if we have a SPA template that's a show case for Headless CMS out of the box

/cc @dodyg @sebastienros

[sebastienros]

Could be a recipe, it could also be a guide. You could argue we could have a guide for the existing recipes too (Blog, Agency).

I think starting with a guide would be nice in this case, as this is more about showing how to do it that having a site ready that uses this technique.

/cc @jrestall who does it with react

[hishamco]

Perhaps a Blazing Pizza is a good example

[hishamco]

Could be a recipe, it could also be a guide

It could be, but I'd like to see a SPA on action with no razor no fluid, just HTML with little jQuery to consume the back-end APIs

[Skrypt]

You mean like what ABP does?

[hishamco]

ABP is a WAF, but what I'm asking for is just a show case, something similar to https://github.com/cofoundry-cms/Cofoundry.Samples.SPASite

I'm a web dev who knows HTML+JavaScript only and I'd like to use Orchard Core as source of data

[Skrypt]

Yeah but ABP uses themes and templates for each type of SPA frameworks like one for Angular, Vue.js, React ... With complete premium templates. Now, this Cofoundry sample looks more like a frontend dashboard.

[jrestall]

Having a 'Headless CMS' setup recipe would be great.

• Enable GraphQL module and permissions/authentication to execute graphql.
• Disable the frontend themes.
• Add a Home Route to point directly to /admin.
• Setup some default modules commonly used by headless sites. Metadata, Assets, Layers etc.
• Page content type.
• ...

I'm slowly working on gatsbyjs plugins for Orchard Core with a sample site. https://github.com/jrestall/gatsby-orchardcore/tree/master/example/site.

[hishamco]

Seems @sebastienros demo gatsbyjs year ago if I'm not wrong in ASP.NET Community Standup

[hishamco]

this Cofoundry sample looks more like a frontend dashboard.

No, it's SPA, all images except the first one shows how to manage the content, like what we did in the admin theme

[Skrypt]

I don't disagree that it's a SPA, though if you can manage content with it then it has content management which could be apparented to a frontend dashboard if you don't consider it as the OC admin. In OC this would need to be 2 separated SPA if you would want to use the content management as a replacement for the current admin. Unless you don't want to use the current admin at all ! 😄

[sebastienros]

Should we have two recipes:

• One Empty SPA Site Like "Blank" but with graphql, and no content types
• One "Pizza SPA" that would be the same as SPA but with sample contents

Also "some" spa template projects (other repository) to reuse the Pizza SPA. Can also be Blog if that's more common. We could also have a sample repos that would generate a static site from it.

What about authentication to make the graphql endpoint secure.

[hishamco]

I think the second option is good

We could also have a sample repos that would generate a static site from it.

This is handy for some scenarios like APIs docs, blog posts.. etc

[hishamco]

Can we do a Pizza SPA that using GraphQL?

[sebastienros]

We should write a guide that shows how to do spa applications with graphql. And maybe ship the result in the OrchardCore.Samples repository.

[dodyg]

We need to do three guides:

• Build traditional CMS from scratch.
• Build using decoupled CMS.
• Build using Headless CMS.

I can do the first two because I have a long real world implementation notes go guide me. I have zero experience with GraphQL.

[sebastienros]

We already published the decoupled: https://orchardcore.readthedocs.io/en/dev/docs/guides/decoupled-cms/decoupled-cms/

Please share the feedback.

If you want to work on the first one then I am ok with that. If you can follow the same format as the video I gave last year, reimplementing the Blog Theme. Creating the types, then a theme, then a recipe, that would be awesome.

For the headless, I could create a custom recipe, then show how to setup openid connect, and generate a static site from it. Maybe a small spa application too to connect to the same graphql endpoint.

[sebastienros]

I have made some good progress on the "traditional CMS from scratch" one. Building the site with types and parts is done, now starting theming. I am rebuilding TheBlogTheme somehow.

Difference with decoupled is that I introduced Autoroute +liquid pattern, and List

[dodyg]

I reviewed https://orchardcore.readthedocs.io/en/dev/docs/guides/decoupled-cms/decoupled-cms/ and it looks good but I think we can make the tutorial process more efficient in terms of the structure.

The tutorials can be broken down to three parts:

1. Code setup for Traditional / Decoupled / GraphQL
2. Content Modelling
3. The rest of Traditional / Decoupled / GraphQL topics

I think if we create a dedicated topics for Content Modelling, we can benefit the beginner and the intermediate users alike and it will cut down the size of the tutorial.

So in Content Modelling we can have:

• How to:
  • Model a Blog
  • Model a Blog with Categories
  • Model a Blog with Localization
  • Model an Event, etc
• Parts and Fields and how they are used in Content Modelling
  • Use Text Field with Select List for enumeration type of Content
  • When to use Flow
• Queries How to index and query contents for different purposes
  • Sort and List based on Dates or Status, etc

Then in the tutorials we can just do

1. Code Setup
2. Point the reader to complete Cookbook "Model a Blog"
3. The rest of relevant topics

Since the Code Setup is the same, we can even simply have a page with Code Setup for Traditional / Decoupled / GraphQL so the tutorial creation process will be

1. Point to Code Setup section.
2. Point the reader to complete How To "Model a Blog".
3. The rest of relevant topics.

[johnrom]

Just a few notes here:

SPA is a multi-headed beast. There are three main types of SPA:

1: Client-rendered

This is when the browser gets a blank page with a bunch of scripts, runs queries and builds the initial render from scratch. This usually starts with a loading screen almost like a splash page in a native application.

This is fine for internal applications without major SEO requirements. The documentation for Decoupled is probably good enough to cover most of this topic.

Orchard roles:

• Traditional CMS with SPA view that only contains the elements required to build initial render.
• Decoupled

2: SSG

Server-side generated. This means a cli tool like NextJS or Gatsby will fetch data, run transforms on the source files and the data to generate static html and deploy it to a static site.

Orchard roles:

• Decoupled with only API
• Traditional serving static files that are deployed to the Orchard Core Server after build.

2.5: ISR

A subtype of SSG, Incremental Server-side Rendering. This means a cli tool like NextJS or Gatsby will perform the SSG process either at intervals or on-demand -- sort of like pre-caching SSR.

Possible Orchard roles:

• Decoupled: Updates to Orchard Content can Trigger an incremental update and deployment in CLI tool. (See Nmbl.Deployments for a somewhat out-of-date example of how to deploy incrementally using Orchard Core + Vercel)
• Traditional: Can also be target of deployed static files.

3: SSR

The server renders an entire page with dynamic data. This is the hardest to achieve, but very useful for SEO-heavy public-facing sites with dynamic content. This can be done with SSG to an extent, but sometimes one might not want to write sensitive data to the filesystem or there can be way too many possible variations of pages that generating them all wouldn't make sense.

There are generally two ways to accomplish this:

1. Browser sends requests to a Node Server, which then requests from Orchard on the backend, builds the initial render, then sends it to the browser. The node server can either cache or not cache the value, but without caching the node server has the potential to make a lot of API calls, which can be noisy and problematic from a network perspective.
2. Browser rends a request to a server like Orchard Core, which then sends a POST request with pre-populated data to a Node Server to render without needing to make requests back to the API. The result is then rendered in cshtml. This is harder to maintain (the server needs to know the data that the client needs in advance), but reduces network overhead perspective.

• this is how Microsoft.AspNetCore.SpaServices used to work, generally

Orchard Roles:

• Decoupled: number 1 above.
• Traditional: number 2 above.

---

I have experience implementing Incremental, SSG and SSR in Orchard Core, so I might be able to share some info on that in the coming weeks.

[Skrypt]

I thought that the GraphQL endpoint had issues with Gatsby.

[Piedone]

How about #15213 and #15647?

[hishamco]

I think we already have a SPA recipe, right?

I need to recheck