Skip to content

Instantly share code, notes, and snippets.

Avatar

Samuel Scheiderich samsch

View GitHub Profile
@samsch
samsch / js-query.js
Last active Oct 2, 2020
Nested Knex query
View js-query.js
knex
.select([
'users.*',
knex.raw('json_agg("posts") as posts')
])
.from('users')
.leftJoin(function () {
this.select(['posts.*', knex.raw('json_agg("comments") as comments')])
.from('posts')
.leftJoin('comments', { 'posts.id': 'comments.post' })
@samsch
samsch / relational-vs-nosql.md
Created Sep 13, 2020
When should I use relational vs NoSQL databases?
View relational-vs-nosql.md

When should I use relational vs NoSQL databases?

What is the task you need to accomplish?

Frequently this question is asked as a "what should I use for a web app" question with no real details for what kind of data is being stored. As it turns out, that's ok! We actually have a type of database which directly fits "general purpose", by being fully robust and flexible. These are the relational databases, which are designed around the SQL standard.

Because "general purpose" covers most tasks really well when it comes to databases (something that's not nearly as true in other areas of technology), you can just grab PostgreSQL or MySQL and use that for all data storage purposes, and likely have no issues for the full lifetime of the project.

When general purpose is not enough

View all-data-is-relational.md

All Data is Relational

Think of the least relational data you can come up with.

That data, and each item in it, has explicit and implicit relationships.

If it's a list of items, then the items are explicitly related to each other by nature of being in the same list. A list is a type of relationship.

If you have an app that stores random items which are each completely unrelated to each other... they are all related to the app.

@samsch
samsch / .md
Created Jul 14, 2020
Don't put sensitive data in environment variables (including .env files)
View .md

Some links

A simple alternative is to put your sensitive (or all) config in a .json file that is gitignored. This also has the advantage of being easily generated using tools which can retrieve the sensitive data from a secure store (e.g., via ssh using user ssh key). With Node.js, .json files can be directly require()d, which is an additional convenience.

@samsch
samsch / .md
Last active Jul 2, 2020
Issues with Scarf-js approach
View .md

My problems with Scarf-js

The @scarf/scarf package uses the postinstall package.json option to run a script that makes a request to [somewhere] with potentially sensitive data, and can be configured to do that with no (reasonably visible) user notice. As per almost any technology, the tech involved isn't inherently bad.

General principle

This is a fairly weak argument on it's own, but it's the "gut feeling" one that leads to others.

Libraries are expected to be installed with npm i, and to take no action besides what they require to be installed.

@samsch
samsch / .md
Created May 6, 2020
Discord answer about how to do dynamic layouts or rendering
View .md

There are a couple ways to handle this. You could generate different bundles for each client, but if the bundle itself is what contains the generated layouts/data choices, then you would have to rebuild that bundle for each change, and for all clients for updates to the base code. I'm not going to say there couldn't be a case where that makes sense to do, but I can't really think of one. What would be more "normal" is to have your bundle build the layout based on a declarative data structure you can easily store in a database.

A really primitive form of this would be a simple conditional rendering:

// settings is coming from the DB
const Component = ({ settings }) => {
  if (settings.itemA) {
    return <ItemA />;
  } else {
    return <ItemB />;
@samsch
samsch / Example.jsx
Created Feb 13, 2020
React Router Switch re-implementation
View Example.jsx
import React from 'react';
import {
BrowserRouter as Router,
Link,
} from 'react-router-dom';
import Switch from './Switch';
const MyRoute = ({ name }) => {
React.useEffect(() => {
console.log('Mounted');
@samsch
samsch / .md
Last active Oct 11, 2019
Working with Postgres JSON datetimes in Laravel
View .md

Working with Postgres JSON datetimes

By default Laravel uses Y-m-d H:i:s for datetime parsing and formatting against the database. It gets this value as the connection default.

Postgres uses Y-m-d H:i:s as the datetime format default for all fields. Except that it does not follow this for datetimes that are serialized as JSON, where it follows ISO 8601 and formats as Y-m-d\TH:i:s.

Laravel is fortunately able to use a manually set datetime format, so after you hydrate a model with datetime from Postgres JSON with datetimes, you should call $modelInstance->setDateFormat('Y-m-d\TH:i:s'); so that datetimes are parsed correctly. Fortunately, this does not break writing to the db, which seems quite happy to accept ISO 8601 datetime strings.

@samsch
samsch / pg_add_db.sh
Created Aug 16, 2019
Create local Postgres database + user + password
View pg_add_db.sh
#!/bin/bash
name=$1
if [[ -n "$name" ]]; then
if [[ $name =~ ^[a-z_]+$ ]]; then
sudo -u postgres createdb $name
sudo -u postgres createuser $name
sudo -u postgres psql -c "alter user $name with encrypted password '$name';"
sudo -u postgres psql -c "grant all privileges on database $name to $name;"
@samsch
samsch / answer.md
Last active Apr 17, 2020
Does using React negatively affect SEO?
View answer.md

The effect on SEO related to React comes from doing client-side rendering only. So this isn't React specific, any client-side-only view will suffer from this. But yes, SEO explicitly suffers for non-Google search engines which don't run the JavaScript for a page. Basically, your page is effectively blank. Google does run JavaScript, but their algorithm is intentionally quite complex and takes into account many factors, some of which (like initial render performance) can be affected by using only client-side rendering.

In reality, most sites where SEO matters for the pages probably should not be rendered on the client, or at least not on the client only. The web is designed around servers generating html, and unless you have a strong reason not to, it's better to fall in with that paradigm by default.

So then, there are two ways React can still be valuable, even when rendering on the server. The simpler way is to just use React as a server side templating language. I've been doing this on a current project,

You can’t perform that action at this time.