Squidex
  • Welcome to Squidex
  • Getting Started
    • Squidex Cloud
    • Installation Instructions
      • Platforms
        • Install on Kubernetes
        • Install on AWS (Deprecated)
        • Install on AWS EC2 using Docker
        • Install on Azure
        • Install on Azure using ARM
        • Install on Google Cloud Platform (GCP)
        • Install on Docker
        • Install on Heroku
        • Install on IIS
        • Install on Render
        • Install on Vultr
      • Configuration
        • Deploying the Image Resizer Service
      • Troubleshooting and Support
        • Diagnose Runtime Issues
        • Restoring Deleted Apps
      • Install Identity (Deprecated)
      • External Identity Providers
        • Azure AD (OAuth) with Squidex
    • Contributing and Developing
      • Building
      • Developing
      • Extensions
        • Custom Rule Action
      • Contributing
      • Architecture
      • Translating
      • Squidex Docs Program
    • Roadmap
    • Quick Start Guides
      • Vue.js Blog with Squidex
      • React.js Blog with Squidex
      • Angular Blog with Squidex
  • Documentation
    • Introduction and Use Case
    • Concepts
      • Apps
      • Teams
      • Schemas
        • Field Rules
      • Content
        • Scheduled Publishing
      • Assets
        • Querying Assets
      • Localization
      • Migrations
      • Roles & Permissions
      • Rules
        • Publish an Event to Azure Queues using Rules
        • Populate Elasticsearch Index
      • Backups
      • Subscriptions
        • App Subscriptions v/s Team Subscriptions
      • Notifications
      • Dashboard
      • Workflows
    • Software Development Kits
      • TypeScript
      • .NET
        • Version v14 (and Earlier)
        • Version v15 (and Later)
      • PHP
      • Java
    • Developer Guides
      • API
        • Authentication
        • Postman
        • Queries
        • Assets
      • Automation Tools (CLI)
      • Scripting
        • Scripting Helper Methods
      • Embed Content
      • Custom Workflows
      • Custom Editors
      • Custom Sidebars
      • Preview Content
      • Rule Formatting
        • Simple
        • Script
        • Liquid
      • Tutorials
        • Building a Blog with Squidex and Next.js
  • Next
    • Squidex 3.0: API Compatibility
Powered by GitBook
On this page
  • The Company
  • The Content Structure
  • Editorial Content
  • Startup Database
  • JSON Structure
  • People and Roles

Was this helpful?

  1. Documentation

Introduction and Use Case

A Brief Introduction to Squidex and a Use Case

PreviousAngular Blog with SquidexNextConcepts

Last updated 2 years ago

Was this helpful?

It's best to describe features and functionality with a use case. So, to make following our documentation easier and briefer, will use a single use case (which will be updated and extended over time). This page describes the details of this particular use case.

Our documentation is still in progress and only a few pages have been created/updated so far. As new information is published, we will update this page. Do check back for our updates.

We recommend opening this use case alongside the documentation, so you don't need to keep switching back and forth!

The Company

The user is the Lead Developer and CTO of a mid-size news magazine called "FoodCrunch", a magazine for everything surrounding food startups. It has just over 100 employees speaking 14 different languages. The editors and content authors write articles, news and other types of editorial content. In addition to that, the magazine also maintains a database called "FoodBase" with information about all startups in the food industry and information on topics such as co-founders, investment rounds and more.

Therefore, for this use case, the team has created one project in Squidex for all content, assets and settings and invited all developers and content editors to the project to work together. In Squidex we call this an "App".

The Content Structure

The structure of the content is defined by schemas in Squidex. In this section, we describe the different content types for our use case. Read more about schemas here:

Editorial Content

The CTO has decided to have a single structure for all editorial content. After bringing everybody to the table, the developers and editors have confirmed what information they need for each type of content. Even though the FoodCrunch website is available in four different languages, the team writes editorial content in one language.

