Flashcards App

Testing Web Components

While any test framework can work, it’s better to test web components in a browser environment because that’s where they’ll be used. Node-based frameworks would require too much shimming of DOM calls that’d make the tests unrepresentative. and are good options for browser-based testing.

is powered by ES-build, and so is the client-side of the app; let’s go down this path and see where it leads. CommonJS modules don’t work in the browser . Earlier on , using ESM on the server turned out difficult. Hopefully, that doesn’t me bite back now.

Currently using MongoDB’s free tier, which has shared RAM, and up to 5GB of storage . So far, the overall DB usage has been less than 5MB.

Query Injection

Current State of Affairs

Currently have this protection implemented back in 2018:

/**
 * @description Prevent a NoSQL Injection in the search parameters. This is
 * achieved by deleting all query values that begin with `$`.
 */
export function sanitizeQuery(query: any) {
  const keys = Object.keys(query);
  for (let i = 0; i < keys.length; i++) {
    if (/^\$/.test(query[keys[i]])) { delete query[keys[i]]; }
  }
  return query;
}

What automatic tools can I add to keep code quality high?

CodeQL

CodeQL is a tool that runs variant analysis on code. The idea is that we create a query from a known vulnerability, e.g., SQL injection, and then run it against a codebase to find instances of that vulnerability. GitHub authorizes the use of CodeQL for public repos, and so we are covered . ql-analysis.sh has a recipe for running the analysis locally in the repo. CodeQL also runs on every PR, and blocks check-in if new vulnerabilities are discovered.

Syntax Highlighting

Previously, we’d highlight code on the client by loading src/lib/highlight.pack.js, a bundle downloaded from but served from our domain, and then execute hljs.highlightBlock on demand, e.g., on page load, when showing a card, etc. This doesn’t work well with a web-component-centric design. Running hljs.highlightBlock through possible Shadow DOM boundaries is a hassle.

Back in 2018 , we installed highlightjs, a shim for the official HighlightJS. Times have changed and has an official Node package, highlight.js . Now, on the server, compute the syntax-highlighted HTML and have it stored in Card.descriptionHTML. All that’s left is to provide CSS on the client.

Moving to TypeScript entails configuring how the JavaScript will be eventually consumed by both the server and the client.

Separating the Client Bundle from the Server Bundle

The server code runs in Node while the client code runs in the browser. advises separating the configurations for advantages like faster type-checking and compiling, lower memory usage when using an editor, and improved enforcement of the logical groupings of your program.

Webpack utilizes loaders to preprocess files, allowing the dev to bundle any static resource. For example, markdown-loader compiles markdown into HTML. I’ve been using ts-loader , and it should be informative to know what else is out there, e.g., esbuild-loader , which has been mentioned at work. esbuild-loader’s claim to fame is speed; other benefits include transpiling to ES6+ using esbuild. ts-loader admits to being slow, but because of type-checking all files in every rebuild though granted that can be dangerously disabled via transpileOnly: true. esbuild makes bold claims about being pretty fast, e.g., 87x faster than rollup 4 + terser.

How to handle redirects without setting window.location.href?

Right now, there’s a pattern of doing:

sendHTTPRequest("POST", "/login/", {})
  .then((_) => {
      window.location.href = "/";
  })
  .catch((err) => { console.error(err); });

Isn’t this something that the server can do? In response, why not issue a redirect?

Back when I wrote this, the motivation for using localStorage was to reduce the trips to the server so that the app is usable offline. However, with two data stores (localStorage and the server), the former has a possibility of going stale. What usage is correct and how can we avoid stale data?

localStorage['session_info']

getAccountInfo: () => AuthenticateUser | null fetches the session_info entry and JSON.parses it into an AuthenticateUser. This is a possible failure point because the parsed JSON cannot be trusted to be a valid AuthenticateUser instance. This bit should be removed.

Current State: SaaS

The app is hosted at render.com on Render’s free tier that gives us these free web services:

• Custom domains
• Managed TLS certificates
• Pull request reviews
• Log streams
• Rollbacks up to the two most recent previous deploys.

… with these limitations:

• Spins down after 15min of no inbound traffic. Spinning up on the next request causes a noticeable delay for a couple seconds.
• Monthly limits, which will suspend the app if exceeded:
  • 750 instance hours.
  • 100GB bandwidth.
  • 500 pipeline minutes.
• Can be restarted at any time by Render.

Render’s free PostgreSQL database becomes inaccessible 90 days after creation. For our DB needs, we’re using MongoDB’s free tier , which has shared RAM, and 512MB to 5GB of storage.