Innovation...GraphQL generally improves performance over REST by reducing the number of calls but be...

Post on 23-May-2020

4 views 0 download

Transcript of Innovation...GraphQL generally improves performance over REST by reducing the number of calls but be...

1

Innovation

Content

Operations

User Experience

Building Single Page Apps with React

Headless CMS, and GraphQL

Russ Danner, VP of Products Crafter Software February 2020

1997- 2001: Industrial Process Control, Specialty steel alloys 2001 - 2008: Development, Architecture, Management in the publishing industry 2008 - 2013: WCM Practice Director, Consulting firm 2013 - Present: Vice President of Products, CMS Company (Crafter Software)

Russ Danner Vice President, Products Crafter Software

Content

Modern Web Applications

Relies on API calls for data Fine. But don’t trivialize the server

01

Relies on API calls for data Fine. But don’t trivialize the server

01

For public facing websites, SEO remains a _MAJOR_ concern

01

Relies on API calls for data Fine. But don’t trivialize the server

01

For public facing websites, SEO remains a _MAJOR_ concern

01

The number of framework variants and options along with the high rate of innovation and change is great! And also TERRIBLE!

GraphQL

GraphQL is ...

A Query Language An Alternative to REST

An API Gateway All of the above

Content

Standard data access “query language” 01

Standard data access “query language” 01

Discoverability enables tooling 01

Standard data access “query language” 01

Discoverability enables tooling 01

No Need to Version APIs

Standard data access “query language” 01

Discoverability enables tooling 01

No Need to Version APIs

Quickly build and roll out an integrated API gateway

Standard data access “query language” 01

Discoverability enables tooling 01

No Need to Version APIs

Quickly build and roll out an integrated API gateway

The rules bring predictability

No inherent security 01

No inherent security 01

The rules bring limitation 01

No inherent security 01

The rules bring limitation 01

GraphQL is NOT always the right API semantics for the job

No inherent security 01

The rules bring limitation 01

GraphQL is NOT always the right API semantics for the job

You have to be aware of the performance overhead introduced by GraphQL

CMS Content Management Systems

Do You Love Your CMS? Show of Hands

Almost Everyone Shares a Common Opinion

Legacy CMS CMS

● Page dominant

● Database centric architecture

● Language, framework specific

● Traditional deployment models

The architecture is the problem

Headless CMS Architecture

Is Headless CMS the Ultimate Cure?

Headless CMS Architecture

Better Support For Multi-Channel: Check

Headless CMS Architecture

Let’s Developers Modern Tech: Check

Headless CMS Architecture

Much Greater Dev Speed & Flexibility: Check

Headless CMS

Architecturally Speaking ...

Headless CMS Architecture

Backend Architecture & Scale issues: Unknown

Headless CMS Architecture

Content is Still Siloed per Environment: Fail

Headless CMS Architecture

DevOps Integration Doesn’t Exist: Fail

Is Headless ALWAYS the RIGHT answer?

Do You Really Need React to Build a Marketing Landing Page?

Most Headless CMS Platforms Lack Visual Authoring Tools

Typical Headless Content Authoring Experience

Headless CMS: Where’s the Beef?

Typical Headless CMS To the Rescue?

● Poor authoring support

○ In-context preview and editing

○ Drag and drop

● No marketing tool support

● Only partially addresses CI/CD Concerns

Headless CMS sacrifices content authoring in favor of

ease of development. Innovation improves, but not

enough and at too high a cost.

SPAs are amazing but the don’t eliminate the server and they have SEO problems

01

SPAs are amazing but the don’t eliminate the server and they have SEO problems

01

GraphQL is awesome but it has limitations and I need to know my GraphQL backend implementation

01

SPAs are amazing but the don’t eliminate the server and they have SEO problems

01

GraphQL is awesome but it has limitations and I need to know my GraphQL backend implementation

01

Headless CMS makes CMS better for developers but I still have scalability and devops issues and now my authors are going to hate the CMS?

