Tech stack used
About the projectFull-stack MERN website for Pulse Clan, an international gaming organization with over 500k followers across social media.
Responsible for talking with the client, coordinating with designers, to developing and deploying the website.
What the project entailed:
- • Creating a custom headless CMS to facilitate website customization for the managers, and allowing members to modify their public information and manage roster sections on the website.
- • Integrating authentication, authorization levels and restrictions within the CMS, allowing managers to add, remove and modify members and roster at will, among other features.
- • Building pages with features like carousels, accordions and animations.
- • Registering applications and contact form submissions to a database.
- • Making multiple parts of the website editable from the CMS by creating protected endpoints.
- • Integrating Discord webhooks for automatic submission of form applications to dedicated channels.
- • Implementing the Youtube API for automatic data retrieval and caching in the database.
- • Utilizing Twitch API to display information on active streamers and automatically refreshing its API credentials to ensure uninterrupted use without the need of maintenance.
- • Deploying the website on a Linux system with Nginx, MongoDB and PM2.
Contents
Landing page
Hero section
In order to reduce the time it takes for the the background video to start playing once the page loaded, a video streaming endpoint was implemented in Express which allows the client to start playing the already downloaded chunks, while it downloads the rest of the file in the background.
News and social media sections
Social media section
All of the numbers here are customizable through the CMS in order to be easily updated.
News section
The date, title, body, and image of the news section are also customizable through the CMS.
CMS form to update news
CMS form to update social media numbers
Latest videos section
The content section is divided in two parts: latest videos and currently active streamers. For the latest videos part, the Youtube API is being used to provide that data automatically, but the catch is that said API has a daily limit, so we're caching the API responses in our database in order to circumvent that limitation. And whenever new videos are uploaded and the page needs to be updated, a simple button was added on the CMS dashboard which will hit an endpoint on the server to fetch new data from Youtube and update the database.
Currently active streamers section
The Twitch API is being used to provide the currently active streamers. The full list of streamers to query from is taken from all followed users of a Twitch account created for this purpose only, meaning that if in the future the client wants to add/remove streamers who will be tracked by the website, they can simply follow/unfollow them on said account.
Also since that specific Twitch API endpoint doesn't provide the profile pictures of the active streamers, another endpoint has to be hit on our back-end in order to get the picture links for each streamer. I decided to divide these two calls into different endpoints in order to reduce initial load times for the landing page, as the front-end will only fetch the profile pictures after the page mounts and it verifies there are streamers online to display.
Additionally, the credentials for the Twitch API endpoints the server is hitting expire after certain time. So another endpoint was needed in order to check for 401 (unauthorized) responses from Twitch, and if that's the case then it'll use a refresh token in order to generate new valid credentials, then update the environment variables both in the file and on runtime for future requests.
Application and contact pages
Pulse Clan has multiple roles open for recruiting, and each role has specific form fields and different requirements, so conditional rendering came in handy.
Different fields and descriptions being rendered based on the selected applicant role
Once the applicant fills the form and sends it, the server takes the request and puts it in the database. Additionally by request of the client, each application is sent automatically to Discord channels for easier viewing. Discord makes this possible with their webhook implementation.
Example of application being received on Discord via the Webhook implementation
Each applicant role has a dedicated Webhook URL. This results in multiple Discord channels, where each channel receives applicant submissions for one designated role only.
This process is very similar for the Contact page.
Contact page
Also both contact submissions and applications can be reviewed and deleted from the CMS
Received application seen from the CMS
Roster page
On the roster page each member displayed has an account registered where they can log in and alter all of their information displayed here such as their name, picture, modify their social media links and more. Also an expand / collapse button was added in order to avoid roster sections with too many members from making the page too cluttered.
Expand / Collapse functionality to show all members of a roster section
Form on the CMS where Pulse Clan members can alter their roster information
Also, the “Roster Leads” shown on the website can add / remove / edit members from their respective section, edit the order in which the members appear on that section, and alter each members' information for them.
Members from upper management can additionally promote / demote members into and out of management positions, and move members from one roster section to another.
Demo showing the member managing page
Faq and Wallpaper pages
The Wallpaper and Faq pages are also consuming customizable data from our database.
FAQ page
Wallpapers page
Wallpaper managing page on CMS
Faq managing page on CMS
Content management system
There are many different roles within Pulse Clan with different levels of authorization, so i made a quick hierarchy graph for the CMS while in discussions with them.
Roster authorization hierarchy on CMS
CMS dashboard. Colored dots indicate which pages each user can access based on their role.
This is one of the instances where the rendered layout and functionality are dictated by what authorization type the user has.
On the “View applications” page, division leads can only see applications pertinent to their division (i.e the lead designer can only see designer applications and so on). Similarly, on the “Manage members” page, the division leads can only register new members pertinent to their own roster section on the website (i.e the lead editor can only add members to the editor roster and so on), and they can't assign or modify their management roles or anyone else's.
I've provided a general overview of this section since all other pages and endpoints have been covered in the sections above separately.
Setting up and deploying the server
We compared multiple options and services to host the website on, but ultimately decided on a Virtual Private Server with DigitalOcean, which provided all the flexibility that was needed.
Nginx is being used as the reverse proxy, PM2 to maintain the node process alive, and configured it to automatically start in case of system reboots. Lastly, a MongoDB instance was created for the backend to connect to.
Additionally Cloudflare was implemented as a layer of security and also to get some analytics.