Skip to content

Instantly share code, notes, and snippets.

View captbaritone's full-sized avatar
💭
-=[ Dorkin' Out ]=-

Jordan Eldredge captbaritone

💭
-=[ Dorkin' Out ]=-
View GitHub Profile
@captbaritone
captbaritone / resolver_directive_spec.md
Last active November 19, 2024 03:54
[RFC] JavaScript Resolver Directive Spec

JavaScript Resolver Directive Spec

This document (DRAFT) describes GraphQL directives used to annotate a GraphQL schema which is backed by JavaScript resolvers. Its goal is to encode enough information that a complete GraphQL executor for the schema can be inferred directly from the GraphQL Schema Definition Language (SDL) document. This approach is especially attractive for implementation-first servers where the GraphQL schema and how to execute it can be inferred directly from the resolver code itself.

Motivation

Ideally this scheme can enabling decoupling and interoperability between tools. For example:

  • Tools that could generate SDL with these directives:
  • Grats
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "ConfigFile",
"anyOf": [
{
"description": "Base case configuration (mostly of OSS) where the project have single schema, and single source directory",
"type": "object",
"required": [
"language"
],
@captbaritone
captbaritone / live-resolvers.md
Created September 20, 2023 05:07
Dropping Live Resolver Docs [Raw]

0. Relay Live Resolvers

Relay Liver Resolvers are an experimental Relay feature which lets you extend your server’s GraphQL schema to include additional client state. For example, you might want to expose data from a legacy state management solution or from IndexDB to your Relay components.

Your experience writing GraphQL resolvers on the server should mostly apply to writing Live Resolvers. The main distinction is that Live Resolvers are reactive. Instead of just reading a single values, Live Resolvers model a value that might change over time, similar to an observable.

Pages

This rule lints for non-colocated fragment spreads within queries or fragments. In other words, situations where a fragment is spread in module A, but the module (B) that defines that fragment is not imported by module A. It does not lint subscriptions or mutations. This catches:

  • The anti-pattern of spreading a fragment in a parent module, then passing that data down to a child module, or jamming it all in context. This defeats the purpose of Relay. From the Relay docs – "[Relay] allows components to specify what data they need and the Relay framework provides the data. This makes the data needs of inner components opaque and allows composition of those needs."
  • Instances where fragment spreads are unused, which results in overfetching. In addition to consuming more gCPU, it can also sometimes cause SEVs: D19057571

When the fragment is unused

The easiest way to tell if a fragment is unused is to remove the line containing the lint error, run js1 rebuild relay, the

'use strict';
const {ROOT_DIR} = require('../../utils/config/index.js');
var fs = require('fs');
const OSS_DIR = `${ROOT_DIR}/xplat/js/RKJSModules/Libraries/Relay/oss`;
const COMPILER_TARGETS_FILE = `${ROOT_DIR}/fbcode/relay/oss/crates/relay-compiler/TARGETS`;
const COMPILER_CARGO_FILES = [
`${ROOT_DIR}/fbcode/relay/oss/crates/relay-compiler/Cargo.toml`,
`${ROOT_DIR}/fbcode/relay/oss/Cargo.oss.lock`,
];
const EQUALITY_OPERATORS = new Set(['==', '===', '!=', '!==']);
module.exports = {
meta: {
messages: {
constant: 'Constant condition.',
coalescingNeverNullish: 'Constant condition. Value can never be nullish.',
coalescingAlwaysNullish:
'Constant condition. Value will always be nullish.',
},
╭─[23:32]: jordaneldredge at Jordans-MacBook-Pro in ~/projects/skin-scrapers/niko-niko.net
╰─➤ find . | grep -i zip | wc -l
218
╭─[23:32]: jordaneldredge at Jordans-MacBook-Pro in ~/projects/skin-scrapers/niko-niko.net
╰─➤ find . | grep -i zip
./winamp/Zel.ZIP
./winamp/shin.zip
./winamp/rasen7.zip
./winamp/naus.ZIP
@captbaritone
captbaritone / index.js
Created September 24, 2019 14:15
maki compiler as a service
const express = require("express");
const path = require("path");
const fsExtra = require("fs-extra");
const os = require("os");
const app = express();
const port = 3000;
const { exec } = require("child_process");
const Busboy = require("busboy");
const tmpDir = os.tmpdir();
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
</head>
<body>
<div id='app'>
<!-- Webamp will attempt to center itself within this div -->