This schema is called magazine and has the following fields.

Name
Type
Localizable
Description

slug

String

No

A single slug for Google friendly URLs.

title

String

No

The title of the editorial content.

content

String

No

The actual content.

content-type

String

No

The type of the content, e.g. "Article" or "News".

startup

Reference

No

A reference to the startup in the database.

image

Assets

No

One or more teaser images.

Startup Database

The startup database is maintained in multiple languages, so that entries can be reference in the languages from all articles, independent from the language they are written in.

This schema is called startups and has the following fields.

Name
Type
Localizable
Description

slug

String

No

A single slug for Google friendly URLs.

name

String

No

The name of the startup.

description

String

Yes

The description of the startup.

funding

Number

No

The total funding in millions (USD).

founded

String

No

The year the startup has been founded.

founders

Array

No

The founders as list of name and position.

tags

Tags

No

A list of tags for search.

location

Geolocation

No

The geolocation of the headquarter.

metadata

JSON

No

Unstructured metadata.

givenUp

Boolean

No

Indicates whether the startup has given up.

JSON Structure

If you are a content editor, you can skip this section.

We use JSON to represent content in the database and API. Each content item is one document and the values of all fields are just called "content data" or "data". As Squidex supports localized fields, we need a way to structure these localized fields as well as the non-localized fields. In Squidex we have decided to use a common structure for this purpose. Therefore, our content takes the following shape:

// magazine
{
    // Additional metadata, such as content id.
    "data": {
        "slug": {
            "iv": "sustainable-eating-by-foodco"
        },
        "title": {
            "iv": "Sustainable eating by FoodCo"
        },
        "content": {
            "iv": "Introducing FoodCo, the latest player in the food industry. FoodCo aims to revolutionize the way we eat. Their innovative products and focus on sustainability have already garnered attention from foodies and investors alike. Stay tuned for what's cooking next!"
        },
        "content-type": {
            "iv": "Article"
        },
        "startup": {
            "iv": [
                "3a20690a-c40b-44bc-832e-0a6e3e708d93"
            ]
        },
        "image": {
            "iv": [
                "287a2948-8992-4e65-990f-3ee486c9a4b5"
            ]
        }
    }
}

// startups
{
    // Additional metadata, such as content id.
    "data": {
        "slug": {
            "iv": "foodco"
        },
        "name": {
            "iv": "FoodCo"
        },
        "description": {
            "en": "Sustainable eating products",
            "de": null
        },
        "stage": {
            "iv": "Early"
        },
        "founded": {
            "iv": 2019
        },
        "funding": {
            "iv": 234
        },
        "founders": {
            "iv": [
                {
                    "name": "John Doe",
                    "position": "CEO"
                }
            ]
        },
        "tags": {
            "iv": [
                "sustainability"
            ]
        },
        "location": {
            "iv": {
                "latitude": 32.0237703,
                "longitude": -92.0390231
            }
        },
        "metadata": {
            "iv": null
        },
        "givenUp": {
            "iv": false
        }
    }
}

As you can see, we need a JSON object for our localized fields. To use a generalized structure, all objects have an iv (which stands for invariant) key, used for localized fields. Read more about the reasoning in the section concerning localization:

People and Roles

The following people work together with Squidex to bring content to a website.

  • Developers work together to bring new features to a website. Their responsibilities are to define the schemas in Squidex and to implement the business roles with Workflows and Permissions. To make it easier for them to find and fix bugs on the website, they also have full control of the content itself.

  • Editors are responsible for writing the articles in different languages and conducting research for preparation of articles. As false information is a big deal in the news industry, Editors are not allowed to publish the content itself.

  • Reviewers check the content before it gets published for spelling, grammar and the accuracy of facts, as well as reviewing other information in the content.

  • Publishers work together with marketing and social media to decide when content should go live. They can also publish reviewed content but don't create any content themselves.

Apps
Schemas
Localization