Integration of apps - best practices

đź’» Development app dev
1

Hello to everyone,

again, I want to trigger a discussion on a rather abstract topic in the ecosystem of Nextcloud and its apps: Integration between foreign apps.

I am developing one app on the NC app store so far. There are quite some requests to integrate the app with this and that other app, like the calendar, the deck, the notes, carnet, etc.

I can understand the wish to have all these pieces glues together as neatly as possible. This is one of the ideas to have a NC server and it is promoted that way as well. For the core apps, this is realized quite reasonably (or on the way there). You can share files to a circle and use that circle in talk to have a quick chat on things etc. All nicely and neatly integrated.

The problem appears when it comes to third party apps. For a common user, the difference is not easy to explain. Even I am unsure from time to time, if a certain app is supported by the core team or just a third-party app. I, personally, find it sort of hard to and tiring to explain over and over that it is currently not possible to connect the shopping list of the cookbook with the deck app for example.

Using and accessing other third-party apps using classes in OCA\<other app>\ might work but will eventually break easily. I would not consider this a good design. I have read a few posts here that discourage the direct access of remote classes rigorously.

Sending events using the event dispatcher might work better as the code is less coupled. Also, if an app is not installed/available/… the event can simply not be received in the worst case. No big breakdown is to be expected.

Essentially, the same argument holds true for accessing any foreign API endpoints from the frontend. These are prone to update and might break from version to version and create a tight coupling between the various apps.

This means, that all app developers would need to implement a certain event system (based on the OCS event dispatcher, similar to e.g. DAV with \OCA\DAV\Events\...) in their apps as soon as the app has reached a certain maturity. Also, versioning issues might arise if the event’s definition or payload evolve over time. So, this should be thought through carefully and a best practice should be derived. This can then be used for all third party apps.

Maybe there are even better approaches possible? Do you have any better idea? Or is there even something I am not aware of so far?

Long story short: I would like to start a discussion on how integrations between different apps could be created in the mid to long-term time span for all (interested) apps. Then, some sort of best practices should be published in the dev documentation and any required update to the core might be carried out.

Considering the big goal of the NC ecosystem to integrate all sorts of functionality, it would be good to have a clear view on how this agenda might be achieved. I am posting this topic here for discussion, ideas, optinions, and suggestions. I hope it will get some traction and eventually, the discussion lead to a solution in the long run.

Christian

4 Likes
2

Agreed. Also should not be done without contact to the maintainers so they are aware of the dependencies and can avoid breaking or at least know whom to talk to after having done bigger changes.

I would say communication is the main key here together with simplicity. For the first iteration/collaboration or if there is only “one” target, direct class access might be doable and easier maintainable on all sides. When something grows bigger or is more spread abstraction via events or server classes is most likely the better idea.
In Talk we have all 3 directions in both directions.

  • OCA
    • In We are directly accessing OCA\Circles because there is/was no proper other way back then and we were a bit in a hurry.
    • Out Also we know that e.g. the appointments app is directly using OCA\Talk classes.
  • Event
  • Manager/Provider in Server
    • In Notifications, Activity, Sharing, …
    • Out OCP\Talk\IConversation was recently introduced https://github.com/nextcloud/server/tree/master/lib/public/Talk allowing apps to create conversations. This should replace the OCA-Out usage by the appointments app. It could have also been done by an event that apps can emit and talk creates a conversation and attaches it. But a proper typable interface in server is more reliable and less likely to be broken.
    • :label: Personal opinion I think this is the cleanest approach, but you need to know what you need and once introduced OCP API can only be extended but not broken for 3 years+ So it’s better to first do a dirty approach until you are sure it settled.
3 Likes
3

Hi,

nice topic.
I would like to add another point to this. You are referring to functional interactions between apps, like creating content/deck/talks, …

I think as NC is evolving from a file-sharing-centric app to a platform, generic content connection across apps is missing. There is calls, sharing, projects, circles, comments,… with all of these developing some linkage per usecase. If an community app wants to connect content, its not possible (e.g. the sharing table only focus on file types).

I am suggesting a generic “link” backend where any object can be linked to any objected defined by parent|parentType|child|childType (type = appId or whatever).

This would enable flexible integration on content (not only function as mentioned here) by any app.
e.g. I could link an analytics report to a project; Share a playlist with users; generic sharing of content with users (now: custom developed by every app);

By replacing the different sharing mechanisms (incl. the current core one) by a clean/generic one, it could offer a better integration for any future ideas to come. Not to forget that there is only one single point handling e.g. user deletion processes (DSGVO).

Not sure if you see this part of this discussion or separate. But I think there is functional integration as well as content integration between apps.

this is something that does not sound logical to me in my personal opinion. Even if Talk is a strategic part of NC, it is an optional app and no core functionality like Notifications, Activities or Dashboard.
And apps are OCA (or events). I think there should be a clean separation between platform and apps - especially due to different/shorter(?) release cycles.

4

You can also disable notifications, activities and dashboard and all the apps that have either still continue to work. That is exactly what we are rebuilding.
Also the BBB app can register as a Talk backend and implement the OCP\Talk\IConversation interface and the calendar app doesn’t even have to care. It will happily use the created URL and put it in the invitation field.