Forem: Lucas Lachance

MERN is not your god

Lucas Lachance — Mon, 07 Apr 2025 16:45:19 +0000

This article addresses a very specific conversation that I find myself having repeatedly with beginners who were suggested that they should learn web development in the MERN stack.

I want to address it because there's a very real dumb reason why MERN is such a common suggestion, and why I'm sort of angry about it: it's because you can say MERN out loud, and remember it written, since it looks like a word more than any other common tech stack.

We humans, we love our acronyms, we love to make them sound like words, and we have generally lost the ability to generalize the full stack technologies by shoving it in the MERN acronym which is often literally used, not metaphorically.

The Meaning of MERN

Let's first explore what MERN actually means:

M stands for MongoDB, a document database that was very popular when the acronym was coined.
E is for Express, which for decades was the defacto HTTP server library you wanted to use in node.
R is React, the most popular front-end client-side rendering, one used by the industry, and still very relevant.
N doesn't even relate to a specific part of the stack but rather just "node".

This means that the stack is really just "mongo + express + react", which is not a bad stack per-se.

The Alternatives

My point, though, is that it's just one single variation out of so many possibilities. So for each of those 4 parts, let's first explore just specific changes we can make.

Mongo can be about 2 dozen different databases depending on your needs. MySQL, Postgres, Oracle, SQLite, etc. Not to mention hosted/distributed systems like Firestore, Cloudflare and AWS offerings.
Express has much better, more modern, more solid alternatives. Fastify first of all, but also more specific depending on your needs. Hono, Nest, Koa, strapi, etc.
React also has alternatives like Vue, SolidJS, Angular, Svelte and a slew of other more minor libraries.
Even Node has alternatives: Deno and Bun, for example, are well known, and Bun also includes its own http server and build tools, and it's more performant.

But does anyone want to remember PFSD (Postgres, Fastify, Svelte, Deno), or ONVB (Oracle, Nest, Vue, Bun)? What about SSSN (SQLite, Strapi, Solid, Node), why is that not valid?

My point here is that there are hundreds of possible combinations of all of these alternatives, all equally valid, all equally potentially useful for your project, or appropriate for your needs.

The not-even-acronyms

Now, what about not even doing this as a completely separate stack, but an actually integrated solution that's all in one? What if we chose something a lot more modern that was actually built for generating frontends quickly, effectively, in a short period of time?

On the stage, we now have systems like NextJS, Astro, Tanstack Start, and Remix. All based on their own specific configuration and libraries, but all doing the same thing, in terms of pure JavaScript stacks: they add the backend directly into your project, using what is called "server-side rendering". This is done via very different methods for each, sometimes using loader methods, sometimes with server functions, or api routes, etc.

These full stack libraries would usually cover both the front-end and back-end libraries (express+react would be replaced by Next or Remix), and the 4 I named above are literally just ones I know from the React world - every front-end library has its list of possible full stack frameworks.

Each of those frameworks also can connect to any database or even other APIs and backends, they can do caching and SEO and so many things, that would be much harder, if not impossible, using separate React + Express stacks.

Not Industry Standard

Some might claim that the MERN stack is somehow an industry standard, potentially citing numbers about React being the most popular front-end JavaScript framework (it is), Node being a good backend language (it is), MongoDB being very popular in node circles (it is) and Express being the most used node http server (it is!). However, those separate facts about popularity are pure cherry picking.

They all stem from a forced choice of node as an engine, and JavaScript as a language, and while JS is in fact the most popular browser language (by virtue of it being the ONLY browser language standing for decades), it is by no means the most popular backend language, a position which is held by PHP. MongoDB is the most popular node database but the actual most popular databases are Oracle, followed by MySQL and then Microsoft SQL server. React is the most popular JavaScript framework but it's overshadowed by a lot of other frameworks in other languages : you have Django in python, Laravel for PHP, etc.

All that being said, the cherry picking is very strongly biased towards Node and JavaScript. Again, this isn't an invalid combination of technology, but it is not, in any way, "the industry standard" or even close to being the most popular.

So what do I choose, then?

That is a great question, thank you for asking! And unfortunately, the answer is that it doesn't matter, or that it depends. But here's a joyful bit of information, however: even if you do decide to go with MERN because there's a slew of popular tutorials and videos and courses, none of what you learn there will be completely lost if you move to a different choice of technology in the future. Concepts of rendering, APIs, databases, security, front-end dynamic pages... It's all good, it's all useful, it's all something you will be using in the future.

