Is this a sensible approach to use in AEM?

[Sutty100]

 So i would like to ask before I spend the time prototyping this up if you think this is a sensible approach to a problem I am trying to solve.

The issue: I have an Ecommerce site with a large number of categories. I don't want to load them all into AEM if I can help it. I want to be able to have a basic layout that all categories will use unless it is specifically overridden for a specific category.

My solution:  There will be a layer between the front end and AEM, this will translate a url from say /shop/categoryA to /content/categories?categoryId=A and make a call to AEM.

in AEM at /content/categories will be some logic that checks if this category has been created if so return it, if not return the generic category layout.

Do you think this is a sensible approach? The layer between AEM and the front end can be taken as a given we will be implementing that. I'm more concerned about my plan to lookup categories in AEM does this seem like the best way to solve my problem. 

[varshsr]

using the query parameter will limit you not using the AEM dispatcher cache 

if you need to use AEM as product catalogue brochure , then you need to import required product into AEM and then cache the pages derived out of catalogue blueprint .

the amount of product data that needs to be imported needs a decent content model to avoid flat structures 

why you do not want to import all the non volatile product data into AEM ? Are you seeing and product volume import limitation ?

[Paul_McMahon]

As another user pointed out using the query string means you won't caching the results in dispatcher. Can you cache the results in your other layer? Or will the result of /shop/categoryA be cached in a CDN for example? You will want to think through the performance impact of this model and be sure you have the capacity in you publish instances to deal with any increased traffic. 

One possible approach that would be similar but still leverage Dispatcher would be switch from a query string to a selector (/content/categories.a.html). This call could be cached in dispatcher but still be handled by /content/categories that same way the query string was used. A couple of downsides:

• You end up caching multiple copies of default template for all the categories that aren't overridden. Depending on how large you product catalog is this may or may not be a problem. 
• You are vulnerable to a DDOS attack because you aren't white listing the valid selectors.There are some potential ways to mitigate this risk (blocking access to /content//categories so only your front end layer can access it, adding a check to make sure the category requests is valid and returning 404s for invalid category requests (either in AEM or in your front end layer). 
• You will want probably need a periodic purge of the dispatcher cache to remove old of invalid cache results. 

[Jörg_Hoh · Accepted solution]

Hi,

what do you mean with "öayer which translates a URL ..."? Is this a dedicated application or application server, which sits in front of AEM and delivers the pages to the enduser? Or is it a servlet/functionality living inside AEM, which does this for you?

The recommendations by orotas and sri003 can be the right way if you have a dispatcher to cache the responses between AEM and the consumer of this service. Otherwise you can use a query approach, but then make sure, that you do your design your categories carefully, so you can either build a dedicated index or have all the data for it cached in memory.

Jörg

[Opkar_Gill]

Sutty100 wrote...

My solution:  There will be a layer between the front end and AEM, this will translate a url from say /shop/categoryA to /content/categories?categoryId=A and make a call to AEM.

Hi,

can I ask why you are not using AEM for the front end? I have seen this setup in the past, but reasons vary from technically not possible to lack of experience on AEM, so it would be good to understnad why you are going down this road.

Regards,

Opkar