search

NIAEFEUP / tts-fe

A platform where students can experiment with the possible combination of schedule options they can pick at the start of the semester
https://tts.niaefeup.pt
10 stars 1 forks source link

Coollaborative edition of schedules #165

Open diogotvf7 opened 8 months ago

diogotvf7 commented 8 months ago

Why

It is very common for students to want to choose the same schedule as their friends. Therefore, there should be a way for users to edit their schedule options in a collaborative session with their friends.

References

diogotvf7 commented 8 months ago

https://pypi.org/project/python-socketio/ for server https://socket.io/docs/v4/client-installation/ for client

thePeras commented 8 months ago

Maybe this is better for the server https://github.com/django/channels

Process-ing commented 4 weeks ago

About the debate of Socket.IO vs Django Channels for the backend, I feel that Socket.IO is the better alternative.

Django Channels is only useful if you are developing a pure Django (no Node.js) solution that should support multiple protocols. Since we are using Node.js and only care about WebSocket for the communication, this isn't very relevant. Socket.IO is also much more focused for real-time communication, which is exactly what we are after. It has multiple features for this end, like the rooms feature that we discussed in our meetings. Also note that Django Channels is not compatible with Socket.IO, so the frontend would have to use the standard WebSocket API.

Being the one that will work with the WebSocket communication (in issues #233 of the frontend and #89 of the backend), I will proceed with the Socket.IO API, but tell me your thoughts if you think Django Channels is better.

tomaspalma commented 4 weeks ago

I agree with it, specially if by using django channels we would need to use raw websockets on the frontend, which would make the development experiente degraded.

Process-ing commented 4 weeks ago

Apparently I discovered that the backend used Node.js, apparently not, my bad, but I still think it is best to setup Node.js to use Socket.IO.

And about the use of Socket.IO vs WebSocket on the frontend, I don't think that using WebSocket is worse for the programmer experience (I even think that the Socket.IO API is a little crappier xD), but it does not provide many of the features that makes Socket.IO so useful.

tomaspalma commented 4 weeks ago

Apparently I discovered that the backend used Node.js, apparently not, my bad, but I still think it is best to setup Node.js to use Socket.IO.

Are you suggesting having a separate nodejs server for socketio apart from the django that we already have?

Process-ing commented 4 weeks ago

Apparently I discovered that the backend used Node.js, apparently not, my bad, but I still think it is best to setup Node.js to use Socket.IO.

Are you suggesting having a separate nodejs server for socketio apart from the django that we already have?

Forget what I just said, the Node.js thing is related to the frontend, we just need to include Socket.IO from pip, again my bad.

thePeras commented 3 weeks ago

Socket.io requires running a second instance among the already django server. For what it has to offer, I don't consider it worth. On the frontend part, we can easily create our own wrapper to attempt our needs.

If the backend was in node.js, I would immediately recommend socket.io, but since it's Django, we should follow its philosophy and resources.

tomaspalma commented 3 weeks ago

When you say that it requires running a second instance are you talking about this part?

image

If so, this is also the standard way to do it in a nodejs server (to instantiate a socketio server instance)

thePeras commented 3 weeks ago

When you say that it requires running a second instance are you talking about this part?

Yes.

The question is: Are we able to get authed user information from this approach? Also, are we able to get it by using Django channels? If the answers are no in both questions, so let's use socket.io. If is no to the first and yes to the second, we may need to discuss as this data can be useful, for example, to display the name and photo of the user.

Process-ing commented 3 weeks ago

After digging more on this issue, I have to agree that creating a second instance for Socket.IO would probably be necessary, which isn't worth it. Ironically, the solution to that problem seems to be to also use Django Channels, in conjuction with Socket.IO, since it allows the Django HTTP methods to coexist with Socket.IO for WebSocket communication. This seems to be a popular approach and there are some guides explaining the setup (e.g. https://www.videosdk.live/developer-hub/socketio/django-socketio).

I still need to test this further, but I will keep this thread updated. If this ends up being the best solution, then this debate will not need to be continued, as both libraries and their functionalities will be available to the backend :raised_hands:

thePeras commented 3 weeks ago

Does AuthMiddlewareStack work with that approach?

To be honest, I would prefer using raw django channels only.

tomaspalma commented 3 weeks ago

As stated here, using raw web sockets will require us to make a lot of functionality that is offered by socket.io, such as automatic reconnection, rooms and other features.

@Process-ing Since if socket io can be used with django channels and you are on the issue of setting up the web sockets on the backend, can you explore if we can use AuthMiddlewareStack that is a feature of django channels even if using socket io? Since this is starting to become more than just setup something, if you think you need help or another person to do this issue with you feel more than free to say so!