Anyone Know of Solutions for These? Show of Hands

SPAs

Only works for sites with a predefined structure. Not great for true drag-n-drop builds with nesting.

01

Only works for sites with a predefined structure. Not great for true drag-n-drop builds with nesting.

01

Only works for relatively small sites. Even if you work around the full site build issue for page edits, a common component edit will force a full render.

01

Only works for sites with a predefined structure. Not great for true drag-n-drop builds with nesting.

01

Only works for relatively small sites. Even if you work around the full site build issue for page edits, a common component edit will force a full render.

01

It’s no good for personalization and other dynamic features

Only works for sites with a predefined structure. Not great for true drag-n-drop builds with nesting.

01

Only works for relatively small sites. Even if you work around the full site build issue for page edits, a common component edit will force a full render.

01

It’s no good for personalization and other dynamic features

Search. Once you start introducing server — you have server.

Server Side Render is Awesome. - It scales for larger sites - Provides SEO benefits - Supports search and other powerful interactions - Supports personalization

But it requires a server. Sorry. :)

01

Headless CMS

Headless+ addresses development and authoring issues but not all headless+ CMS platforms are created equal. Challenges with DevOps, DevContentOps and the CI/CD automation still exist.

01

A “Perfect” Fit

Where SEO is not a concern. GO FOR IT. 01

Where SEO is not a concern. GO FOR IT. 01

Manage the builds scripts as content 01

Where SEO is not a concern. GO FOR IT. 01

Where SEO is a concern. Accept the server 01

Manage the builds scripts as content 01

Where SEO is not a concern. GO FOR IT. 01

Where SEO is a concern. Accept the server

01

SPAs are a lot of effort to create. Are you getting the leverage? Make sure your getting the leverage — If not, use simple markup.

Manage the builds scripts as content 01

Where SEO is not a concern. GO FOR IT. 01

Where SEO is a concern. Accept the server

01

SPAs are a lot of effort to create. Are you getting the leverage? Make sure your getting the leverage — If not, use simple markup.

Manage the builds scripts as content 01

If authors want a high degree of control to assemble the application with drag and drop plan extra time to think this through end to end

Beware the deletes and renames in the schema 01

Think through security and personalization. Do you need it? Where is it applied?

01

Beware the deletes and renames in the schema 01

Think through security and personalization. Do you need it? Where is it applied?

01

Don’t force it. If you have a data retrieval or mutation that doesn’t fit… USE REST. You’re still a cool kid.

01

Beware the deletes and renames in the schema 01

Think through security and personalization. Do you need it? Where is it applied?

01

Don’t force it. If you have a data retrieval or mutation that doesn’t fit… USE REST. You’re still a cool kid.

01

Realize that without transformations some amount of the backing store’s structure abstractions will leak through in the query response.

Beware the deletes and renames in the schema 01

Think through security and personalization. Do you need it? Where is it applied?

01

Don’t force it. If you have a data retrieval or mutation that doesn’t fit… USE REST. You’re still a cool kid.

01

Realize that without transformations some amount of the backing store’s structure abstractions will leak through in the query response.

GraphQL generally improves performance over REST by reducing the number of calls but be aware of the cost of your GraphQL calls.

Beware the deletes and renames in the schema 01

Think through security and personalization. Do you need it? Where is it applied?

01

Don’t force it. If you have a data retrieval or mutation that doesn’t fit… USE REST. You’re still a cool kid.

01

Realize that without transformations some amount of the backing store’s structure abstractions will leak through in the query response.

GraphQL generally improves performance over REST by reducing the number of calls but be aware of the cost of your GraphQL calls.

Remember not all GraphQL enabled systems are equal. Some are offer more control, better performance and better plugability than others.

Beware the deletes and renames in the schema 01

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Gatsby is a great option for simple, small, developer centric sites that don’t mind a CI/CD process as part of workflow

01

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Gatsby is a great option for simple, small, developer centric sites that don’t mind a CI/CD process as part of workflow

