Async API

[Behnam-Emamian]

I have check the oqtane api and I can see it is not implemented async, is there any special reason for that? I beleive async should have a better performance.

[sbwalker]

This is one of those topics where there are a lot of opinions. My personal understanding is that async is not about performance, it is about scalability (which is a completely different concern). Basically an asynchronous approach is all about managing the number of workload threads, which in theory can allow it to achieve greater scalability. However, the tradeoff for using async is greater overhead which actually reduces the performance of the application for smaller workloads. There are plenty of load tests online which demonstrate how API performance is worse when using asynchronous - however at the point of thread saturation the synchronous approach will choke whereas the asynchronous approach will continue to handle the load. But it is important to note that it requires REALLY intensive loads to create this scenario - and usually you have the ability to scale up or out to deal with it in other ways. There is also plenty of literature on how the database is actually the bottleneck and will fall over well before the web thread pool is exhausted. In addition, async code is much harder to debug - which can create maintenance issues. I am sure other folks may have other experiences and opinions... but Oqtane chose to use a synchronous approach for its API/repository layers. This is one area where we fall back to the Consistency philosophy (https://www.oqtane.org/blog/!/20/oqtane-philosophy) and take the approach that a consistent pattern throughout the framework is more important than trying to embrace multiple approaches.

[Behnam-Emamian]

Thank you for your timely and thoughtful response.

I concur with your assessment that the appropriate implementation of an API is largely contingent upon the specific use case. If the API requires frequent interaction with a database, then an asynchronous approach may prove advantageous.

I would appreciate your counsel on the feasibility of creating two distinct module templates - one for synchronous and one for asynchronous processes. Would it be wise for me to focus on developing the asynchronous version?

[sbwalker]

The topic of alternative templates have come up previously... there were requests for alternative templates which use the code-behind approach (rather than inline), which are created internally within the framework codebase rather than external, use a generic repository pattern, use async APIs, etc... My goal is to keep the core framework as lean as possible so I am not in favor of including a bunch of alternative templates in the core code itself. In addition each template has its own maintenance requirements, so when new core features are introduced it creates a lot more work to ensure all the templates are updated. To satisfy the need for alternative templates it is possible to create templates and package them as Modules which can be installed using the standard installer. As example is the Code Behind template created by @leigh-pointer https://github.com/leigh-pointer/StuidoElf.Oqtane.Templates