hackmit / playground Goto Github PK

Sorry to interrupt, but I can't log in after the deployment is done.

Hi development team!
Thanks for this open source platform! We are planning to use this platform for an upcoming hackathon but are facing a few issues in the deployed software.
When the playground is deployed on AWS ElasticBeanstalk and we use the deployed version as the websocketURL for the frontend running on localhost, the frontend does not display the SVG images for all the locations except Personal Room (that is, the town plaza etc. are not rendered) although the character and its movements work fine
However, all the SVGs seem to be rendered fine when the backend is run on localhost.

We wanted to ask whether you had faced a similar issue on the deployed software? If yes, could you please suggest a workaround for the same? Thank You!

cc @jackcook

Summary

One idea we've tossed around involves creating a virtual "jukebox" for our hackers, similar to plug.dj. Hackers will be able to suggest songs by entering YouTube URLs, which will be put into a queue. All of our hackers will then be able to listen to the same songs at the same time.

Potential solution

1. Pick a "leader" ingest server
2. Create new type of packet for receiving song requests, save video URL and sender ID
3. When we receive that packet, add the data to a Redis list
4. The leader should publish events when we should move to the next song, sending a new YouTube URL to all of our clients

Open questions

1. What if our hackers don't all like the same genres of music? Should we have multiple different jukeboxes for people to join?
2. Our backend is a distributed system, but the events that need to be sent for this to work only need to happen once. How do we decide which ingest server starts a new song, for example? Talk to Jack for suggestions -- use 046 in the real world :') (see slide 11 - leader election)
3. What do we do if someone submits bad videos? Is there a YouTube API that identifies whether videos are music videos? Should we implement a system to ban people from submitting song requests?

• Browser notifications
• In game notifications
• SMS
• Slack bot?
• Google calendar?

Summary

We use Redis's pub/sub paradigm to receive real-time updates from other ingest servers. However, right now all events are sent over the same channel, room. Since each ingest is subscribed to room and publishing to room, each ingest server receives events that it already knew about. We should change this to make our messaging more efficient.

For example, if we have two ingest servers, each sending 100 messages/second to Redis, each server would receive 200 messages/second from Redis. With this change, each server would only receive 100 messages/second from Redis, a huge reduction!

Potential solution

Instead of having a single room channel, each ingest server could publish to a different channel (e.g. room-1, room-2...). However, each ingest server would then have to be aware of all of the other ingest servers.

1. When the server starts up, generate a unique ID that we can use to identify this ingest server. Then, save this ID in Redis so that other ingests can find it when they start up. Consider using a Redis set.
2. Fetch from the ingest IDs set so we can find the other ingest servers. Subscribe to each of their channels (room-<id1>, room-<id2>...) to receive their events.
3. Publish messages to room-<id>, where <id> is the current ingest's unique ID.
4. On startup, also publish a message to a new ingest channel to let other ingest servers know to subscribe to our events
5. Profit?

Summary

Right now, we assign people a unique ID every single time they join -- this doesn't give us any way to identify hackers. Ideally, people will sign into Playground with Quill SSO, allowing us to identify each hacker, and save their progress/location/etc each time they leave and re-join.

Potential solution

Talk to Shirlyn 😛

Hi, thanks for making such a great event platform open source! We're planning to use it for an upcoming hackathon and have been trying to test deployment on elastic beanstalk before we deploy our final version.

We've tried deploying frontend and backend separately, but the app-deploy step fails in both cases. The versions we're trying to test deployment with are the latest hackmit repos, with our own .env file and some other minor changes. The error for backend appears to be some missing file or directory relating to nginx, but we couldn't find anything similar online. We think it might have to do with the fact that Redis runs locally in development but is not present in production on localhost:6379.

May I know all the steps that your team took to deploy everything on elastic beanstalk? I can include the error logs if necessary. We would really appreciate it, thanks!

Summary

Our users should be able to chat with other people in the same room, similar to how you can chat in Club Penguin or other similar online games. Clients should be able to send a chat packet, which is then broadcast to other clients in the same room as them.