01

Once authors are in play on a day to day basis you need a headless+ authoring experience

01

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Gatsby is a great option for simple, small, developer centric sites that don’t mind a CI/CD process as part of workflow

01

Once authors are in play on a day to day basis you need a headless+ authoring experience

01

You need to think about DevContentOps. How will production content flow back from production to lower environments? How will code flow forward from lower environments up to production

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Gatsby is a great option for simple, small, developer centric sites that don’t mind a CI/CD process as part of workflow

01

Once authors are in play on a day to day basis you need a headless+ authoring experience

01

You need to think about DevContentOps. How will production content flow back from production to lower environments? How will code flow forward from lower environments up to production

Your Source Code management and version history is modern an integrated with your CI/CD. Is your content repository?

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Gatsby is a great option for simple, small, developer centric sites that don’t mind a CI/CD process as part of workflow

01

Once authors are in play on a day to day basis you need a headless+ authoring experience

01

You need to think about DevContentOps. How will production content flow back from production to lower environments? How will code flow forward from lower environments up to production

Your Source Code management and version history is modern an integrated with your CI/CD. Is your content repository?

Look for a CMS that can scale in a serverless and stateless fashion but that can still do dynamic content.

Headless Only CMS is great for simple use cases like fixed content in a mobile application. “Strings in a app”

01

Git-based repository for full DevContentOps support

Git-based repository for full DevContentOps support

Native high-performance GraphQL and REST Support

Git-based repository for full DevContentOps support

Native high-performance GraphQL and REST Support

Headless+ Incontext authoring support

Git-based repository for full DevContentOps support

Native high-performance GraphQL and REST Support

Headless+ Incontext authoring support

Serverless & Statemess Content Delivery

Questions

craftersoftware.com | craftercms.org

Slides Cut Due to Time

128

Customer Experience Leaders are Winning

Who is Using React Show of Hands

Based on 20 Year-old Architecture Common Challenges for Marketing

Legacy CMS Solutions

Content freezes

due to DevOps

Legacy CMS Solutions

Design restrictions

Development is

difficult, slow,

expensive

Content freezes

due to DevOps

Based on 20 Year-old Architecture Common Challenges for Marketing

Legacy CMS Solutions

Design restrictions

Development is

difficult, slow,

expensive

Content freezes

due to DevOps

Global authoring is

a problem.

Versioning is weak

Auditing is weak

Based on 20 Year-old Architecture Common Challenges for Marketing

Legacy CMS Solutions

Design restrictions

Development is

difficult, slow,

expensive

Content freezes

due to DevOps

Global authoring is

a problem.

Versioning is weak

Auditing is weak

Based on 20 Year-old Architecture Common Challenges for Marketing

Redesigns are

difficult because

we have to migrate

or double publish

Legacy CMS Solutions

Not designed for

multi-channel

Based on 20 Year-old Architecture Common Challenges for DevOps

Legacy CMS Solutions

Restrictive

development

frameworks

Not Designed for

multi-channel

Based on 20 Year-old Architecture Common Challenges for DevOps

Legacy CMS Solutions

Restrictive

development

frameworks

Not designed for

multi-channel

Don’t fit in to

modern

development

process

Based on 20 Year-old Architecture Common Challenges for DevOps

Legacy CMS Solutions

Are difficult to

scale, distribute

and operate

Based on 20 Year-old Architecture Common Challenges for DevOps

Restrictive

development

frameworks

Not designed for

multi-channel

Don’t fit in to

modern

development

process

Where SEO is not a concern. GO FOR IT. 01

Where SEO is a concern. Accept the server

01

SPAs are a lot of effort to create. Are you getting the leverage? Make sure your getting the leverage — If not, use simple markup.

Manage the builds scripts as content 01

If authors want a high degree of control to assemble the application with drag and drop plan extra time to think this through end to end

Your routing, data retrieval and state management for websites is non-trivial. Take time to think it through

Dynamic Routing

Late Binding Templates and Components