CORS is dumb. CORS is here to stay. CORS has a bit of usefulness. As my daughter opined recently, cry me a river, build a bridge, and get over it.

After spending days on it, I now have a five minute fix for CORS in a dev environment where the frontend is split from the backend during development.

GIVEN:

  • a server that serves up your RESTful API using backend data
  • that same server, serving up your nicely bundled front end, after you bake it for prod
  • https in prod, and http in dev
  • a modern front end development environment that maximizes your local web development speed while also bundling it tight for prod ( 💕 Vite 💕 )

You may have been sailing along with that sweet setup for a while now. But then one day, CORS arrives in your neighborhood. Perhaps you realize your Node front end can now use native fetch(), how nice (at first). Or your browser just got updated and all of a sudden it’s very unhappy serving your JWT tokens. Any way you get there, you will probably hit CORS issues. They tell you you are a bad person for trying to reach your backend from your frontend. Bad dev!

The problem is that is actually now blocked as a cross-site request. This blockage is now ubiquitous. How else can you still get to your favorite awful monster sites if they are sideloading dozens of malware ads? Why should megasite be responsible for the ads they serve? Let the browser block them! We need to protect the sheeple!! But i digress…

To fix your CORS issues, quickly, you simply add proxying to your Vite environment. The proxy takes all your backend calls, sends them off, and when they return, gently stuffs all the weird painful CORS headers you need in the response to keep your frontend from having a seizure.

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  server: {
    // For back end calls, make sure to use the API prefix.
    // Our vite dev environment will proxy those calls to the back end,
    // and return them to us, with fetch's xss concerns disabled via CORS:
    //    front -> proxy -> back -> proxy -> (ADD CORS) -> front
    proxy: {
      '/api': {
        'target': 'http://backend:8080',
        changeOrigin: true,
      },
    },
    port: 8008,
  },
})

Beautiful. In addition to that, if you can just slightly touch your server side cookie header to make it fit the CORS rulebook, you can get all that cross-site protection in prod, and never deal with a CORS issue in local dev again:

if (dev_environment) {
    cookie_header += " SameSite=Lax;";
  } else {
    cookie_header += " Secure; SameSite=Strict;";
  }

The internet has officially crossed over from a source of generally good information to a floating island landfill of outdated plastic shrapnel.

Just trying to find “today’s” best-practice for simply fetching data in a React app turns into an exhausting ritual of filtering for hours. Thank goodness for subreddit and stack overflow ratings metadata, and this answer in particular, and tools like npmtrends.

No one can ever say that software development is boring…

A better Trader has been a work-in-progress project of mine for a very long time. The web UI was done in vanilla javascript, with old school imports, and PHP-style server-generated html, then added jQuery, then bootstrap, then started removing jQuery, then moved towards more-static html with JSON payloads for the data, then pined for better node imports, then then then. You get the point.

I went too long without a rewrite, so I recently became a weekend warrior skeletoning up the next gen web ui. Parts include:

  • Vite due to its blazing hot-loading, tree-shaking, polyfilling goodness
  • React because it’s good enough and gets the job done
  • Bootstrap because I won’t have time to finish the mobile apps for a while

For my UIs, D3 is the most important library there is. So the skeleton is based on responsively displaying a handful of some of Mike Bostock’s greatest hits (imho). This was quite important to me because D3 examples have been somewhat obfuscated when they were migrated to Observables notebooks. The skeleton makes it much easier for me to quickly get working D3 examples by copying Mike’s Observables code into a cozy little container with all the bells and whistles in place.

Let me know what you think of it.

Reddit | Live Demo | GitLab | GitHub | Wiki

Bash is the worst pile of anti-patterns and hacked up bullshit, but what would you expect from something that’s been our emergency-room band-aid for as long as we’ve been alive? This is just a reminder, for your career’s sake, to NOT make it one of your “specialty languages”. Learn what you have to. And double down on a modern, sane scripting language. I’ve tooled up node to do all things command-line, I recommend you do the same – but even writing little Java or C++ command-line apps is better than letting bash poison your brain! Just say no. And some day, our great-great-grandchildren will have a replacement. No, not another sh variant. A true sane modern programming language. okbyeeee!

Hate of the day: I love how [rm -f ] “fails” (non-zero error code) but [mkdir -p …] “succeeds”, and there is no [mv -f …]. The Unix philosophy: do one thing, and do it well, but always slightly differently than anyone else would have done it. Sure it’s bizarre bazaar chaos, but it’s “beautiful”. Ummmm…. no, fuck you, I don’t want to memorize your chaos.

UPDATE: Dude. In my defense I was in pain and jacked on meds when I wrote this, haha. Step away from the oxy, take less Adderall… calm ye self down. “Whatever Works”.

UPDATE 2: Yeah, the horror is real. Yet another damning example of why, for your career’s sake, you should focus on a real scripting language and not (ba)sh’s arbitrary stupidity.

I spent this morning exploring available tech to address this goal:

Add a bigdata database to my application, to archive older data out of the realtime local model

This is for my stock app, which deals with realtime in-memory data during market hours, with a delayed-write to local storage.  At the end of the day, it can then archive most of the data collected during market hours.

Because I have not achieved “success” in life yet, at least enough to allow me to pursue my larger goals uninhibited, I have to be very careful about how I apply my limited resources.  To be more precise:

  • Follow patterns that are as simple as possible (but no less), and sustainable into the next decade.
  • For my projects, limit languages, libraries and tools to those that are
    • well maintained
    • solve difficult problems more elegantly than I could solve with a medium level of effort

The result of today’s philosophically-informed research:

  • The primary languages of my software projects should be Javascript and C++
  • All data should be defined by JSON schema that is used to generate code, via quicktype
  • Long-term libraries and tools include boost, jquery, bootstrap, accounting.js, moment.js, nlohmann::json, sqlite, postgres

Note that using quicktype with nlohmann::json is an elegant way to effectively get C++ reflection.  Once you serialize an object to JSON you can walk all its fields.  Then you can do things like automatically build SQL queries for your classes based on the JSON schema.  Beautiful.

PS. I avoided spotify-json, StaticJson/autojsoncxx, Google Prototype Buffers, Code Synthesis’s ODB, the sqlite JSON1 Extension, C++ reflection libraries like RTTR, lots of code from Stiffstream and Chilkat, etc. because while they are all brilliant and compelling, they bring extra weight.  The world keeps churning though, so keep searching.  Also, there are cases where my choices do not fit, most obviously being cross-platform mobile apps, which will have to be saved for another post… 🙂