lemasc
commented
1 year ago This PR seems to be okay for now. However, there are rooms of improvements here.
- We have started using GitHub organizations, but Vercel "Hobby" plan doesn't support deploying from organizations. Netlify does support, however there might be a problem in setting up Next.js on production or some issues. Rechecking on that.
- The
kiosk-socketserver is now deprecated. There still contain some logics, including fetching the playlist from Firestore. I haven't setup this yet, because I think this website should be merged with the main website as in #1 and the database will be changed as in #3 . But even if the refactor won't finished, I'm now certain that this PR still works with the main, old version. - We can boost up the performance by running server code in Edge Functions. Netlify and Vercel supports that. However, most of the libraries are relying on the Node.js
streammodule (in node-fetch for example) andcryptomodule (for encrypt, decrypt data). We can patch it manually like I did, but it might be better if we fork it out to this repo, and setup some automatic actions to sync up with the mainstream (similar to this repo does). However, it's not high priority I think. I prefer stability over speed of the website. - Also, I don't know if this year's council will use this system or not. 😿
I will not merge this for now, until there's more direction to this system extension.
Note that the build script now should be yarn kiosk dev instead of yarn kiosk:dev. The old run script will also start the kiosk-socket server, which is not necessary.
We were currently implementing our custom Socket.IO server
kiosk-socketfor real-time communication between projector and controller devices. The reason was mainly because of type safety and we designed it for very minimal purpose. At initial time, we deployed on Fly.io, with hope that we can combined the service into a single Docker container. However, WebSockets servers uses memory, and the free plan can't handle both services in a single container. We tried to figure out the problem with our configuration, but we couldn't fix it.The quick solution at that time was to separate the WebSockets server and the website to a different provider, The website was deployed on Vercel, while the server was deployed on Fly as before. The current stack is is not easy to maintain now.
I decided to migrate this to Pusher, the BaaS that provides real-time APIs for using in both client and server. Pusher is easier to implement than what I'm thinking. It provides an easier debugging console, and it just works. Combining with Next.js Server Actions, this will be very easy to maintain, and extend any further features.
This PR is made to merge in the main branch, as the primary refactor branch is a long long way to go. The Next.js version of both PRs are matching. If the song requests system is ready we can simply rebase and continue our work!