Draft (Proof of Concept) - Add an hybrid SPA/SSR interaction #1727
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…so-called 'prod' one
The current quality gate raises "errors" that just aren't. Duplication, Coverage, all these indicators are interesting, but they should not be used with arbitrary values to achieve our quality goals. Hence we will disable the Quality Gate check on Github actions side, while keeping it on Sonarqube side for regular analysis.
…so-called 'prod' one
It's not a plugin like ArgoCD, Gitlab, etc. but it's a dedicated component with its own lifecycle, docker image, etc.
We thought it could be handled as a plugin like ArgoCD and others, but in the end it's more like an adhoc integration that might even be moved outside of this repository.
…le workers on the runner
…cement de l'application console
…fied but tests have
…CDS contract in server
In this commit, I added a `plugins/opencds/app.js` script that is a standalone, SSR-ready Vue.js component. This component is retrieved as a rendered raw string through a `GET /api/v1/opencds` HTTP request made by `client` (in the user's browser) and then loaded by Vue.js in the DOM thanks to the `v-html` directive. Then, a dedicated `onUpdated` callback is triggred by the DOM update and this will trigger _another render_ of the component, on the client this time, that will be "mounted" by Vue.js on the SSR DOM node. Thus the component is rendered by the server, loaded by the client, and Vue.js handles all the 🪄MAGIC🪄.
|
0 New Issues
0 Fixed Issues
0 Accepted Issues
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Ticket lié: #1623
Contexte
Dans le cadre d'une possible orientation de Console vers un mode de fonctionnement plutôt SSR (Server Side Rendering), dans lequel
clientetserverseraient fusionné en un seul projetcorequi recevrait ensuite ses plugins via de l'injection de dépendance, il nous faut envisager que les plugins soient "auto-portés", c'est-à-dire qu'ils contiendront à la fois les parties d'API de backend, et à la fois les parties de Composant de FrontEnd. Les plugins pourraient alors être chargés indépendamment (au graphe de dépendance près) et alimenter ainsi la Console dans son ensemble, plutôt que d'être "hard-codés" tantôt côtéclient, tantôt côtéserver.Pour permettre une transition de la Console vers ce possible mode de fonctionnement futur, il nous faut explorer la possibilité de faire un rendu, côté
server, de composants Vue.js, de manière à progressivement transformer notre full-SPA (Single Page Application) en hybride SPA/SSR (via de l'hydration des composant Vue.js qui auront été rendus côté serveur).De cette manière l'application Console pourrait grosso modo suivre le fonctionnement suivant:
core) serait initialement démarrée. Il s'agirait d'une application Vue.js SPA/SSR qui aurait ses composants basiques (home page, login, etc.) et les routes d'API qui vont avec.console, et qui seraient alors chargés au démarrage, chacun exposant des routes HTTP permettant de récupérer les composants Vue.js, et des routes HTTP d'API pour leur fonctionnement métier.Si un fonctionnement tel qu'énoncé est possible, alors CPiN pourra devenir une "variante" de la Console avec ses plugins propres (ArgoCD, Vault, OpenCDS, etc.), et les autres utilisateurs de la Console pourront avoir "leurs" plugins (Flux, AWS Secret Manager, MonPluginCustom, etc.).
Contenu de cette MR
apps/client, ni deapps/server)stringlors d'un appel declientversserversur la routeGET /api/v1/opencds(note: le JWT de session est passé afin d'éviter une 302 vers Keycloak 😅 )innerHTMLdans le template concerné de l'application cliente (ici j'ai créé unListServiceChainBisqui me sert de placeholder, vu queListServiceChainest déclaré dans le router. Je n'ai donc rien à recréer ici, je "squatte" la place)onUpdateva se déclencher et déclencher un deuxième rendu du composant ce qui permettra de le monter (au sens Vue.js du terme) et donc d'avoir les évènements du DOM qui vont avec (@click, par ex).Reste à faire
ListServiceChainqui est ici squatté) ce qui permettra de valider que tout un composant Vue.js avec sa diversité et sa complexité va fonctionner dans ce nouveau modeNotes
plugins/opencds/app.jsest lié symboliquement (ln -s) enclient/src/opencds/app.jsetserver/src/opencds/app.jsafin de ne pas lutter contre les règles d'import Typescript qui imposent que tous les scripts imports soient localisés danssrc/. Dans la cible, oùclientetserverseraient fusionné, ce sujet serait caduc.