So do what you like, learn what you can, but just be willing to learn new things in the future, as you define yourself in your development journey.

Interact with this post!

I would love to hear your thoughts on what stack you've learned with (whether it's JavaScript or not!), and if you continued in that stack in projects, at work, etc. Did changing to a different stack or technology take time to adapt? How did you cope? Let me know in the comments!

How to make an async constructor in Javascript?

Lucas Lachance — Wed, 20 Nov 2024 01:10:53 +0000

You're here because you have a question : how do I await a Class constructor? How do I make the constructor Async???

And the answer, I'm sorry, is that you literally can't. A constructor for a class in Javascript must be synchronous. However, there are alternatives in implementations that can help you do what you want. Let's explore it!

You probably want this because you need to initialize something in the constructor and have it available in any call you make to the class. A good example of this would be connecting to a database and waiting for that connection to be established before accepting any queries.

The pattern for this is really simple! Let's start with an example database connector, using the sqlite module on npm:

import sqlite3 from 'sqlite3';
import { open } from 'sqlite';

To open this database, you need to await the open function. I asked my friendly AI code helper to come up with a "DBConnector" class and it actually got the common pattern right - the one you'll see everywhere:

class DBConnector {
  constructor() {
    this.db = null;
  }

  async connect() {
    this.db = await open({
      filename: './database.sqlite',
      driver: sqlite3.Database,
    });
  }

  async disconnect() {
    await this.db.close();
  }

  async query(sql, params) {
    return this.db.all(sql, params);
  }
}

// exporting a singleton so there's only one connection
export default new DBConnector();

You'd call this simply by importing it and then awaiting its calls:

import db from './dbconnector.js';

await db.connect();
await db.query('GET * FROM test');

So now, the problem here of course, is that not only do you need to manually call myDB.connect() in order to start the connection, you also can't guarantee that the query call will work, say, if a different file does a query as your main file is connecting.

Sure, the main file can await db.connect(); , but anything else importing this module won't have any way to do that. And you might think, "ok but I can call await db.connect(); in other files too, right?" and you can... but that will reconnect to the database every time, which can be slow depending on what you're using.

The Deferred Pattern

The pattern that I came up with involves a little bit more complexity, but it remains simple and ensures that every little piece of code - and yourself - are all happy. And I did in fact come up with it on my own, even if it's actually known to others. They're called "Deferred" promises.

Here's how it works.

// still have our imports
import sqlite3 from 'sqlite3';
import { open } from 'sqlite';

// Create the class
class DBConnector {
  // We'll need these private properties:
  #db;
  #defer;
  #resolve;
  #reject;
  // Then we make our constructor:
  constructor() {

    // We create a new promise and store its resolve and reject
    // functions in the class instance properties.
    this.#defer = new Promise((res, rej) => {
      // this is the magic, right here, basically.
      this.#resolve = res;
      this.#reject = rej;
    });

    // So now, this.#defer is a promise! We can await it in other methods.
    // Now we call our this.connect *internally* and automatically.
    this.connect();
  }

  async connect() {
    try {
      this.#db = await open({
        filename: `./database.sqlite`,
        driver: sqlite3.Database,
      });
      // Now that we resolve the promise, any other method that awaits
      // this.#defer will continue executing.
      this.#resolve();
    } catch (err) {
      // in case of error we can of course reject the promise
      // any code using it would then throw an error.
      this.#reject(err);
    }
  }

  async disconnect() {
    // on any action, we just await this.#defer
    await this.#defer;
    await this.#db.close();
  }

  async query(sql, params) {
    // Even in queries, it works perfectly fine!
    await this.#defer;
    // Here we KNOW that this.#db is already initialized.
    return this.#db.all(sql, params);
  }
}

export default new DBConnector();

Now ain't that a charming little pattern? It is, of course, more code that a basic example, but personally, I think it definitely raises the bar on boilerplate code for classes that are mostly based on async methods.

Let's see how to use it!

import db from './dbconnector.js';

// it's already initialized... just use it!
await db.query('GET * FROM test');
// and it just works :D

Bonus: I made a library!

