jdrydn

[jdrydn]

This month, thanks to Amazon Prime Day, I’m finally tapping into the world of 3D printing!

I went with a “Creality Ender 3 V2 Neo”, a little bigger than I was expecting but loving the size of the bed, that should mean I can print some fantastic stuff!

It took a little while to get it printing properly, the default bed temperature was too low for anything to stick! A little searching on Reddit & a couple of texts to a colleague (thanks L!) I finally got the Boat to complete successfully!

"Benchy" from Makerworld:

Next print, a Skyrim bookmark for my wife, again from Makerworld:

What’s next? Looking through sites like Makerworld & Thingiverse:

Stackable shipping containers?

Stackable mesh boxes?

Vegas sign?

Or something way more complex.. Corvo's blade from Dishonored?

[jdrydn]

You can’t trust anyone - but don’t panic!

Ah DHH, your opinion pieces never cease to make waves! 🤣

This really should be a wider-focussed piece about how the internet comes and goes - everything online is ephemeral (even if you run your own servers (and promise to support really old software “forever”)) - but instead it’s targeted at Google & their quick subset of Google Domains, probably helps “the DHH agenda” & “big corporate-led cloud providers are bad” narrative.

To be clear: This specific situation isn’t great. If my domain registrar was selling my data (and more importantly, my domains!) without giving me enough time to migrate, I’d be angry too.

But this could happen with any service. Facebook, Gmail, iCloud or Yahoo Mail (that last one, perhaps should have happened already! 😬). At any time in the future, a product/service will be deprecated & customers will have to pick up & take their business elsewhere.

Until then, enjoy today & be wary of those clickbait headlines!

[jdrydn]

GraphQL WhereInputs

When you resolve properties in GraphQL types, especially resolving relational types, you usually take a single ID & expand it into an object.

Frustratingly, GraphQL doesn’t support the same resolver behaviour for input types. Typically you’d have to send up the ID as a standalone property - which you need to know/lookup beforehand. And what about bulk queries, where you (atomically) can’t fetch all IDs at once to perform updates?

To address this issue I tend to build a series of "WhereInput" types into the GraphQL project, which are small reusable inputs throughout the schema, to create a uniform way to filter entries or select a relational entry when creating/updating entries:

An example usage of these might include:

Implementing WhereInputs into your GraphQL project has plenty of benefits & side effects, the top three include:

Unify how you specify relational entities in your GraphQL schema. Rather than using a quick entryID input property (e.g. author: $userID) you can use a uniform object (e.g. author: { id: $userID } or author: { email: $email }). And, depending on how you structure your Input functions, you could perform additional validation on the relational entry you want to use) e.g. { id: $userID, status: ACTIVE }).

When you want to filter entries by a new property, e.g. a user’s favourite colour, you add a few lines of code in one function & now anywhere you already filter users can now filter by email!

A good WhereInput implementation can also give your application logic a unified way of searching for entries by your WhereInput query, simplifying your application logic further.

Remarks

By habit, I tend to append "Input"/"Enum" to the end of these types so when used throughout the codebase, it's always clear that what type I'm using.

It would be nice to have a type/input class that works for both reading & writing though!

If you’re building a GraphQL API in Node.JS without dataloader or graphql-resolve-batch be sure to check them out - both libraries make bulk-loading data ruthlessly efficient!

You can combine your Inputs with a Dataloader instance to create a uniform way of fetching entry IDs from a schema-defined object internally. This is incredibly useful within your resolvers but throughout the rest of your application too!

[jdrydn]

You definitely should have timestamp'd it!

Storing timestamps instead of booleans, however, is one of those things I can go out on a limb and say it doesn’t really depend all that much. You might as well timestamp it. There are plenty of times in my career when I’ve stored a boolean and later wished I’d had a timestamp. There are zero times when I’ve stored a timestamp and regretted that decision.

Nailed it 🔨

It's a pattern I've done by accident for a few tables, and now after reading this it'll be a pattern to implement literally everywhere.

Future-you will thank you. 🙏

Other good articles from Changelog I've ended up reading over the weekend:

There's a good reason why experienced devs say "it depends" so often

Hosting SQLite databases on GitHub Pages