When a search is made successful, the hospital search component will show a structured HTML grid view of 20 room availabilities to the users. When a search is made unsuccessful, a message of “no results” will be shown.
How can we build a high performance and scalable solution for this requirement? Below is “the non-optimized” and “the optimized” solutions for my recommended implementations.
Solutions
1. Non-Optimized, Unacceptable Solution
For this solution, the Sling Servlet with the /bin/my-app/search endpoint will be utilized. This Sling Servlet will accept the HTTP POST request. When the HTTP POST request is made to /bin/my-app/search, the AEM server will process the request with logic where it will make a server-side HTTP Client request to the third-party API, waits for the response, and returns JSON as results. With the JSON results returned from the third-party API, the AEM server-side logic will format and return the appropriate JSON data to the AEM front-end component.
The example below is an inefficient implementation because:
How can we build a high performance and scalable solution for this requirement? Below is “the non-optimized” and “the optimized” solutions for my recommended implementations.
Solutions
1. Non-Optimized, Unacceptable Solution
For this solution, the Sling Servlet with the /bin/my-app/search endpoint will be utilized. This Sling Servlet will accept the HTTP POST request. When the HTTP POST request is made to /bin/my-app/search, the AEM server will process the request with logic where it will make a server-side HTTP Client request to the third-party API, waits for the response, and returns JSON as results. With the JSON results returned from the third-party API, the AEM server-side logic will format and return the appropriate JSON data to the AEM front-end component.
The example below is an inefficient implementation because:
- All search request hits the AEM publishers.
- All search requests made to the AEM publisher are not cached; though including a caching mechanism may be more complicated when integrating this strategy into AEM.
- The Sling Servlet being scalable is limited by the number of AEM publisher servers available.
- All search concurrent requests made to the AEM publisher will consume the CPU, memory, and I/O resources, therefore other visitors may experience a delay.
2. Optimized, Better Solution
For this solution, the AEM front-end component makes the HTTP POST request directly from the client to the third-party API. The third-party API processes the request and returns the correct formatted JSON data. Next, the AEM front-end component will render HTML elements to the page.
For this solution, the AEM front-end component makes the HTTP POST request directly from the client to the third-party API. The third-party API processes the request and returns the correct formatted JSON data. Next, the AEM front-end component will render HTML elements to the page.
The example below is a more efficient implementation because:
NOTES:
For most high traffic AEM sites, we typically try to offload as much processing from our AEM live-publish instances to reduce CPU resources being used and to maintain good performance.
- All search requests hit a micro-service, and away from AEM.
- The search requests will not affect any processing from the AEM publishers.
- The search requests will not consume the CPU, memory, and I/O resources
- The micro-service will have caching abilities.
- The micro-service will be reusable across the organization.
- The micro-service will be scalable.
NOTES:
For most high traffic AEM sites, we typically try to offload as much processing from our AEM live-publish instances to reduce CPU resources being used and to maintain good performance.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.