I'm using this pattern so often that in the end, I decided to make a really quick & dirty library and publish it on NPM. It's called deferrals and it's pretty trivial to use (it was pretty trivial to write, too, once I knew the pattern).

Let's remake the above example using deferrals instead.

import sqlite3 from "sqlite3";
import { open } from "sqlite";
// We import the library, of course.
import { makeDefer, waitForDefer, resolveDefer, rejectDefer } from 'deferrals';

class DBConnector {
  #db;
  // We don't need the private properties anymore.
  constructor() {
    // Our constructor is a bit simpler.
    makeDefer('db');
    // We still call our connect method.
    this.connect();
  }

  async connect() {
    try {
      this.#db = await open({
        filename: `./database.sqlite`,
        driver: sqlite3.Database,
      });
      // We resolve the defer here
      resolveDefer('db');
    } catch (err) {
      // or we reject it here.
      rejectDefer(err);
    }
  }

  async disconnect() {
    // We still need to await something: the defer.
    await waitForDefer('db');
    await this.#db.close();
  }

  async query(sql, params) {
    await waitForDefer('db');
    return this.#db.all(sql, params);
  }
}

export default new DBConnector();

The 'db' string is basically any string name that you want to give to the defer, and you can create as many as you like. Obviously you don't need this library, but personally I think it's quite nice, y'know?

I hope you learned a really useful pattern here, and I'm glad to have been part of your learning journey today <3

React Components - just a function that returns html

Lucas Lachance — Tue, 03 Sep 2024 17:12:02 +0000

Let me make a grossly oversimplified statement that can help beginners understand React without diving too deeply into things like the "render loop" and the "shadow dom". If you just want to get the very basics of React components please read on. If you understand React internals, you should probably skip this for your own sanity.

The statement is :

A React Component is simply a function that returns HTML.

This oversimplification is important to understand so many things in React, I think it's a mantra that should be integrated by any beginner. So let's repeat again :

A React Component is simply a function that returns HTML.

Let's take for example this extremely simple React app which is a button with a counter:

import { useState } from 'react'

function App() {
  const [count, setCount] = useState(0)

  return (
    <button onClick={() => setCount((count) => count + 1)}>
      count is {count}
    </button>
  )
}

export default App

As you can see, App is a function. So that part of the statement is true as-is.

The second part of my statement is almost true : "it returns HTML" is technically false, because in fact there's a bunch of things that happens with the JSX ("almost html") returned by the component. But if we imagine for a second this is just HTML, then you can just think : this html is being put inside the webpage.

Is that simple enough? Good! I knew you would get it.

I'll call the return of a component JSX from now on because I've triggered enough people already.

But there's a 3rd part of the sentence that I omitted until now. David's secret chord as it were, which will definitely please the Lord.

A React Component is simply a function that runs every time its state or props change which returns JSX.

This new part explains exactly how React is "reactive", the core of its idea. When the state changes, the component renders again. That means, in simple terms, that the function runs again, and returns updated JSX.

This means that when setCount is called, the component function runs again, and this time, const [count, setCount] = useState(0); is going to ignore the default 0 value, and use the new state value instead. Which is why when it reaches the JSX, that value of count is put in the JSX, and that then goes to update the webpage.

So why does this matter?

The entire reason I wrote this short article is to explain one thing : "state updates are asynchronous". It's a common misunderstanding of React. Let's change the example code for the counter a little bit to demonstrate:

import { useState } from 'react'

function App() {
  const [count, setCount] = useState(0)

  const handleClick = () => {
    console.log(count);  
    setCount(count + 1);
    console.log(count);
  }
  return (
    <button onClick={handleClick}>
      count is {count}
    </button>
  )
}

export default App

So what's going to happen here? What will be the output of the console.log before and what will it be after?

If you said "0, then 1" on the first click... you forgot something extremely basic about javascript: You defined count with CONST. How would the value possibly change on a const??? So the answer is, they're both going to be 0. Then they're both going to be 1.

So how do you get the new value of a state within a function in your component? Well, simply, you don't. Rather than doing setCount(count + 1) what you do instead is const newCount = count + 1 and then you can console.log(newcount) and also setCount(newCount).

And what if you are doing some complex operation in the state and you can't do it outside because it's a functional setstate? In that case, you can rely on the new state via a useEffect:

import { useEffect, useState } from 'react'

