Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Patterns for Integrating 3rd Party Content Into Your CMS

DZone's Guide to

Patterns for Integrating 3rd Party Content Into Your CMS

When you're running a site that uses syndicated material from other sites, knowing how to integrate that content into your CMS is key. Here are the 3 most useful ways.

· Web Dev Zone
Free Resource

Learn how to build modern digital experience apps with Crafter CMS. Download this eBook now. Brought to you in partnership with Crafter Software

There are often times when you will want to integrate content into your site that does not ORIGINATE in your content management system.  In this article, we’ll look at a few high-level patterns for integration and discuss the pros and cons of each approach.

Approach 1: Sync to CMS, Publish to Site as Full Content

Approach 1 focuses on integration at the CMS level only. Content is either pulled or pushed from the 3rd party system into the CMS. From there, it can be further processed and is ultimately published to the website where it can be used like any other type of content including native involvement in search and targeting scenarios.

Pros

  • 3rd party content is converted to 1st class content which allows it to be used natively by the system without rendering engine level integration.
  • Authors may augment the content coming from the 3rd party system to include additional content and metadata.
  • This integration is typically very simple.
  • There is no impact on the performance or complexity profile of your delivery environment.

Cons

  • Syncs can be tricky.  Remember content originates in the 3rd party system but it’s possible that it may need to be further modified by the CMS.  
  • A mechanism and a process must be defined that allows content updates to flow from the 3rd party system into the CMS. Typically, this involves a strong ID that identifies each object, a mapping of fields that can always be overridden in the CMS, and a mechanism for communicating creates, updates, and deletes.

Other Considerations

By passing through the CMS, 3rd party content is not “immediately” available on the website. Content must wait for the sync mechanism to operate. Further, there may be workflow required before the content can be made live.

Reasons to Use This Pattern

  • This pattern is often preferred in the industry.
  • It is relatively simple. 
  • Allows for augmentation of the content in the CMS.
  • Requires no run-time integration.
  • Has no impact on the performance and SLA of the run-time.
  • When Not to Use This Pattern

    When any create, update, or delete to the content in the 3rd party system must be IMMEDIATELY available on the live site.


    Approach 2: Partial Sync to CMS, Full Details Retrieved at Run-Time

    Approach 2 syncs a simple jacket for the content to the CMS but relies on runtime integration with the 3rd party system to get the full details of the 3rd party content. The jacket in the CMS carries only the metadata required for the 3rd party content to participate in the search, targeting, and other dynamic behavior on the site. The “sync” that creates the jacket in the CMS may be done through a simple integration or can even be a manual process.

    Pros

    • Less content is relied on from the CMS which means that for items that have been previously published, detailed data is always 100% in sync with the 3rd party system.
    • Search, targeting, and other dynamic capabilities native to the delivery system may still be relied on for functionality within the site.

    Cons

    • There is a runtime dependency on the third party system for the actual content.  If that site is down, the content is unavailable.
    • As discussed in approach 1, syncs can be tricky. In the case of approach 2, we still have some sort of manual or automated sync with which to create a jacket in the CMS.
    • In this approach, there are two points of integration: one at the CMS and one at delivery. When you add additional moving parts, you are adding operational complexity that must be maintained and supported.
    • Content can be out of sync between what the site has in its jacket (and this in the indexes) and what is in the 3rd party system. You must consider all cases: create, update, and delete.

    Other Considerations

    By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

    When to Use This Pattern

    • When detailed aspects of the 3rd party content must be IMMEDIATELY up to date.
    • When it is impractical to import all of the 3rd party content into the CMS. A typical use case for this approach is a 3rd party hosted video. The CMS may contain only basic metadata and thumbnails while the 3rd party system retains all of the various video encodings.

    When Not to Use This Pattern

    • If the website and the 3rd party system must be 100% in sync on ALL aspects of the content at all times.
    • When approach 1 is viable.


    Approach 3: Run-Time Integration Only

    Approach 3 focuses on integration at the content delivery tier only. Display and behavior related to the 3rd party content are all handled through integration.

    Pros

    • This approach is the most simple from a “moving parts” perspective. There is no syncing involved.
    • 3rd party content is immediately up to date when changes are made in the 3rd party system.

    Cons

    • There is a runtime dependency on the third party system for the actual content. If that site is down, the content is unavailable.
    • All displayed content and behaviors such as query-driven listings, content targeting, and searches must be integrated.
    • It can be difficult to integrate functionality like searches where the CMS content and 3rd party content are placed together on the page in a seamless way. This is because the implementation is very likely to require issuing from at least two queries (one to the CMS and one to the 3rd party system).

    Other Considerations

    By creating a run-time dependency between the delivery system and the 3rd party system you dictate that the 3rd party system must (generally) have the same reliability and performance capabilities of the delivery system.

    When to Use This Pattern

    • When 3rd party content must be IMMEDIATELY available and up to date on the site the instant it is updated in the 3rd party system.
    • When there is no need to rely on native capabilities of your delivery platform for delivery of the content and dynamic behavior (like search.)

    When Not to Use This Pattern

    When option 1 or 2 are viable and use of native capabilities of the content delivery platform is useful/required.

    Crafter is a modern CMS platform for building modern websites and content-rich digital experiences. Download this eBook now. Brought to you in partnership with Crafter Software.

    Topics:
    cms ,web dev ,integration ,content

    Published at DZone with permission of Russ Danner, DZone MVB. See the original article here.

    Opinions expressed by DZone contributors are their own.

    {{ parent.title || parent.header.title}}

    {{ parent.tldr }}

    {{ parent.urlSource.name }}