Hello Nextcloud developer friends,
I am currently working on an app for Nextcloud as a part of a project in my university. I am now documenting my development process and right now I am explaining the design of how my Nextcloud app integrates on the Nextcloud server. For this I have made a component diagram:
The point I want to explain with the diagram is how nc apps work with the interfaces and how they work with the same data. My question is if you have any suggestions for improvement or see any errors in my diagram. The diagram should be kept rather simple and only illustrate the principles. I would be very happy about your feedback!
1 Like
Is there any special aspect you want to focus on (like the database access)?
No, nothing specific, I want to give readers a general overview of how the app we are developing fits into the server and interacts with the environment
You are only focusing on the backend?
Currently yes but maybe it would be a good idea to include the client as well
For the backend, I have the suggestion, to go with something like this (just as example):
Thank you for the suggestion! I have a question about the figure: Does the kernel mean the core of the Nextcloud server?
I would mean by the kernel the index.php and some base files that build up the initial structures like the dependency injection structures (called containers) and the like.
The core is rather roughly defined. What would you call the core? What is in the core folder in the server? What is common to all NC server installations?
I, personally, would consider the kernel the core with all the periphery code as interfaces. That is the AppFramework, the ORM, the storage handlers, the Redis connecot (which I dropped above) and all common code to be shared by the server. So, in fact everything minus all apps. But this might be just definition.
Ok thanks, that makes sense.
Where would you put the router in the diagram or is the router then also part of the kernel?
You could interpret the router as part of the app framework, as part of the kernel or as dedicated instance in the core. Or depends a bit on your view on things and your focus.
PS: there is also the remote.php as an alternative to the normal routing via index.php. This is for non-user interactions. Just for completeness here.
Thanks a lot, helped me understand it better!
One last question:
How would you describe the connection between the apps and the app framework: do the apps implement the framework, use it, or are they part of it?
The app framework is an abstraction layer for all the parts that the core is handling like the files, the DB etc. You can see it as a sort of operating system that provides some helper functions to handle various basic tasks. In this analogy, the framework (and the core and the real OS) are the “OS”, while the apps are the regular “programs”.
I’m unsure here. Do the apps really access the ORM or the files storage via the AppFramework? Are they not accessing the file storage via the OCP\Files interface? This is not part of the AppFramework or?
That depends on how you define the app framework. If you restrict it to OCP/AppFramework, then, yes, this is most probably true, especially as in OCP there are only interfaces without implementation 
.
You can however interpret it that way that the dependency injector provides you with the necessary classes/implementations in order to access the various resources. In that interpretation the app framework (which covers the per-app containers and DI algorithms) would indirectly provide access to said resources.