function App() {
  const [count, setCount] = useState(0)

  const handleClick = () => { 
    setCount(count + 1);
  }

  useEffect(() => {
    console.log("new count value : ", count);
  , [count]);

  return (
    <button onClick={handleClick}>
      count is {count}
    </button>
  )
}

export default App

Since the change in state triggers the component to render again and run the function, useEffect will be checked. And since it has a dependency on the count state which changed, it'll execute the body of the useEffect, and log the change!

Hopefully this clarifies the very basic idea:

A React Component is only a function that runs when its state or props change, and returns JSX.

Stop using create-react-app

Lucas Lachance — Sat, 24 Aug 2024 15:19:32 +0000

This is a cry for help. I beg you, I am on my knees, weeping, imploring you...

STOP USING CREATE-REACT-APP

Ok so if you don't want to read the whole article let me tell you what's what in simple terms (TL;DR):

create-react-app stopped being updated over 2 years ago
react-scripts which CRA depends on, stopped being updated over 2 years ago
CRA is slow compared to modern alternatives
webpack is very slow compared to modern alternatives

What's the solution? In one word: Vite.

No Longer Updated

The last time the create-react-app package was updated was on April 12 2022 at 1:33 EDT, which by all accounts as of writing this, is over 2 years ago. And while some things can go years without updating, it's important to realize that CRA itself has a lot of dependencies which have not been updated, and have suffered from vulnerabilities. When you run npx create-react-app you'll get the following result:

8 vulnerabilities (2 moderate, 6 high)

The Facebook/React team have no intention at this point of fixing any dependency, as made clear by the fact that create-react-app is no longer updated and they now recommend other tools (see further down).

React-Scripts

react-scripts is the actual dependency used by CRA when running your dev server, with npm run dev and when building with npm run build. And just like CRA, its last update was in 2022, in fact, in the exact same commit as CRA's last update. react-scripts has a ton of dependencies that have since updated and patched, but of course, react-scripts won't update.

Webpack

I don't want to bash webpack here, but I will say this : webpack is slow as shit, compared to Vite. It's not as configurable as the alternative either, even if it seems to have plenty of a plugin ecosystem, it's already been overshadowed by what Vite offers.

The solution: Vite

Vite (pronounced somewhere between vit and veet since it's the French word for "Fast") is a direct replacement for create-react-app's features, in that it offers a fully configurable development environment with a hot reload server and plenty of plugins.

Not only is Vite configurable, it's blazing fast and it also supports basically all front-end frameworks. That is to say, you can create a Vite project for React, Svelte, Solid, Vue, Lit, Quik, and Angular. It even lets you create vanillajs applications but with builder dependencies such as tailwind, sass, etc.

Personal anecdote time : When I first learned of Vite in a previous job, I took half a day to convert a project that was using react-scripts into Vite. It took half a day because it was a pretty massive project, I was a Junior level dev, and I was new to a lot of it. I knew it was worth it, and I was right : When saving a file and waiting for the hot reload in the browser, the waiting time went straight down from 6 MINUTES to LESS THAN A SECOND. Yes, you're reading that right, I didn't make a typo between "minutes" and "seconds". The initial build time also was reduced to about 20 seconds, because it was still a pretty massive application.

So when I say "blazing fast" I actually do mean it, it is not a hyperbole or exaggeration. And I'm going to do it again, and again, in every project I work on still using react-scripts.

So, have I convinced you? Go right ahead and get started with Vite today.

How to convert

Ok so you might be wondering if there's going to be a whole lot of changes to make in your code, right? Well... not really. The truth of the matter is that the vast majority of your changes happen at the configuration and root level of the app.

Converting a CRA app into a Vite one boils down to:

From a new folder (not your existing app), run npm create vite@latest
Select React as a framework
Choose Javascript + SWC or Typescript + SWC depending on whether you use TS. (SWC makes the build process even faster than not using it)
Let it generate the scaffold project
Copy over all your components and subfolders (EXCEPT FOR App.js and index.js)
Modify the main.jsx and App.jsx to re-introduce your configuration including react-router, your contexts, etc
Add any required plugins into vite.config.js
Adjust for errors/issues

Obviously the last 3 steps are where the majority of your work will go. Depending on the complexity of your existing application, finding the correct plugin and configuration might take a bit of time, and adjusting for errors you might encounter could take some time. But in the end, I repeat again that it will absolutely be worth the effort.

What if I need help?

If you've reached this far and you've decided to switch but are afraid of having to deal with problems and errors, I invite you to join me in the #javascript channel of The Programmer's Hangout on Discord. I hang out there as eslachance (usually nicknamed Alterion), don't hesitate to ping me for help and mention this dev.to article. The more official Reactiflux server is also at your disposal.

If I'm not available there are plenty of people in TPH and Reactiflux that can help you, some that I've directly converted to Vite!

A Conspiracy Theory

Stop reading here if you don't care about drama, conspiracy theories, and rants. I'm about to go deep into a rabbit hole which you're absolutely not forced to follow me into - Vite's cool as it is, it's your answer, you may disengage for the rest ;)

The question I asked myself often is : Why did the React team bury the mention of Vite deep within a collapsed "Deep Dive" block on the Start a New Project page of their docs. Why does the mention of Vite feel very brushed off, just a comment, a maybe not important note at the very end of a wall of text most people won't read?

What I think should have happened is that instead of this massive hidden wall of text casually handing out a mention of Vite along with Parcel... it should have been a paragraph at the top level of the page, before any mention of NextJS and other full-stack frameworks.

The page should have noted that create-react-app is deprecated (it makes NO mention of CRA at all!) and that its direct, suggested replacement for a front-end-only project was to use Vite.

Instead, what the documentation does is suggest to use a "Production-grade React framework", and starts with NextJS as the main one, the first one.

Here's where the conspiracy comes in. NextJS is made by Vercel, who also offers hosting that is specifically compatible with NextJS, which is not hostable unless you are on a service that supports it. Even if the docs say All of the frameworks we recommend are open source with active communities for support, and can be deployed to your own server or a hosting provider , it fails to mention that the hosting or server requires nodejs to be running for this to work.

I am aware of NextJS's "static output" but that doesn't support most of its features and more importantly, isn't an SPA but rather a Static Site Generator where every page is reloaded, just what React avoids happening.

Now... Vercel is a large company, and they have been infiltrating themselves into the React ecosystem. As one reddit post points out:

"The React team is currently working primarily with Vercel to "research, develop, integrate, and test framework-agnostic bleeding-edge React features like React Server Components". The React docs website is built on NextJs."
"Vercel has been more aggressive in hiring and sponsoring React core team members."

Now... it doesn't source these facts, so take it with a grain of salt (I haven't been able to seriously find any source for these on my own. that's why it's a conspiracy theory and not an affirmation of facts). But it sure makes me wonder just how much money Vercel has been pumping into the React team, how many members of that team it stole and how that affected the React docs and the team itself, either directly or through "my colleague used to work here and now is at Vercel and they keep telling me Next is great".

If you have any solid information on the subject I would love to hear from you in private, do a little bit of investigative journalism, and write up a real article or video on the matter. But until then, it'll remain just real life conspiracy theory I'll continue to believe in until an official Facebook/React team member explains to me why the hell Vite isn't put front and center in their docs.

That's all, folks!

EDIT 2025-01-19 : More Info

Ok so I have actually learned a few things regarding the above conspiracy which does go against it, somewhat. This is all second-hand information but it does come from trusted sources in the React ecosystem.

The idea is that the React team, for the last 2 years, have been thinking about how to specifically handle either a CRA update or a proper graceful deprecation.

On the one hand, updating CRA, for the React team, would mean supporting more than just a standard webpack "front-end only" react scaffold, since they're now neck-deep in pushing Server Components down everyone's gullet (I'm opinionated about this and against it as you might tell). So this would mean making a CLI that supports multiple methods of creating such apps, a bit like Vite does, but obviously only for the React ecosystem, and that takes planning and time.

On the other hand, deprecating it means guiding people to different places and different tools that replaces it. Now, it's not necessarily that they don't like Vite, it's that they want to give everyone a fair shake when talking about that deprecation. One specific example : Parcel which wants to be a competing system to vite (and, imho, failing miserably at it, sorry Devon), and so wants a seat at the table of "hey now that CRA doesn't work, use THIS instead". The React team would want to list some tools, but at the same time, probably that's a list that would eventually need to be upgraded so there's definitely a lot of planning required here, too.

All in all, if all this is correct (and I have no actual reason to doubt it at this point) then there's still the problem of the React team just... missing their window of opportunity. The bigger issue at hand is that CRA isn't just deprecated now, it's completely broken, since the release of React 19, since CRA doesn't support it. So all this time wasted on thinking about it because they didn't want to lose the exposure and "brand recognition" of create-react-app means that now, create-react-app is broken and will continue to bleed usage as we all continue to tell people not to use it since vitejs works perfectly fine.

React team, you missed your window. Please admit defeat or make a decision already.

Fixing CORS in your SPA

Lucas Lachance — Mon, 12 Aug 2024 18:24:45 +0000

An extremely common issue that plagues new web developers trying to establish communication between their front-end project and a backend or API, is the almighty CORS error. You know what I'm talking about, it's the one that looks like this:

Access to fetch at 'http://localhost:3000/' from origin 'http://localhost:5173' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

What others say

When doing research on this, you'll probably find a lot of different potential solutions, including adding "credentials": "include" in your request (WRONG!), "mode": "no-cors" (WRONG AGAIN!), or having to modify your backend to add CORS headers such as app.use(cors()) in express (functional, but not always possible or ideal).

I'm here to tell you there's a better way. An easier way. One that will make a lot of sense for a lot of people, especially those getting started on simple projects.

Not an absolute solution

I want to clarify that I'm here to address a very particular situation that does not apply to every single case out there. This only applies if you are:

Using a front-end javascript-based Single-Page-Application (SPA), such as: React, Vue, Svelte, SolidJS, Angular, Astro, or any purely frontend SPA, OR you are using vanilla javascript but with a development server like Vite.

That is it. I will explain examples using both Vite as well as the (very deprecated and dead) create-react-app, but the concept should apply to any frontend framework with a development server.

Note: full-stack frameworks such as Next, Nuxt, Solid-Start, etc, won't need this unless you're accessing a secondary backend, but this should be done via the actual backend provided by that framework so is beyond the scope of this article.

Why the error happens

Some optional background information, you can skip this if you only want a solution.

The TL;DR of the CORS error is that a backend server made for a frontend can (and should) only allow for http queries made by a known frontend from a known URL. That is to say, if I'm the owner of my-domain-name.com , I have a backend that's running on my-domain-name.com/api or api.my-domain-name.com , I want to only accept requests made from my-domain-name.com. This prevents any request from other domain names.

To explain a very clear, unambiguous example: Let's say you're bankofamerica.com. You do not want someone to register bankofamerlca.com and be able to show a proper login screen, where people would enter their real Bank of America login and password, check them against your backend, before stealing them... right? That's what CORS is mostly for.

It's also why CORS errors don't affect requests made from another server, or through a proxy : because it's meant to protect a normal end user at home, with no technical know-how, from being a victim of very simple phishing attempts. That can still happen, of course, but it's part of that ongoing battle against scammers and thieves.

But, you might actually want to allow for requests to be made from more than one origin (if you own more than one domain, for example) or from any origin (if you have a public-facing API or service anyone can access). That's why CORS is configurable via the Access-Control-Allow-Origin header, and why adding app.use(cors()) in express works, for example.

But enough background, let's go to the solution.

The solution, in development

Statistically speaking, you're probably doing your development in React, so let's address the most popular option first.

React developers will be using one of the two following development environments.

Create-React-App

If you are using create-react-app, consider moving to Vite as soon as you can, since CRA is deprecated. However, here's the solution anyways because I'm not your mother and I don't make your choices.

Source documentation

To add a proxy, you can simply open your package.json and add the following line at the top level of the json structure:

"proxy": "http://localhost:3000",

You must obviously change the localhost address to your backend URL. You also need to modify all your HTTP requests made with fetch() or axios to start with /api.

For example if you were previously calling http://localhost:3000/login , you would change that to /api/login. The backend would then need to respond do the /login route in this case.

Advanced Configuration needs to be done via the src/setupProxy.js file but should not be required in this case. See more documentation on the subject.

Vite

Source Documentation

A number of frontend frameworks now rely on Vite to provide a fast and efficient development environment with hot module reload (that means, updating the page when you save a file!). Whether it's React, Vue, Svelte, Solid, or even vanilla javascript, you'll find a boilerplate available by running npm create vite@latest and choosing your framework and other options.

Once you have your Vite project running, setting up the proxy is as easy as updating vite.config.js to add the proxy configuration, as so:

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/api': 'http://localhost:3000',
    },
  },
});

