[Epic] Micro Frontends

[DeepDiver1975]

Background

I'd like to discuss a different approach to build phoenix to address more the requirements we will have in the future. The future backend (ownCloud Infinite Scale) will be based on a micro service architecture.

So new additional services can be added to add backend capabilities. But what about the frontend?

There is an approach to this called 'Micro Frontends'

Proposal for the first step where we are talking about isolated apps only

1. one webserver will server different/multiple SPAs
2. all SPAs authorize using OpenIdConnect (without it will be pretty hard)
3. split Phoenix into reasonable pieces

• /files - SPA for the users own file spaces
• /public-files - SPA for publicly shared files/folders
• /account - SPA for setting any personal settings (there might be two different - one for oc10 and one for ocis ???)
• /admin - SPA for the admin to manage the system (in oc10 this might just we a redirect to the oc10 admin pages)

4. In order to give the user the capability to switch the SPAs each app will serve an app menu and elements are configured individually or by one backend service

Proposal for deeper integration

Deeper integrations will be much more explicit to clearly defined extension points of specific apps. As per #2573 two extension points for the files app are defined.

References

https://medium.com/@witek1902/ui-in-microservices-world-micro-frontends-pattern-and-web-components-23607a569363
https://martinfowler.com/articles/micro-frontends.html
https://micro-frontends.org/

Commonly shared elements between SPAs

There are items in the system which will be used by every phoenix SPA.

1. First of all the applications config section (see [Epic] different and well defined extension points of phoenix #2573 ) is used by every app to display the application switcher.
2. For authentication an OpenID Connect Provider is required - will be a mandatory part of future owncloud installations.
3. Shared web assets like the navigation bar, applicatoin switcher, user menu, avatar display. This can happen via explicit npm packages which are build from the design system. These elements can or caoont contain logic (e.g. query backend for config)
4. Specifically shared elements. Thinking about files and public-files these apps will share elements and logic. One approach could be to reuse a shared npm package or build two apps from the same source repo

[DeepDiver1975]

Todays phoenix is like on the left - future should be like on the right

[PVince81]

@DeepDiver1975 one missing bit in the diagram is that there is likely a "wrapping frontend" that contains the header, navigation, etc.

We also need to see how extending the files app would fit into this.
Here are the existing known extension points already: #2423

• app navigation: this is needed anyway, so one of the microservices needs to be a hub for extension points. Apps like "calendar" would register their URL there. The "wrapping frontend" or navigation bar would query the list of app URLs from an API endpoint exposed by microservice.

• files sidebar panels: would need iframe for panel content. registering panel to be done on extensions endpoint API in backend

• file actions: register in backend through API. files app reads available file actions from API endpoint. For frontend component to process the actions, would need a hidden iframe ?! It depends on what the action is supposed to be able to do.

• new menu actions: similar approach like navigation entries: "file type + target base URL"

• future: indicators in file row: need to be examined/specified first

[DeepDiver1975]

one missing bit in the diagram is that there is likely a "wrapping frontend" that contains the header, navigation, etc.

From my understanding this is living in each app on it's own or there is a top level html which has some menu and loads the apps in iframes (or even as web components ..... see https://github.com/asc-lab/web-components-poc/blob/master/all-components-together/index.html)

[DeepDiver1975]

Any extension points within the files app might work on a different level .... but maybe even web components are of interest here as well .....

[DeepDiver1975]

Configuration options on extension points are in detail described in #2573

[DeepDiver1975]

* new menu actions: similar approach like navigation entries: "file type + target base URL"

this need to be part of the fileActions config as per #2573

* future: indicators in file row: need to be examined/specified first

We need to define this once we are there. As a design goal every phoenix extension/app shall be on pure config level in the first place.

[PVince81]

Next up:

• document and adjust diagrams to represent the clear separation of phoenix-assets from phoenix-files app

• discuss and decide how we want to split and deliver the above assets (npm package, etc)

• phoenix-common npm package(s)

  • pure frontend without logic (design system) => owncloud-design-system as npm
  • logic into SDK as npm
    • app switcher: SDK ?? https://docs.microsoft.com/en-us/graph/api/application-list?view=graph-rest-1.0&tabs=http => put it in SDK for the time being until we can use the MS Graph JS SDK
    • account menu => have it bundle inside top-bar
    • notifications => separate from the top-bar, injectable through slots
    • left sidebar toggle menu is in top-bar, but not the sidebar itself
  • auth is done with the oidc-client library

• raise and clarify tasks for later scheduling

  • for actually doing it later on
  • coordinate with OCIS team to have the assets used in ocis-hello
  • how to reuse of OC 10 phoenix app for serving some of these things ?
    • OC 10 app that delivers phoenix-files and replaces the files app
    • OC 10 app that delivers phoenix-common and automatically replaces the top bar

[PVince81]

More tasks to keep in mind in the future:

• sort out smooth authentication, because the UX sucks when you have to "authorize" again in every app page we open => openid connect (Login is cumbersome #2064)

[DeepDiver1975]

example implementation of minimal SPA is in here - https://github.com/DeepDiver1975/turbo-eureka

Needs cleanup, review and proper baseline as start for any other SPA (vuecli plugin maybe ....)