Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client-server architecture for SPG #1

Open
clement-moulin-frier opened this issue Nov 11, 2021 · 6 comments
Open

Client-server architecture for SPG #1

clement-moulin-frier opened this issue Nov 11, 2021 · 6 comments

Comments

@clement-moulin-frier
Copy link
Collaborator

Bonjour à tous,

Voici ci-dessous quelques pointeurs pour implémenter les interactions client-server. À première vue, la solution Flask me semble être intéressante, mais je n'ai pas d'avis tranché.

@mgarciaortiz , as-tu une préférence de ton côté ?

Je copie ci-dessous les messages que j'ai reçu de certains membres de mon équipe à ce sujet (en anglais).

J'ai aussi regardé Flask d'un peu plus prêt, voici deux liens qui me semblent intéressants :

https://flask.palletsprojects.com/en/2.0.x/quickstart/#apis-with-json

https://auth0.com/blog/developing-restful-apis-with-python-and-flask/

Il y a peut-être aussi quelques inspirations à prendre dans la REST API de Pypot : https://poppy-project.github.io/pypot/remote_access.html
(Plutôt l'interface que l'implémentation qui date un peu -- Flask n'existait pas à l'époque ..)

++
Clément

Messages de l'équipe Flowers:

The first idea that comes to my mind when you say you want the client to "connect" to the server and then send commands is to use Python sockets. You create a Python program which starts a socket on an arbitrary port and listens for connections and instructions (https://realpython.com/python-sockets/#running-the-echo-client-and-server).

You could also use Flask to create a web server with HTTP routes, but you won't get (at least you'll have to implement it) a connection protocol.

The only key difference I see is that if you use a connection protocol, your server can send things to the client whenever it wants. Whereas if you don't, client will send info to the server and receive info only as a response of its send. I don't think one solution is better than the other, it only depends on what you want 🙂 And yes Flask is very easy to use!

I think both ways you'll have to serialize data as JSON-like. If you only send primitive types or numpy arrays it won't be a big problem. You can also pickle dumps objects and send the obtained string (so that you can pass Python instances through your request). I'd advise using this solution only if necessary (it's not super clean in my opinion).

You might also want to look into websockets, which is maybe a bit more high level than using the sockets interface

https://websockets.readthedocs.io/en/stable/

@gaorkl
Copy link
Collaborator

gaorkl commented Nov 11, 2021

Salut!
De mon côté je pense qu'il y a deux requirements qui peuvent être intéressants:

  • une solution cross-plateform (Ubuntu, mac, Windows). Je pense que ça peut être important.
  • la possibilité d'avoir le serveur en remote. Ce n'est pas nécessaire, mais si ma solution choisie permet de faire ça facilement ça peut être bien de lavoir en tête.

Qu'est ce que vous en dites?

@gaorkl
Copy link
Collaborator

gaorkl commented Nov 11, 2021

Pour le json, je peux ajouter ça côté SPG.

@clement-moulin-frier
Copy link
Collaborator Author

  • une solution cross-plateform (Ubuntu, mac, Windows). Je pense que ça peut être important.

Tant qu'on utilise une librairie en Python je pense que ce sera le cas. Pour la solution Flask c'est certain je pense (c'est juste du protocole http) ; pour les sockets je pense aussi mais mieux vaut vérifier en effet.

  • la possibilité d'avoir le serveur en remote. Ce n'est pas nécessaire, mais si ma solution choisie permet de faire ça facilement ça peut être bien de lavoir en tête.

Pareil, je pense que les deux solutions peuvent faire ça (à condition d'avoir le port correspondant ouvert/redirigé). Ici encore, c'est certain pour Flask ; pour les sockets quasi-certain.

@plorgue @jizekki Qu'en pensez-vous de votre côté, Flask ou sockets ?

@clement-moulin-frier
Copy link
Collaborator Author

Pour le json, je peux ajouter ça côté SPG.

Oui je pense qu'on peut utiliser du json pour transmettre tous nos types de données entre le client et le serveur.
Si tu penses qu'il vaut mieux "jsonifier" côté SPG, ça me va.

@jizekki
Copy link
Collaborator

jizekki commented Nov 11, 2021

Bonjour !

Avec Paul, nous avons regardé les deux possibilités. Flask semble en effet être le plus adapté pour réaliser l’architecture du serveur. L’utilisation des sockets quant à elle semble être compliquée. Du côté du client, le module requests pourra être utilisé pour envoyer des données (sous forme de dictionnaires Python, tuples ou JSON) au serveur à travers des requêtes HTTP et recevoir les réponses. Les deux modules fonctionnent (selon la documentation) sur tous les OS (Linux, MacOS, Windows). Flask fournit la méthode jsonify pour construire du JSON à partir d’un dictionnaire Python, et requests dispose de la méthode json pour transformer la réponse HTTP en JSON. Le serveur Flask peut aussi être facilement paramétré pour être lancé en remote.

@clement-moulin-frier
Copy link
Collaborator Author

OK super, merci pour les infos. En avant pour Flask alors :)
Ça reviendra du coup à mettre en place une REST API pour SPG.
Du coup vous pouvez commencer à coder une classe mock pour le serveur.
On peut continuer à interagir sur cette issue si vous avez besoin de feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants