I’m looking for a diagram that describe architecture of Enonic XP. I tried to googling many times but didn’t find any diagram. Do you have this kind of diagram or dependency diagram between sub-project of XP?
Thank you very much!
What do you mean “sub projects”? Are you looking for a diagram of the internals of XP?
Hi, I would like to use XP to develop an application and I have to add some complex business (and a state machine) into middle of sub-projects of XP. My idea is using JS controller to call to a business layer written in Java. So that it’s much easier for me if I understand the dependencies of the internals of XP. For example, I see that many sub-projects depend on :core:core-api, and project start with :libs:* are at upper layer compare with project start with :core:*
Here are some diagrams that illustrate how apps and XP relate.
Short version is to think of XP as an operating system that you build apps on! Your app may contain both JS and Java code in the same instance.
Each app will run within an isolated environment (as an OSGi bundle) - like every other XP component is handled. The libraries simply enable you to communicate with the other XP components.
Concept diagram of XP architecture
Concept diagram of an XP app (providing both client-side and server-side)
The only thing you should consider very carefully is if you are planning to hold state.
If you never intend to run multiple instances of XP (cluster) you do not need to worry, however, if you plan to scale things up, you should persist state in the XP storage (or other way to distribute that state in the cluster).
NB! We will soon be releasing support for Grid memory that allows you to distribute state in a cluster without persisting as well.
I see Ignite in the road map, I use Ignite before and very happy if XP can integrate with Ignite. How about GraalVM? I had some performance issues with Nashorn .
We have dropped Ignite, and are now using Hazelcast instead. In terms of Graal, this is most likely an XP8 thing. We have optimized use of Nashorn, so it is quite performant Imho.