Skip to content

Files

Latest commit

 

History

History
207 lines (174 loc) · 10.7 KB

TODO.md

File metadata and controls

207 lines (174 loc) · 10.7 KB

TODO

Introduction

Authoring

SQL

  • Include "id" INTEGER PRIMARY KEY AUTOINCREMENT in every table.
  • Use STRICT
  • Quote table and column names (for example, "users"."name"), to avoid conflicts with SQL reserved keywords and to help with syntax highlighting.
  • Put sql`___` on its own line because of a glitch in the syntax highlighting.

HTML

  • Use key="___" to control Live Navigation and Live Connection updates.

CSS

  • Define properties in the following order:
    1. Font and text properties.
    2. Colors, from foreground to background (for example, color then background-color).
    3. Box model, from the inside out (for example, width, then padding, then border, then margin, then outline).
    4. Positioning of element with respect to container (for example, position).
    5. Positioning of children (for example, display: flex;).
    6. Interactions (for example, cursor).
    7. Transformations.
    8. Animations.
    9. States (in chronological order, for example, :hover, :focus-within, :active).
    10. Variations (for example, breakpoints and dark mode).
    11. Children, including ::before and ::after.
  • Don’t use the same set of breakpoints all the time. Analyze case by case, and set breakpoints accordingly. (And besides, CSS variables don’t work for setting breakpoints, because they’re defined in :root, and the media query lives outside the scope of a selector.)
  • Levels of abstraction
    • Inline styles
    • Extract a CSS class (for example, .button)
    • Extract a function that produces HTML (for example, userAvatar())
    • Global styles (for example, font)
  • Document: Don’t use #ids, because of specificity (use key=""s instead, for compatibility with @radically-straightforward/javascript)
  • Use classes for everything, not just tag name selectors, because you may want an <a> to look like a button, and a button to look like a link.

@radically-straightforward/server

  • Router
  • Request Parsing
    • In the case of a request with a file that is too big, the server may not stop writing the file to the filesystem early enough, abusing the server resources (for example, disk).
    • Pass pathname parameters through decodeURIComponent?
    • Different charsets?
    • Content-Encoding (for example, compression)?
  • Response Helpers
    • Do we really don’t have to worry about Content-Length?
      • Node.js already sets Content-Length if you use end(). If you use write() Node.js sets chunked transfer.
      • If necessary we could use Buffer.byteLength() to determine the Content-Length
  • Live Connection
    • Don’t traverse the set of connections: Index by request.id and by request.URL.pathname (with hierarchical indexing, similar to proposal for utilities.intern)
    • Currently a Live Connection update sends a whole new page to the browser, even if only a small occurred. To solve this, we could have the server hold on to the latest rendering, diff on the server instead of the browser, and send a transcript of what the browser needs to do to to morph the page. This is what Phoenix LiveView does.
  • Image/Video/Audio Proxy
    • Edge cases
      • Test destinations like localhost, 127.0.0.1, and so forth
      • Test redirect loop
      • Test timeout
      • Limit size?
    • Range requests?
    • Resize images?
    • Cache? Not only for performance, but also because third-party images may go away
    • Include HMAC?
      • Perhaps not, because as far as I understand the purpose of HMAC is to prevent abuse, but hotlinked images can only be used from our website anyway due to Cross-Origin-Resource-Policy. In other words, you can’t hotlink a hotlinked (proxied) image. This saves us from having to compute & verify HMACs.
  • CSRF Protection
    • Currently we’re defending from CSRF by requiring a custom header. This is the simplest protection mechanism, but it’s vulnerable to broken environments that let cross-site requests include custom headers (for example, old versions of Flash).
    • Synchronizer tokens are the most secure option.
      • Communicate the token to the server with the custom header (CSRF-Protection), combining the synchronizer token with the custom header approach.
      • Let the synchronizer tokens be session-wide, not specific per page, so as to not break the browser “Back” button.
      • Couple the synchronizer token to the user session.
      • Have pre-sessions with synchronizer tokens for signed out users to protect against login CSRF.
    • In case the implementation of the synchronizer token doesn’t go well, try to use the double-submit pattern.
      • It requires a secret known by the server to implement most securely. Note how everything boils down to the server recognizing itself by seeing a secret piece of data that it created.

@radically-straightforward/sqlite

@radically-straightforward/html

@radically-straightforward/css

@radically-straightforward/javascript

  • TypeScript in browser JavaScript.

  • Client-side templating from within server-side templating:

    response.end(html`
  <div javascript="${javascript`
    this.insertAdjacentHTML("beforestart", html`[...] ${HAVE THIS RESOLVE ON THE CLIENT} [...]`);
  `}"></div>
`);

  • Live Navigation

  • Live Connection

    • Partials could have their own Live Connection lifecycle

@radically-straightforward/utilities

@radically-straightforward/node

  • Application startup (process management)
    • Tunnel
      • Start Caddy with address http://localhost, then create a port forwarding in Visual Studio Code to port 80, public.
    • Profiling
    • Children processes could tell main process that they’re ready, this way we could do things like, for example, only start Caddy when the web processes are ready to receive requests. This is what worker threads & clusters call being online. If we do that, then we can enable Caddy’s active health checks.
    • If a child process crashes too many times in a short period, then crash the main process.
  • Performance monitoring
    • Requests that are slow to answer
    • Background jobs queue that grows too long
    • Process crashes

@radically-straightforward/typescript

@radically-straightforward/documentation

@radically-straightforward/caddy

  • There’s an issue when running for the first time: Caddy may ask for your password, but you may not see it.
    • It still works if you see it and type in the password, even as other stuff has scrolled by.
    • Potential solutions:
      • If Caddy configuration directory doesn’t exist, run Caddy on the foreground
      • Run Caddy before spawning other children processes (but how do you know that Caddy is done?)
      • Document this quirk.
  • Rate limiting

@radically-straightforward/build

@radically-straightforward/package

@radically-straightforward/production

@radically-straightforward/development

Other

  • unref the setTimeouts.
  • Better text editor support for tagged templates with 100% functional syntax highlighting and IntelliSense.

Marketing

  • Logo
  • Dedicated website
  • Conference talks
  • Videos
  • Podcasts