[Discussion] Restructure CSSS site into subdomains

[jbriones1]

I wanted to make an issue here so that we can discuss potentially restructuring how URLs for the CSSS site are handled post rewrite.

TL;DR

• Split Frosh, Tech Fair, Mountain Madness and Fall Hacks into their own subdomains.
• When serving the root of these subdomains, just display the current year's event.
• Remove the portal pages, but preserve the old sites by adding something to the subdomain's URL to go to that year's page.

Current situation

Right now, on new.sfucsss.org we have pages served in two different ways: static routes and single-page application (SPA) routes. Here's a summary of what that means:

Static Routes

• Have the form /<route> (e.g. Frosh Week is new.sfucsss.org/frosh)
• Routes that use this are frosh, mountain_madness, fall_hacks, walle, profile, admin and tech_fair
• The root of these some of these routes is a portal page, which has links to each year a website was made for it (e.g. Frosh Week has links for 2012-2024)
• They match the file structure of the /var/www/html folder in the host machine (Mountain Madness is an exception, but nginx handles it separately)
• This allows the nginx configuration to be simple
• If a sub-route is not found, you receive a plain 404 page, rather than the one found in the main site. (e.g. Frosh 2011)

SPA routes

• Have the form /#<route> (e.g. About is new.sfucsss.org/#about)
• Routes that should use these are about, affiliates, common_rooms, officers, documents, events, and committees
• Uses a React hash router, which was needed based on how the nginx configuration was set up. This means we can't really use hash routing to target sections in a web page, since they're being used to route to different React routes.
• Uses pure client-side rendering, so they don't have separate HTML files and are instantiated inside the main index.html file

The short of it is that we're sort of half SPA and half static HTML. This makes it feel like some of these pages feel like you're going to a completely different site. The rewrite will be fully SPA, so there is only one index.html to serve, which makes this routing scheme incompatible with how nginx is set up right now.

Structure Proposal

I see no reason to rewrite the legacy static pages. So I propose a different structure to be implemented before the rewrite of the frontend.

Split the static sites into their own subdomains.

The pages that have portals would each have their own subdomain.

Route	Subdomain
/frosh	frosh.sfucsss.org
/mountain_madness	madness.sfucsss.org
/fall_hacks	fall-hacks.sfucsss.org
/tech_fair	tech-fair.sfucsss.org

Move other parts into the rewritten application

Some pages, like admin, profile and walle can be merged into the rewrite.

Change the currently deployed folder structure

/var/www/html
├── index.html
├── ng
│   └── // The Angular app stuff, I'll figure this part out later
├── frosh
│   ├── index.html // This would display the latest Frosh site (in our case 2025 once it's done)
│   └── 2024
│       ├── index.html // Older site, accessible with `frosh.sfucsss.org`
│       └── ... // other supporting files
// These folders would also have a similar structure to `frosh`
├── tech-fair
├── mountain-madness
└── fall-hacks

Change the nginx configuration to handle this

The current config can be seen here. As far as I am aware, I think all we'd have to do is change the configuration to be something like this:

# nginx.conf

...
server {
    server_name new.sfucsss.org;
    ...
    root /var/www/html;

    ...
    # All routes here need to lead back to the SPA. Might need to be more advanced if lazy-loading is implemented.
    # Note: no 404 page, that will handled by the SPA.
    location / {
        charset utf-8;
        try_files $uri $uri/ /index.html;
    }
}

# Need a server block for each subdomain
server {
    server_name frosh.sfucsss.org;
    ...
    root /var/www/html/frosh;

    ...
    # We'll need to make a 404.html for each subdomain.
    location / {
        charset utf-8;
        try_files $uri $uri/ $uri/index.html $uri/404.html =404;
    }
}

Required changes:

• Adding the four subdomains to the Namecheap DNS record (?)
• Have these four subdomains added to Digital Ocean (?) or just point them to the machine currently hosting new.sfucsss.org
• Restructure the folders to handle the new layout
• Change the build/deployment scripts to create the new folder structure
• Editing nginx.conf to handle the new structure
• Make sure to redirect old URLs from both the original sfucsss.org site and the current new.sfucsss.org site

Feel free to call me a 🤡

[micahdbak]

Wow, great work with this. Honestly don't think this should take too long to implement - my only request that is different from what you've shown is to prepare redirect routes in the nginx configuration for the static pages that are currently served; e.g., this one is already in the nginx.conf:

    # redirects old 2024 mountain madness requests to the new URL
    location ~ ^/events/2024/mm(/|/index.html)?$ {
	    return 301 /mountain_madness/2024/index.html;
    }

So, in the above case, you'd need to prepare the following redirects in the base new.sfucsss.org domain:

    location ~ ^/events/2024/mm(/|/index.html)?$ {
	    return 301 madness.sfucsss.org/2024/index.html;
    }

    location ~ ^/mountain_madness/2024(/|/index.html)?$ {
	    return 301 madness.sfucsss.org/2024/index.html;
    }

Hopefully that won't take too long. But IMO, you could do this just for mountain madness, as some people link them on their resumes when they've won.

[jbriones1]

Whoops, forgot to write out that part. Yeah, we'd need to handle redirecting old links to the new links. I'll add that to the list of things to do, thank you!

[alexng353]

Many of our static pages (frosh.csss.org) would be primarily static, as it's completely unnecessary for a single page to use server rendering or anything like that (prerendering is much faster). We could point something like frosh.csss.org to a cloudflare r2 bucket and host it much cheaper (free) and faster (cloudflare cdn).

[jbriones1]

• I agree on the CDN part, which we can eventually do. I'll need to talk to Puneet, as doing this might complicate how our site is set up and I'm busy with the rewrite at the moment. I've already asked him to look into Digital Ocean Spaces and see if we have access to that right now. I'm not sure if we want to open a Cloudflare account as it's one more thing to manage and our traffic isn't high enough to warrant it

• I'm exploring statically generating certain pages for the main application and leaving other pages CSR. Just for speed, the rewrite will be fully CSR and when I have time I'll try and get SSG working for the routes that need it. Eventually we can probably look at dedicating our current Digital Ocean VPS to just API calls and have a CDN serve all of our front end stuff

If it's not apparent, I'm wary about over-complicating our setup as whoever wants to work on these projects should be able to easily map out what our architecture is.