HN user

tgasson

51 karma

tom<at>gasson<dot>com<dot>au

Posts0
Comments29
View on HN
No posts found.
Progressive JSON 1 year ago

The GraphQL payload has redundant copies of the objects within. Relay has an experimental (dead) exploration of normalising data on the server[1] in order to avoid that transport cost.

For @defer, the transport is a stream[2] where subsequent payloads are tracked ("pending") and as those payloads arrive they are "patched" into the existing data at the appropriate path.

Both of these are effectively implementations of this Progressive JSON concept.

I can picture a future where both the JSX and object payloads are delivered progressively over the wire in the same stream, and hydrate React and Relay stores alike. That could potentially simplify and eliminate the need for Relay to synchronise it's own updates with React. It would also potentially be a suitable compile target for decoupling, React taking ownership of a normalised reactive object store (with state garbage collection which is a hard problem for external stores to solve) with external tools like Relay and TanStack Query providing the type-generation & fetching implementation details.

Using `new Promise()` in the client-side store would also mean you could potentially shrink the component API to this. `useFragment(fragment IssueAssignee on Issue { assignee { name }}, issue)` could instead be `const assignee = use(issue.assignee)` and would suspend (or not) appropriately.

[1] https://github.com/facebook/relay/blob/main/packages/relay-r...

[2] https://github.com/graphql/graphql-wg/blob/main/rfcs/DeferSt...

No, not part of graphql. Apollo Optics (no relation) is an option, or you can instrument the fields yourself just like you would implement any other instrumentation.

with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API

That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change

Do you have any links to how the errors are passed through to the client? Do you mean that they imitate the incoming certificate exactly or send the information by some other method?

You want to do that both on your intercepted LAN and with a direct connection and compare the results. If they both give the same results you can be happy your MitM proxy is at least treating insecure sites equivalently. You still lose the advantage that you browser will tell you why the site is insecure

It's 4. The columns are the digits 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 And the rows are the character used for that digit at that point in time.

At some point later 5 mutated from looking like 4 to as it is now.

Yes I have run into this issue myself. It is a public resource, if you're not logged in at all its fine or if you're recently logged in its fine.

It's the same reauth you sometimes get when visiting a public blogger site. It is an edge case, but quite unpredictable and hard to track down from client reports.

This is great for prototypes but there's an edge case that breaks it's usefulness in live sites.

Sometimes google will make already logged in users reauthenticate. It will redirect to the authentication page and you'll get a bunch of HTML rather than json returned, and the user won't know why it's not working.

No, because it needs to be checked out (that's the deployment). As a usual git server, yes --bare is the way to go. In this case you could alternatively use --bare in a ~/repos/example.com dir and set the $GIT_WORKING_DIR environment variable to ~/www/example.com for checkout.

Mapping with D3 14 years ago

That's actually something topojson will do for you. It stores a translate and scale value that fits so all the values can be simple integers.

Mapping with D3 14 years ago

Absolutely agree. I'm currently in the process of producing a thematic map as part of a set of data visualisations[1]. TopoJSON is proving to be an absolute godsend. It's allowed us to reduce ~100MB+ geoJSON down to ~1MB and the shared arc's means we can include multiple levels of boundaries without duplicating the data needed to be sent over the network.

There's still some issues we're having. SVG rendering performance isn't fast or consistent across browsers for 3000+ polygons and although TopoJSON shares arcs between common boundaries the rendered polygons don't. Also the large differences in the size of boundaries we're dealing with means the map needs to be zoom-able. Delivering higher detail boundaries dynamically is tough problem to solve. Ideally you could request a bounding box from a TopoJSON based server, and it would deliver a delta of higher detailed points precomputed from Visvalingam’s algorithm[2].

I found the default quantization level to be much too blocky. For anyone working with TopoJSON I'd recommend you first raise the quantization level while looking at your smallest features until they're no longer blocky, then use the inbuilt simplification to bring the file size down to manageable.

[1] http://www.bts.nsw.gov.au/BTS-Visual [2]: http://bost.ocks.org/mike/simplify/ (explained at the bottom)

Sorry I wasn't aware of that. Do you have a link? Best I can find is [1] which states

  In respect of Offence 4, Mr Assange contended that whilst rape was a Framework Offence and therefore didn't require dual criminality, the conduct described in the EAW was not fairly and accurately described and that if it had it would not be rape.
[1]: http://www.judiciary.gov.uk/Resources/JCO/Documents/Judgment...

edit: Thanks for clarification.

Splash screens are never good UX. Why not load a content-less DOM structure whilst loading the data so the user can get familiar immediately, the same way iOS apps work.

I wouldn't be surprised to see them directly replace the old surface with the guts of the new one integrated into a 60" multitouch TV (for both table and on the wall use) and scrap the IR object detection for a kinect based solution. Of course this would leave them with the cost of a huge multitouch panel.

Every module will have a `module` variable available to it.

    `module` defaults to {
        id: ...
        exports: {}
        parent:...
        filename:...
        loaded:...
        exited:...
        children:...
        paths:...
    }
Whatever module.exports is at the end of the module is passed to the require statement.

Every file essentially has two lines at the top.

    this = module.exports;
    var exports = module.exports;
The first helps lazy developers by allowing exporting without explicitly saying so. Because of this, the following alone is a valid module that exports {foo:'bar'}
    foo = 'bar'; // can also be written as this.foo = 'bar';
And the second matches the CommonJS standard. So the following CommonJS module will work:
    exports.foo = 'bar';
If you assign module.exports at any time after using `this` or `exports`, module.exports will point to the new object, and anything on the original module.exports object wont be passed to the `require` call.

I think much of this is due to Spine being designed for CoffeeScript, and the article only uses the Javascript notation. Be sure to look at the documentation http://spinejs.com/docs/models and toggle between the Javascript and CoffeeScript versions of the code samples.