You only need the proxy line in the server object here - the rest of your configuration does not need to match the above. Note that in the default case, requests made to the backend will be prepended with /api, meaning if you call /api/login , the backend call that will be made will be on http://localhost:3000/api/login.

So that means all your backend calls go from something like fetch("http://localhost:3000/endpoint") to fetch("/api/endpoint").

Advanced Configuration is necessary to remove the `/api` prefix in the calls

You can use a slightly more advanced configuration on Vite to remove the /api prefix:

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
  },
});

As you can see, it's not that hard, just a simple regex replace.

But what about PRODUCTION???

Some of you might be wondering what happens when you push your code to production, as in, when you deploy it to your hosting. There are obviously a large number of possible situations that might arise, but let me cover a few. Before that, I want to clear out a misconception.

Your proxy configuration and development server are not relevant to production or deployment to a hosting service. That is to say, your development server is just that, development.

The important thing to understand is that invariable in SPAs, to create your production build, you must run a command like npm run build, which creates a new folder in your project called build/ or output/. This will contain a small number of files in html, js, and css format, and that is your static production output. From here, this is where the solutions stem from.

Solution 1: Backend Serves Static Files

The very first, simplest, and probably most valid solution for you, is to serve the build folder files directly from your existing backend server. This obviously only relates if you're the one making the backend, and it's why I noted that using app.use(cors()) wasn't the best way... Because if you simply serve your static files from the backend, you can skip the whole CORS problem in production too!

