OrbitLens Devlog #13: fixing deployment bugs 😭😭

Before i continue with this devlog, let me start by saying that modern security rules are the worst. Like istg, why do they have to be so strict? Anyway, you’ll see what i mean by that down below. THis session was all about fixing the deployment bugs. I was almost done and then these f bugs ruined it. This devlog has only abt 30 mins logged because i had the help of ai to fix this because this was way way out of my expertise. Here are the changes. I used ai for this devlog though cus i didn’t understand what it did (but i only used it for htis devlog):

Problem 1: The [UNSUPPORTED_FEATURE] Vite Crash

My very first Vercel build crashed immediately with a “Top-level await is currently not supported with the ‘iife’ output format” error. Apparently, the satellite.js library I use for SGP4 orbital propagation runs heavy calculations using Web Workers and WebAssembly. By default, Vite tries to bundle everything into an older iife format for maximum browser compatibility, which completely choked on the newer await feature inside the worker file.

I fixed this (with the help of ai) by explicitly telling Vite’s internal bundler (Rolldown) to output modern ES modules for both the main thread and the background workers. I created a vite.config.js file and updated the configuration (see vite.config.js in the github repo)

Problem 2: 404 Missing 3D Models

After fixing the build, the site successfully deployed, but my 3D models (like the ISS and Hubble) and Earth textures threw 404 Not Found errors in the console. Because I was loading these assets while the app was running in my Three.js code using string paths (e.g., ‘/models/iss.glb’), Vite didn’t know they existed and simply excluded them from the final production build.

I moved my models and textures folders into Vite’s public directory. Anything placed in the public folder gets copied exactly as is to the root of the final build.

This bug wasn’t too bad but the next one was absolute hell.

Problem 3: API, Cloudflare and CORS block

This was the hardest part. Orbit Lens fetches live Two-Line Element (TLE) data for over 16,000 satellites directly from CelesTrak. It worked perfectly when i hosted it locally, but on Vercel, the browser instantly threw a 403 Forbidden error. CelesTrak uses Cloudflare to prevent automated scraping. When Cloudflare saw an Origin header coming from a deployed Vercel frontend instead of an normaly IP like my computer’s, it blocked the connection.

Attempts to use public proxies (like allorigins) resulted in 408 Request Timeout errors because the multiple mb big satellite data took too long to transfer.

To fix this, I used Vercel’s Native Rewrites (i have no idea how to use this so i asked ai to do it for me). “I” ;) created a vercel.json file in the root directory to act as a silent backend proxy.

By fetching from my own local route (/api/celestrak), the browser doesn’t trigger CORS security. Vercel’s backend intercepts the request, strips the frontend Origin header that was triggering the firewall, and routes the raw data back to the application.

This worked! And the website is finally live and i am about to ship the project!