Aide sur architecture de solution
Pyroh
Membre
Bonjour,
Pour mon boulot je dois passer par un éditeur web pour coder des web apps. L'éditeur est basé sur Che —l'Eclipse web edition— et c'est buggé à souhait. On reste cependant sur une architecture client serveur donc avec un peu de reverse engineering j'ai pu définir comment fonctionne l'API et je vais pouvoir à terme travailler avec des fichiers locaux synchronisés avec le backend au travers d'une app sur la machine client. Les tests sont concluant.
Voilà les morceaux qu'il me faut :
- un qui s'occupe de la communication avec l'API.
- un watcher qui scrute les changements sur le disque.
- un central engine qui gère l'état des fichiers, la synchronisation, etc..
Pour le moment je compte faire ça avec une seule app monolithique qui utilise GCD pour les appels réseau. Mais je me demande si ça n'est pas le bon moment pour mettre les doigts dans les XPC avec :
- L'app qui sert de central engine.
- Un XPC pour scruter le disque.
- Un XPC pour la gestion de l'API.
Je n'ai jamais utilisé cette techno, j'ai une bonne connaissance générale de la com inter-process mais ça remonte à mes TP, je n'ai pas eu à les utiliser depuis lors. Ou presque pas.
Ce qui fait que je me demande si :
- L'architecture que je propose est viable (deux XPC n'est-ce pas un de trop, ou deux...)
- Vous avez des conseils sur l'emploi de cette techno ou un autre avis sur l'architecture.
Pour le moment je vais commencer à coder les différentes parties et les tester je pourrai réorganiser par la suite.
Merci 😃
Réponses
Dissocier certaines parties "potentiellement critiques" de l'application dans des XPC est un bon choix. De plus ce projet te sert pour mettre le pied à l'étrier de cette technologie c'est encore mieux.
Personnellement je ne vais qu'abonder dans ton sens et je ne trouve rien à redire dans ton choix.
Cela dit, et uniquement par curiosité et pour voir si j'ai bien compris, qu'elle est l'API sur laquelle tu as effectué le RE ? Celle de Eclipse WE ou une autre partie ?
Ça t'aide si je te dis que je ne sais pas ce qu'est un XPC ?
Non 😧
Plus je réfléchis à la question plus je me dis qu'il me faut un XPC pour la partie communication avec l'API certes mais il me faudrait aussi un helper. Une app faceless qui s'occupe de tout et qui se pilote depuis un GUI. Donc il me faut un helper mais je trouve très peu de documentation sur comment l'implémenter.
Quelqu'un a une idée de comment gérer un helper qui fasse autre chose que lancer une app sandboxée au boot ? C'est surtout la communication entre ce helper et le GUI qui m'intéresse.
Pour ce qui est de l'API en elle même c'est du produit SAP basé sur Eclipse WE donc c'est quelque chose de très spécifique. Tout ce que je peux dire d'intéressant est que c'est l'API qui permet au frontend en javascript de communiquer avec le backend. Je n'ai aucune info sur le backend.
J'ai trouvé comment faire des opérations CRUD sur la liste des workspaces, des projets et des fichiers. Le reste ne m'intéresse pas parce qu'il est potentiellement buggé.
"gérer un helper" que veux tu dire ?
Tu veux donc avoir une application qui officie en tâche de fond même si ton application principale n'est pas lancé ? Faut-il vraiment cela, un XPC ne serait-il pas suffisant ?
Pour la communication je pense que tu as le choix, socket, shared memory, machport, distributed object (runtime cocoa). Certaines méthodes ne sont pas compatibles avec les apps sandboxés et pour d'autres il faut utiliser le même "application group".
Ouais, ce n'est pas la première fois que j'entends ou lis "XPC" mais je ne sais toujours pas ce que c'est !
Moi, c'est la première fois !
Voir la session 241 sur youtube spécial XPC
https://youtube.com/watch?v=2vvHlK3DvTM&t=856s
Alors l'architecture que j'ai décidé d'explorer est la suivante :
Le helper n'est pas un XPC Process pour la simple et bonne raison que d'après la doc ils sont stateless (pas pratique) et surtout qu'il peuvent être killé par l'OS à tout moment (vraiment pas pratique).