For example, if you have an express.js backend, you could simply copy over your build folder into the express project, and use the following line:

app.use(express.static('build'))

// your other routes here!
app.get('/api/login', (req, res) => {});
// etc

Yes, that would work perfectly well. It does imply you copy over the files all the time however. The express docs indicate you can also call another folder but it's a bit more complex, so I won't go into that.

This solution works with koa, fastify, hono, and probably any other nodejs backend, they each have an equivalent to express.static(). If you're not in nodejs, look up your docs on how to do it in your prefered backend.

Solution 2: An HTTP Server Proxy

Let's say you don't want to use the backend to serve static files. You can reproduce a similar proxy configuration from your development, into a production http server. This is possible in Apache, Nginx, IIS, or any other http server that has this proxy capability.

For example, an nginx.conf would look like this for static files + express:

server {
  listen 80;
  server_name example.com;
  location / {
    root /path/to/build/folder;
    index index.html;
  }
  location /api {
    proxy_pass http://localhost:3000;
  }
}

Here's another quick example with Apache (The ProxyPass line is all you would need) :

<VirtualHost *:80>
        ServerName example.com
        DocumentRoot /var/www/backup
        ProxyPass /api http://localhost:3000/api/
        <Directory /var/www/backup>
                Require all granted
                Options +Indexes
                AllowOverride None
                Order allow,deny
                Allow from all
        </Directory>
