AEM Jamstack with Content Fragments

[jithinkumar]

Currently we are experimenting a Jamstack approach for developing our websites with utilising headless possibliities of AEM.

To achieve good scalability, we prefer developing user interfaces "outisde" AEM and will use AEM as a content store so that we can use Access, Permissions and workflows within AEM.
So In our value chain AEM is our datasource (content store), We will have site structure with pages and every page will be backed by a content fragment.

Every page will have a json blob that represents content for that page. For Eg; 

{
"page" : {
  "header" : {
    "title" : "Page Title"
  },
  "image" :  {
    "path" : "/content/dam/test.svg"
   },

   .... 

  "footer" :  {
   "copyrighttext" : "copyright to"
  }
}
}

We couldnt use content fragments to define our data schema since content fragments have only a limited set of input field types which we were not able to extend and that UI wont scale with the UX.
So we end up creating on content fragment for each page to store the json blob in a text field in the content fragment. and site structure and CF structure looks as follows

Sites	Dam
/content	/content/dam/content-fragments
/mysite          --  language                 -- page 1                 -- page 2                        -- page 2.1	/mysite (folder)        -- language (folder)                -- page1(folder)                 -- page1(CF)                 -- page2(folder)                       -- page2.1 (folder)                       -- page 2.1(CF)                 -- page2(CF)        -- language (CF)

I would like to hear from the community that If we move forward with the approach of storing json blob like this, what will be the consequences? Since the size of the json blob is uncertain, max length of our text field in content fragment is a húge value to have some buffer (For Eg; 3000000). Even if i have a json blob of length 100, I understand that AEM might reserve the space to store 3000000 in jackrabbit repo. What are your thoughts on this approach. If you think this wont scale could you suggest an alternate approach to store json?

[Nirmal_Jose · Accepted solution]

My personal opinion - if you are not able to use the content fragment models and its content fragments for the content API then the information architecture needs to be reviewed again.

 Unless you are able to manage the content fragment content with content fragment models, it's no more structured content which can fail on a longer term maintenance.

Also, this approach won't use what AEM is best for  - WYSIWYG experience for content creation. So my view for a  non-AEM content API will be 
1. Identify and streamline content using content fragment models
2. Create content using content fragments - create variations based on channels.
3. Use core components like content fragment component [1], content fragment list component [2] and other core component to generate styled content
4. create content API for page template using sling model exporter for the managed JSON

[1] - https://aemcomponents.dev/content/core-components-examples/library/page-authoring/content-fragment.h...
[2] - https://aemcomponents.dev/content/core-components-examples/library/page-authoring/content-fragment-l...