</VirtualHost>

Note that the proxy address above doesn't need to be on the same machine - this can work even if you're hosting the frontend and backend on completely different services!

Solution 3: Actually using CORS

So what if you actually need to have a separate frontend and backend hosted on a completely different domain name, and you can't use a reverse proxy on your web server, and you have absolutely no way to do this any other method than API calls being on a different origin? THAT is when you need to think about CORS.

The very basics of CORS is extremely simple. You just need to add a header to any outgoing request sent from your backend server. The frontend cannot control this, it has to be a backend response header, period.

The header will look like Access-Control-Allow-Origin: https://example.com for a specific domain name, Access-Control-Allow-Origin: http://somedomain.com:8080 for, say, something on a different port, or if you really want to let anyone access your service, Access-Control-Allow-Origin: *.

It's not possible to add more than one ACAO header, or add more than one domain to the header. In order to support multiple origin domains, you would need backend logic that modifies this header to allow for the one doing the request. Most CORS libraries for your backend should have that capability, but obviously it's beyond the scope of this tutorial.

Conclusion

That's all, folks! Hopefully this extensive and verbose (sorry!) post is enough for you to understand why CORS errors happen, how to resolve them while you're developing your website, and even how to deal with them in production. If you have any questions, please don't hesitate to ask below and I'll try my best to help! 💖