profile
viewpoint
Harry Brundage airhorns Ottawa harry.me Developer developer

airhorns/codejam 3

a node.js application written for the mcgill codejam in 48 hours

airhorns/backbone 1

Give your JS App some Backbone with Models, Views, Collections, and Events

airhorns/batman 1

Fighting Crime and Kicking Apps

airhorns/batman-rails 1

Easily use batman.js with Rails 3.1

airhorns/ble-gateway 1

Teensy node service for receiving BLE beacons and firing them onto an MQTT bus

airhorns/body-fractals 1

OpenGL fractal renderer controlled by your body via Kinect!

startedjuxt/crux

started time in 12 hours

starteddatacrypt-project/hitchhiker-tree

started time in 12 hours

push eventairhorns/find-my-way

Harry Brundage

commit sha a0e8905548f7aa67d8a5f5ff2417449b1cef6a41

Add function names to route handler pretty print if they are present

view details

push time in 20 hours

PR opened delvedor/find-my-way

Pretty print handler names

This is on top of #168 and replaces #138 and #144. If/when #168 gets merged I will rebase this!

This adds a handler function's name to the pretty printed route output. It required a kind of annoying change in how the handlers are iterated to pretty print, but that change is also necessary for the constrained route handler work in #166 so it's one more thing that I peeled out for merging separately.

+233 -130

0 comment

5 changed files

pr created time in 20 hours

create barnchairhorns/find-my-way

branch : pretty-print-handler-names

created branch time in 20 hours

pull request commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

Ok, with the latest version of this branch I'm up to lookup static route x 43,797,356 ops/sec ±0.98% (589 runs sampled) which is faster than master for me, plus or minus the benchmarking noise! 🥳

airhorns

comment created time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha acf1283552c1e0fc5e5939dc1f23f195fadd3676

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha ce7f7cc6f4d87e448f2a6715059fe8cfe1e6be1f

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

pull request commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

Does it make sense to you why an object literal would be faster? Shouldn't it be slower because of the shape chain created?

airhorns

comment created time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha 2314b7754439a0f4cab644d1d0bbdc22575f6c9b

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

Pull request review commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

 if (!isRegexSafe(FULL_PATH_REGEXP)) {  const acceptVersionStrategy = require('./lib/accept-version') +function buildMethodMap () {+  const code = []+  for (var i = 0; i < http.METHODS.length; i++) {+    var m = http.METHODS[i]+    code.push(`this['${m}'] = null`)+  }+  return new Function(code.join('\n')) // eslint-disable-line+}

I take it back -- this makes a huge difference:


function buildMethodMap () {
  const code = []
  for (var i = 0; i < http.METHODS.length; i++) {
    var m = http.METHODS[i]
    code.push(`this['${m}'] = null`)
  }
  return new Function(code.join('\n')) // eslint-disable-line
}

// Object with prototype slots for all the HTTP methods
const MethodMap = buildMethodMap()

gives me lookup static route x 44,563,670 ops/sec ±0.88% (584 runs sampled)

whereas a constructor that just loops over the methods gives me lookup static route x 29,380,113 ops/sec ±1.03% (573 runs sampled)

airhorns

comment created time in 2 days

PullRequestReviewEvent

push eventairhorns/find-my-way

Harry Brundage

commit sha 334be9f963c933f5dd068cb6bac20b84749029c8

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha 3e21a17d8b96475a6b278ae778100d5e8ecafcd7

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha 68d5725ce207210bace8e845d8b739cd8b44102a

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

push time in 2 days

pull request commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

I found this thing the other day which might be worth setting up: https://github.com/rhysd/github-action-benchmark , though I think it wouldn't resolve the benchmark noise issue because of noisy neighbours in the cloud, it would at least mean contributors can let computers do the computer stuff of running the benchmarks and formatting them all the time instead of having to rerun locally often and try not to touch their computer while they are running :)

airhorns

comment created time in 2 days

Pull request review commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

 if (!isRegexSafe(FULL_PATH_REGEXP)) {  const acceptVersionStrategy = require('./lib/accept-version') +function buildMethodMap () {+  const code = []+  for (var i = 0; i < http.METHODS.length; i++) {+    var m = http.METHODS[i]+    code.push(`this['${m}'] = null`)+  }+  return new Function(code.join('\n')) // eslint-disable-line+}

I was just copying the code that was already there -- this object with one property per HTTP method was used in Node for the handler map before. See https://github.com/delvedor/find-my-way/commit/c70b2e8599262aa4d784f8f50c88ee655cca94ca. I think it a little unclear and since there's only one instance of them per router I will switch it back to being a plain old constructor.

airhorns

comment created time in 2 days

PullRequestReviewEvent

pull request commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

Also, I have gotten pretty widely varying benchmark results when running locally such that I thought that static line was about the same, but do you trust the error bars on those numbers enough that they really do need to match?

airhorns

comment created time in 2 days

pull request commentdelvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

@mcollina or @delvedor do you have any suggestions for what might be causing that small regression? I tried profiling locally and it's hard to assess because the find method dominates everything (duh) and is so big.

airhorns

comment created time in 2 days

push eventairhorns/find-my-way

Harry Brundage

commit sha 6170204c26bcb6fb9f6d46320d8c11785c483257

Add constrained route pretty printing

view details

push time in 3 days

push eventairhorns/find-my-way

Harry Brundage

commit sha 57e7a6d6f1bb26ac3239bbfd839c81311e3dd9a4

Add some couple realistic routes and benchmarks for a REST API

view details

Harry Brundage

commit sha 39b07590c6cfa5ff613622bd278419c0fabc5090

Switch to using one tree per method instead of a map of per-method handlers on each node This makes pretty printing annoying, but increases performance! With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption. This also makes the constraint implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug. This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless. For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests. Benchmarks: ``` kamloop ~/C/find-my-way (master) ➜ npm run bench; git checkout one-tree-per-method; npm run bench > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 42,774,309 ops/sec ±0.84% (580 runs sampled) lookup dynamic route x 3,536,084 ops/sec ±0.70% (587 runs sampled) lookup dynamic multi-parametric route x 1,842,343 ops/sec ±0.92% (587 runs sampled) lookup dynamic multi-parametric route with regex x 1,477,768 ops/sec ±0.57% (590 runs sampled) lookup long static route x 3,350,884 ops/sec ±0.62% (589 runs sampled) lookup long dynamic route x 2,491,556 ops/sec ±0.63% (585 runs sampled) lookup static versioned route x 9,241,735 ops/sec ±0.44% (586 runs sampled) find static route x 36,660,039 ops/sec ±0.76% (581 runs sampled) find dynamic route x 4,473,753 ops/sec ±0.72% (588 runs sampled) find dynamic multi-parametric route x 2,202,207 ops/sec ±1.00% (578 runs sampled) find dynamic multi-parametric route with regex x 1,680,101 ops/sec ±0.76% (579 runs sampled) find long static route x 4,633,069 ops/sec ±1.04% (588 runs sampled) find long dynamic route x 3,333,916 ops/sec ±0.76% (586 runs sampled) find static versioned route x 10,779,325 ops/sec ±0.73% (586 runs sampled) find long nested dynamic route x 1,379,726 ops/sec ±0.45% (587 runs sampled) find long nested dynamic route with other method x 1,962,454 ops/sec ±0.97% (587 runs sampled) > find-my-way@3.0.4 bench /Users/airhorns/Code/find-my-way > node bench.js lookup static route x 41,200,005 ops/sec ±0.98% (591 runs sampled) lookup dynamic route x 3,553,160 ops/sec ±0.28% (591 runs sampled) lookup dynamic multi-parametric route x 2,047,064 ops/sec ±0.83% (584 runs sampled) lookup dynamic multi-parametric route with regex x 1,500,267 ops/sec ±0.64% (590 runs sampled) lookup long static route x 3,406,235 ops/sec ±0.77% (588 runs sampled) lookup long dynamic route x 2,338,285 ops/sec ±1.60% (589 runs sampled) lookup static versioned route x 9,239,314 ops/sec ±0.40% (586 runs sampled) find static route x 35,230,842 ops/sec ±0.92% (578 runs sampled) find dynamic route x 4,469,776 ops/sec ±0.33% (590 runs sampled) find dynamic multi-parametric route x 2,237,214 ops/sec ±1.39% (585 runs sampled) find dynamic multi-parametric route with regex x 1,533,243 ops/sec ±1.04% (581 runs sampled) find long static route x 4,585,833 ops/sec ±0.51% (588 runs sampled) find long dynamic route x 3,491,155 ops/sec ±0.45% (589 runs sampled) find static versioned route x 10,801,810 ops/sec ±0.89% (580 runs sampled) find long nested dynamic route x 1,418,610 ops/sec ±0.68% (588 runs sampled) find long nested dynamic route with other method x 2,499,722 ops/sec ±0.38% (587 runs sampled) ```

view details

Harry Brundage

commit sha a0232ed9f54dbba148e39d0a3751157c544e11e7

Merge branch 'one-tree-per-method' into constraints

view details

push time in 3 days

PR opened delvedor/find-my-way

Switch to using one tree per method instead of a map of per-method handlers on each node

This makes pretty printing annoying, but increases performance!

With n trees instead of one tree, each tree is only split for handlers it actually has, so for HTTP verbs like POST or PUT that tend to have fewer routes, the trees are smaller and faster to traverse. For the HTTP GET tree, there are fewer nodes and I think better cache locality as that tree is traversed the most often. Each verb doesn't pay any traversal penalty for the other trees' size. This also results in more instances of more selective version stores, which means traversing them should be faster at the expense of a bit more memory consumption.

This also makes the constraints implementation (see #166) easier, and prevents bugs like #132, and avoids the extra checks we have to do to fix that bug.

This also prevents tree traversal for methods where there are no routes at all, which is a small optimization but kinda nice regardless.

For the pretty printing algorithm, I think a nice pretty print wouldn't be per method and would instead show all routes in the same list, so I added code to merge the separate node trees and then pretty print the merged tree! To make it look pretty I added some "compression" to the tree where branches that only had one branch get compressed down, which if you ask me results in some prettier output, see the tests.

Test master one-tree-per-method
lookup static route 42,774,309 ops/sec ±0.84% (580 runs sampled) 41,200,005 ops/sec ±0.98% (591 runs sampled)
lookup dynamic route 3,536,084 ops/sec ±0.70% (587 runs sampled) 3,553,160 ops/sec ±0.28% (591 runs sampled)
lookup dynamic multi-parametric route 1,842,343 ops/sec ±0.92% (587 runs sampled) 2,047,064 ops/sec ±0.83% (584 runs sampled)
lookup dynamic multi-parametric route with regex 1,477,768 ops/sec ±0.57% (590 runs sampled) 1,500,267 ops/sec ±0.64% (590 runs sampled)
lookup long static route 3,350,884 ops/sec ±0.62% (589 runs sampled) 3,406,235 ops/sec ±0.77% (588 runs sampled)
lookup long dynamic route 2,491,556 ops/sec ±0.63% (585 runs sampled) 2,338,285 ops/sec ±1.60% (589 runs sampled)
lookup static versioned route 9,241,735 ops/sec ±0.44% (586 runs sampled) 9,239,314 ops/sec ±0.40% (586 runs sampled)
find static route 36,660,039 ops/sec ±0.76% (581 runs sampled) 35,230,842 ops/sec ±0.92% (578 runs sampled)
find dynamic route 4,473,753 ops/sec ±0.72% (588 runs sampled) 4,469,776 ops/sec ±0.33% (590 runs sampled)
find dynamic multi-parametric route 2,202,207 ops/sec ±1.00% (578 runs sampled) 2,237,214 ops/sec ±1.39% (585 runs sampled)
find dynamic multi-parametric route with regex 1,680,101 ops/sec ±0.76% (579 runs sampled) 1,533,243 ops/sec ±1.04% (581 runs sampled)
find long static route 4,633,069 ops/sec ±1.04% (588 runs sampled) 4,585,833 ops/sec ±0.51% (588 runs sampled)
find long dynamic route 3,333,916 ops/sec ±0.76% (586 runs sampled) 3,491,155 ops/sec ±0.45% (589 runs sampled)
find static versioned route 10,779,325 ops/sec ±0.73% (586 runs sampled) 10,801,810 ops/sec ±0.89% (580 runs sampled)
find long nested dynamic route 1,379,726 ops/sec ±0.45% (587 runs sampled) 1,418,610 ops/sec ±0.68% (588 runs sampled)
find long nested dynamic route with other method 1,962,454 ops/sec ±0.97% (587 runs sampled) 2,499,722 ops/sec ±0.38% (587 runs sampled)
+210 -130

0 comment

4 changed files

pr created time in 3 days

create barnchairhorns/find-my-way

branch : one-tree-per-method

created branch time in 3 days

delete branch airhorns/krane

delete branch : frontendconfig

delete time in 3 days

push eventairhorns/find-my-way

Harry Brundage

commit sha c805f1eb390e453f3409818561b553fd07d3d22b

Switch to one tree per method and optimize constraint support - Make find always take a derivedConstraints object since with host constraining there will almost always be a derived constraint - Switch to one tree per HTTP method to use less memory per node and provide a more permanent solution to the wildcard issue between methods - Switches to using function generation for deriving constraints and matching given nodes against constraints with a performant bitmapping algorithm - Refactor the constraint store into a thing called a Constrainer that has all the global state needed for assessing constraints

view details

push time in 3 days

create barnchairhorns/find-my-way

branch : constraints

created branch time in 3 days

fork airhorns/find-my-way

A crazy fast HTTP router

fork in 5 days

push eventgadget-inc/deploy-container

Harry Brundage

commit sha ee60651b0745ee37a1a18d70ea8569be2cef560e

Use a hacked up version of krane for newer gke support

view details

Harry Brundage

commit sha 1640fc0459026e96d6ec111d188db7534d4fd21f

Upgraded krane

view details

push time in 6 days

pull request commentdelvedor/find-my-way

Request based constraints implementation

@AyoubElk I don't mind taking a stab at the semantics I just mentioned -- do you have any unpushed code though that I should base changes on?

AyoubElk

comment created time in 6 days

PR opened Shopify/krane

Add version exception for FrontendConfig resource for GKE

Fixes

error: no matches for kind "FrontendConfig" in version "networking.gke.io/v1"

when pruning resources on GKE clusters >= 1.17.9-gke.6300

See #687 for more details. Not exactly sure what the best way to test it, it's really just data and would require adding some CRD configured exactly like Google's is to a test cluster.

+1 -1

0 comment

1 changed file

pr created time in 6 days

push eventairhorns/krane

Harry Brundage

commit sha 31a695c1758c0f795d01f130276c04904289ffb4

Add version exception for FrontendConfig resource for GKE Fixes ``` error: no matches for kind "FrontendConfig" in version "networking.gke.io/v1" ``` when pruning resources on GKE clusters >= 1.17.9-gke.6300 See #687 for more details

view details

push time in 6 days

create barnchairhorns/krane

branch : frontendconfig

created branch time in 6 days

PR opened mkinoshi/fastify-opentelemetry

Make trace logging at the debug level

Fastify does it's request / reply logging at the INFO level, so if one wants request logs in production, they have to run at INFO. I think this means that this library should do its logging at the DEBUG level to keep log volume down and the logs easier to read through for humans. This also switches the debug log statement to use Pino's object bindings for the dynamic values which prevents time spent on cobbling together strings for often-unused debug log entries.

+1 -1

0 comment

1 changed file

pr created time in 6 days

push eventairhorns/fastify-opentelemetry

Harry Brundage

commit sha 93aac20b42936241cbfc65a1ff62ad7971b0e579

Make trace logging at the debug level Fastify does it's request / reply logging at the `INFO` level, so if one wants request logs in production, they have to run at INFO. I think this means that this library should do its logging at the `DEBUG` level to keep log volume down and the logs easier to read through for humans. This also switches the debug log statement to use Pino's object bindings for the dynamic values which prevents time spent on cobbling together strings for often-unused debug log entries.

view details

push time in 6 days

issue commentfission/fission

Fission 1.11.0 environment declarative specs are not working

I observed this behaviour too and 1.11.2 seems to have fixed it for me!

I installed fission with helm, and it seems like helm upgrade didn't update the CRDs properly, so even though I started using the 1.11.2 chart, my CRD definitions were out of date. I was able to fix that by completely removing fission with helm uninstall, and then manually kubectl deleting each of the CRDs, and then installing a fresh release with helm, which created the updated CRDs. I couldn't find where the CRDs were created in the helm chart but I feel like this might be a gotcha for other folks too!

Thanks!

abbaspw21

comment created time in 8 days

issue commentShopify/krane

Krane deploy error with prune whitelist - error: no matches for kind "Job" in version "batch/v2alpha1"

I'm getting the same error on GKE 1.17.9-gke.6300 for FrontendConfig:

error: no matches for kind "FrontendConfig" in version "networking.gke.io/v1"

Failed command:

Command failed: apply -f /tmp/d20201022-168-14b244a --prune --all --prune-whitelist\=/v1/configmap --prune-whitelist\=/v1/endpoints --prune-whitelist\=/v1/event --prune-whitelist\=/v1/limitrange --prune-whitelist\=/v1/persistentvolumeclaim --prune-whitelist\=/v1/pod --prune-whitelist\=/v1/podtemplate --prune-whitelist\=/v1/replicationcontroller --prune-whitelist\=/v1/resourcequota --prune-whitelist\=/v1/secret --prune-whitelist\=/v1/serviceaccount --prune-whitelist\=/v1/service --prune-whitelist\=acme.cert-manager.io/v1/challenge --prune-whitelist\=acme.cert-manager.io/v1/order --prune-whitelist\=apm.k8s.elastic.co/v1/apmserver --prune-whitelist\=apps/v1/daemonset --prune-whitelist\=apps/v1/deployment --prune-whitelist\=apps/v1/replicaset --prune-whitelist\=apps/v1/statefulset --prune-whitelist\=autoscaling/v2beta2/horizontalpodautoscaler --prune-whitelist\=batch/v1beta1/cronjob --prune-whitelist\=batch/v1/job --prune-whitelist\=beat.k8s.elastic.co/v1beta1/beat --prune-whitelist\=cert-manager.io/v1/certificaterequest --prune-whitelist\=cert-manager.io/v1/certificate --prune-whitelist\=cert-manager.io/v1/issuer --prune-whitelist\=cloud.google.com/v1/backendconfig --prune-whitelist\=coordination.k8s.io/v1/lease --prune-whitelist\=discovery.k8s.io/v1beta1/endpointslice --prune-whitelist\=elasticsearch.k8s.elastic.co/v1/elasticsearch --prune-whitelist\=enterprisesearch.k8s.elastic.co/v1beta1/enterprisesearch --prune-whitelist\=extensions/v1beta1/ingress --prune-whitelist\=fission.io/v1/canaryconfig --prune-whitelist\=fission.io/v1/environment --prune-whitelist\=fission.io/v1/function --prune-whitelist\=fission.io/v1/httptrigger --prune-whitelist\=fission.io/v1/kuberneteswatchtrigger --prune-whitelist\=fission.io/v1/messagequeuetrigger --prune-whitelist\=fission.io/v1/package --prune-whitelist\=fission.io/v1/timetrigger --prune-whitelist\=internal.autoscaling.k8s.io/v1alpha1/capacityrequest --prune-whitelist\=jaegertracing.io/v1/jaeger --prune-whitelist\=kibana.k8s.elastic.co/v1/kibana --prune-whitelist\=networking.gke.io/v1/frontendconfig --prune-whitelist\=networking.gke.io/v1/managedcertificate --prune-whitelist\=networking.k8s.io/v1/networkpolicy --prune-whitelist\=nodemanagement.gke.io/v1alpha1/updateinfo --prune-whitelist\=policy/v1beta1/poddisruptionbudget --prune-whitelist\=rbac.authorization.k8s.io/v1/rolebinding --prune-whitelist\=rbac.authorization.k8s.io/v1/role --prune-whitelist\=scalingpolicy.kope.io/v1alpha1/scalingpolicy --prune-whitelist\=snapshot.storage.k8s.io/v1beta1/volumesnapshot

Explain:

kamloop ~/C/gadget (main*) ➜  kubectl explain FrontendConfig
KIND:     FrontendConfig
VERSION:  networking.gke.io/v1beta1

DESCRIPTION:
     <empty>

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata	<Object>
     Standard object's metadata. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

   spec	<Object>
     FrontendConfigSpec is the spec for a FrontendConfig resource

   status	<map[string]>

Could you folks explain more about the general fix for this? I don't quite understand, and am happy to PR the small fix again for this resource but I wonder what a more sustainable version looks like.

sco11morgan

comment created time in 8 days

startedtantivy-search/tantivy

started time in 8 days

startedmosuka/blast

started time in 8 days

pull request commentaelbore/esbuild-jest

hard code options

I think the user's options still need to be respected in some instances, like the JSX pragma or the tslib stuff, no?

remorses

comment created time in 8 days

push eventgadget-inc/baseweb

Harry Brundage

commit sha 94e3279d50f76ca5d06a170c0f033d5309dc28cd

fix(input): add missing clearOnEscape prop to TypeScript types

view details

Harry Brundage

commit sha 9fd97e9a64224edd8da469e464049eee985d7ec6

Merge branch 'add-clear-on-escape-to-input' into gadget-hacks

view details

Chase Starr

commit sha 4afdc10a64ee4d337fb08827bd65f9c060ee4b64

feat(data-table): add initial sort props (#3751) * feat(data-table): add initial sort props * test(vrt): update visual snapshots for 7ee64bb [skip ci] (#3752) Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com> * fix(data-table): lint Co-authored-by: UberOpenSourceBot <33560951+UberOpenSourceBot@users.noreply.github.com> Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com>

view details

Konrad Kalemba

commit sha 2f75282b25243b07a7f548236dd7b9ef1398d5cb

feat(data-table): add locale support (#3729) * feat(data-table): add locale support * fix(data-table): fix type import source * refactor(data-table): get locale via context instead of prop * refactor(data-table): improve labels naming * feat(data-table): add locale support to datetime column * fix(data-table): remove redundant prop Co-authored-by: Chase Starr <chasestarr@gmail.com> * feat(data-table): respect locale's week starting day * fix(data-table): fix typo in locale * fix(data-table): add missing label's locale * feat(data-table): add locale support to boolean column * feat(data-table): add locale support to datetime and numerical filters * refactor(data-table): rename boolean column's labels * test(data-table): update test case Co-authored-by: Chase Starr <chasestarr@gmail.com>

view details

Bhavay Puri

commit sha 64033ed0a402780e2cbf14507a308157db97206a

fix(styletron): relax styletron-component (#3759)

view details

Harry Brundage

commit sha 43a6ea3708b334b3a06d40c2efb3562d924e55f3

fix(input): add missing clearOnEscape prop to TypeScript types (#3756)

view details

Graham Murdoch

commit sha 130570da35974f86887ed4efbd6554d20668bf5b

fix(tabs-motion): remove focus from tabpanel (#3763) * fix(tabs-motion): remove focus from tabpanel Also fixes an issue where focusVisible wasn't propagating properly to root components. * fix: update e2e spec

view details

Vojtech Miksu

commit sha 2bef0dccb1079b0752f616254a56b3b348d7ad50

Slider Redesign (#3761) * feat(slider): add support for marks * feat(slider): update scenarios and label styles * feat(slider): fix lint, flow and examples * test(vrt): update visual snapshots for 423ff2e [skip ci] (#3762) Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com> * feat(slider): update disabled styles * test(vrt): update visual snapshots for fe4f441 [skip ci] (#3764) Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com> Co-authored-by: UberOpenSourceBot <33560951+UberOpenSourceBot@users.noreply.github.com> Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com>

view details

Bhavay Puri

commit sha 8caef4a76202b6f7c5e34e76b407a37cfe5b5ac1

fix(combobox, menu, popover, skeleton): overrides (#3765)

view details

Graham Murdoch

commit sha 58789f949a69c00920ea5c99396f0d0ca61f7dde

docs: remove guidelines prototype (#3769) * docs: remove guidelines prototype * fix: remove a few more things * fix: add back node-fetch

view details

Graham Murdoch

commit sha 5094cf80a782a0d168fd8ae11268a0dff44d2ff0

fix(radio): cleanup unused path (#3770)

view details

Tushar Moraye

commit sha bf42bc645014563bad363503746494b957d509ab

fix(nav-bar): fix spacing of navigation bar in rtl (#3754) Co-authored-by: Chase Starr <chasestarr@gmail.com>

view details

Graham Murdoch

commit sha 2417e08fd131462cca480d9a097261da62b19bec

fix(link): styletron component typescript (#3773)

view details

Konrad Kalemba

commit sha 2aadd314040365cf8c6cc96a73d9ff4c85be3990

fix(data-table): reflect applied filters correctly in datetime filter (#3776)

view details

Gergely Nemeth

commit sha d9fce32d8479cac2f938a3d760e85c873eaae977

Release v9.100.0 (#3778) 💯 💯 💯

view details

Graham Murdoch

commit sha 3753e66f8ab21b4ca3a3bf3f7c354d26dcf32897

feat(theme): export typescript theme properties (#3779)

view details

Chase Starr

commit sha bcf5b24e0df1affdcd937e3fb1ebbe48a3cdb793

feat(snackbar): initial layout (#3757) * feat(snackbar): initial layout * feat(snackbar): adds behavior * feat(snackbar): behaviors * feat(snackbar): element overrides * feat(snackbar): provider overrides * feat(snackbar): placement container overrides * feat(snackbar): dequeue snackbar on action click * feat(snackbar): tests * feat(snackbar): documentation * feat(snackbar): use theme values in snackbar * feat(snackbar): voiceover alert role * feat(snackbar): rtl layout * feat(snackbar): adds autofocus * fix(snackbar): lint * test(vrt): update visual snapshots for 282f9ce [skip ci] (#3780) Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com> * fix(snackbar): lint * fix(snackbar): update e2e due to animation time change * fix(snackbar): correct infinite duration example * fix(snackbar): make sure example does not auto focus * fix(snackbar): simplify autofocus implementation * fix(snackbar): tsc Co-authored-by: UberOpenSourceBot <33560951+UberOpenSourceBot@users.noreply.github.com> Co-authored-by: UberOpenSourceBot <UberOpenSourceBot@users.noreply.github.com>

view details

Chase Starr

commit sha 3d2217e9084104def9860903d2ca9765e0f29774

feat(menu): export the nested menu context (#3782)

view details

Chase Starr

commit sha c8d2a4ee35ddc82a6ff5451cf79e4a2e7850712c

Release v9.101.0 (#3783)

view details

Leyan Lo

commit sha 4dfe4b5d1b7d65fed05b4da57570515e1a17d05f

fix(link): avoid passing in animateUnderline as attribute (#3787) Avoid passing in animateUnderline as attribute. Otherwise results in warning: ``` Warning: React does not recognize the `animateUnderline` prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase `animateunderline` instead. If you accidentally passed it from a parent component, remove it from the DOM element. ``` Test Plan: Create a Link with animateUnderline prop and no longer see the warning.

view details

push time in 9 days

create barnchgadget-inc/baseweb

branch : build-033a21cc

created branch time in 9 days

startedplanety/prologue

started time in 9 days

create barnchairhorns/naught

branch : main

created branch time in 9 days

fork airhorns/naught

Zero downtime deployment for your Node.js server using builtin cluster API

fork in 9 days

startedvaleriansaliou/sonic

started time in 9 days

issue commentfastify/fastify-websocket

Start using FastifyRequest objects for the upgrade request so hooks fire and decorators can be used

I haven't made any progress on this but it is worth mentioning one bit of prior art from the Ruby world which is rack.hijack. I feel this pattern would be a good way to make this work in the Fastify world. Read more about rack hijack here: https://old.blog.phusion.nl/2013/01/23/the-new-rack-socket-hijacking-api/

airhorns

comment created time in 9 days

issue commentfastify/fastify-helmet

Missing example of how to use upgraded fastify-helmet with a style/script nonce

Is there a way to get back to the FastifyRequest instance from the http.IncomingMessage? If that was true, we could map the helmet options to pass handlers in that play nice with Helmet and accept http.IncomingMessages, and then make the jump back to the fastify objects and then pass those to the user handlers.

wolfejw86

comment created time in 9 days

issue commentUnitech/pm2

PM2 logs in docker

Anyone figured out how to get this to work? I think it only happens to some people when running in cluster for the exec_mode which is maybe why its hard to reproduce.

luisdavim

comment created time in 10 days

startedminio/simdjson-go

started time in 10 days

startedvoxpelli/node-pg-pubsub

started time in 10 days

issue commentyugabyte/yugabyte-db

[YSQL] Support GIN & GIST index methods

Just want to note another vote for this feature -- would be really amazing, especially when using JSONB fields to get a best-of-both-worlds SQL + NoSQL kind of system going.

robertpang

comment created time in 11 days

pull request commentdelvedor/find-my-way

Request based constraints implementation

I feel like the max version ordering for the semver store makes sense semantically and I think we shouldn't break it, but that is indeed annoying! Versions have an ordering where you can definitely sort one version as greater than another, but hosts don't, so I still think we need some other predictable way to sort the routes by a host constraint, and I think the most sensible way would be by addition order.

Would it be possible to just special case it? When there's more than one handler, check if there's a version constraint and use the max version if so, and otherwise just use the first one added?

AyoubElk

comment created time in 11 days

startedjaladankisuresh/thinktrans

started time in 11 days

startedbikeshaving/crank

started time in 13 days

starteddimforge/rapier.js

started time in 14 days

startedkubermatic/kubeone

started time in 15 days

pull request commentdelvedor/find-my-way

Request based constraints implementation

Ah right. Yeah, I think the first constraint matched makes sense to me!

AyoubElk

comment created time in 17 days

push eventgadget-inc/join-monster

Harry Brundage

commit sha c755902ee6dc9958fd8540297c898ecf3bf9297d

GraphQL v15 config via extensions (#418) * Switch to using GraphQL 15's extensions for join-monster config in a schema GraphQL 15 doesn't let schema authors attach arbitrary properties to schema objects anymore, so join-monster's config style has to change. There's an `extensions` property that works great for this, let's use that! * Update docs to reflect new extensions configuration setup * Bump join-monster version to indicate breaking change * Update TypeScript types to export strongly typed extension interfaces After https://github.com/graphql/graphql-js/pull/2465 , we can now use TypeScript declaration merging to augment the graphql-types nice and cleanly. Woop woop! * Add a changelog entry explaining how to migrate to the new extensions format * Fix a couple broken TypeScript types for thunking and add TypeScript tests

view details

Loren 🤓

commit sha ad1615ecce7d016ea1e1d7b9854af0957b5fa8e0

Release 3.0.0-alpha.1

view details

Loren 🤓

commit sha b4c54263355820ff0777052717b3fe93a9c164bd

Add v2 docs link to README

view details

dependabot[bot]

commit sha 0b4ccc2605a6ed6a6d1698d30dd7e3c2f3ae4648

Bump lodash from 4.17.15 to 4.17.19 (#420) Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

view details

Harry Brundage

commit sha 2220811127868d5743403d2902fade07d6e8c376

Accept orderings in arrays of {column, direction} for explicitness

view details

Harry Brundage

commit sha 8797f3d978af0647164d11eb3efa2b30a154f70b

Add support for multiple independent sortKeys for cursor pagination

view details

Enno Thoma

commit sha 57b3700d7f86deef708ded5b2b2d43c70cb36bbc

Merge pull request #421 from gadget-inc/multiple-sort-orders Multiple, independent, and ordered sortKey and orderBy directions

view details

Loren 🤓

commit sha 3d579f38508d8c5e23d79e6a12418e33e27ef7c8

Add note about npm tags to CONTRIBUTING

view details

Loren 🤓

commit sha 5d0dd042008621062a0646063b528b393ca7084e

Release v3.0.0-alpha.2

view details

Loren 🤓

commit sha 819cd03c8eca3421bf3008594ea84db8fad057d4

Update npm release instructions

view details

Harry Brundage

commit sha 4b6065e1afb5ccc4151ab4cf4b75710f8e05cd2e

Update TypeScript alwaysFetch definitions to permit arrays of column names

view details

Harry Brundage

commit sha f6980e5e1564a7469a79876da725fd4d4f490b4c

Add the ability for scalars to be powered by sqlTables join-monster excels at retrieving exactly the fields asked for by a given GraphQL query, but sometimes, there isn't an exact 1-1 correspondence between the desired fields in a GraphQL API and the table structure powering the system. Sometimes, data is normalized in the database or broken out into many tables for performance or reporting reasons or whatever, and join-monster supports these non 1-1 mappings fine with sqlExpr, alwaysFetch, and custom resolvers just fine, except when the "virtual" field is a scalar. I've ended up having to use a few custom scalars in my application, mostly from the `graphql-scalars` package as well as a couple other random ones, and I have one that is powered by a whole other table in the actual database schema. As an example, I have a `Post` object with normal fields that map to columns, but then a `tags` field on the Post that should return a string of tags, where the Tag is a custom scalar to apply some special parsing and formatting to the tag. The tags are stored in their own tags table in the database. To expose this using `join-monster`, I could create a whole new `GraphQLObjectType` to represent Tags and then have a `{name, id}` field or whatever, but I feel like that is changing the design of the API to accomodate join-monster (and GraphQL to an extent), instead of making the nicest API for developers, which would just be a plain old array of strings. So, I'd like to be able to do a `GraphQLList` of `Tag`, where `Tag` is a `new GraphQLScalar`, and have `join-monster` traverse that join and fetch my tags from the database. Turns out the only thing preventing this was the whitelist of types that `join-monster` looks for `sqlTable` on, so that's the only actual functional change in this PR. This is probably a pretty rare thing, but it's super handy for these custom scalars, as well as the JSON scalar escape hatch that folks might use to escape the strict typing shackles of GraphQL when they need to.

view details

Harry Brundage

commit sha f8e69ab44214bfae94a760a94018ca0930e9c022

Build

view details

push time in 17 days

pull request commentdelvedor/find-my-way

Request based constraints implementation

@AyoubElk which issue exactly would you like some input on, sorry, there's lots that's interesting!

Also, for this issue:

This works well, but would mean the user would have to provide any custom strategy using the new format (which is not as straight-forward as the first)

One potential solution you could explore would be to copy properties from the user-supplied object without a prototype to an internal object with a defined prototype at route definition time. At the expense of slightly increased startup time you'd get increased route lookup performance which I think is the right tradeoff to make.

AyoubElk

comment created time in 17 days

Pull request review commentdelvedor/find-my-way

Request based constraints implementation

 Node.prototype.addChild = function (node) {   return this } -Node.prototype.reset = function (prefix, versions) {+Node.prototype.reset = function (prefix, constraints) {   this.prefix = prefix   this.children = {}   this.kind = this.types.STATIC   this.handlers = new Handlers()   this.numberOfChildren = 0   this.regex = null   this.wildcardChild = null-  this.versions = versions+  this.kConstraints = new Set()+  this.constraintsStorage = constraints   return this }  Node.prototype.findByLabel = function (path) {   return this.children[path[0]] } -Node.prototype.findChild = function (path, method) {+Node.prototype.findMatchingChild = function (derivedConstraints, path, method) {   var child = this.children[path[0]]-  if (child !== undefined && (child.numberOfChildren > 0 || child.handlers[method] !== null)) {+  if (child !== undefined && (child.numberOfChildren > 0 || child.getMatchingHandler(derivedConstraints, method) !== null)) {     if (path.slice(0, child.prefix.length) === child.prefix) {       return child     }   }    child = this.children[':']-  if (child !== undefined && (child.numberOfChildren > 0 || child.handlers[method] !== null)) {+  if (child !== undefined && (child.numberOfChildren > 0 || child.getMatchingHandler(derivedConstraints, method) !== null)) {     return child   }    child = this.children['*']-  if (child !== undefined && (child.numberOfChildren > 0 || child.handlers[method] !== null)) {-    return child-  }--  return null-}--Node.prototype.findVersionChild = function (version, path, method) {

👍 nice cleanup

AyoubElk

comment created time in 17 days

Pull request review commentdelvedor/find-my-way

Request based constraints implementation

+'use strict'++const ConstraintsStore = require('./constraints-store')++const acceptVersionStrategy = require('./strategies/accept-version')+const acceptHostStrategy = require('./strategies/accept-host')++const DEFAULT_STRATEGIES_NAMES = ['version', 'host']++module.exports = (customStrategies) => {+  const strategies = [+    new acceptVersionStrategy(),+    new acceptHostStrategy()+  ]++  if (customStrategies) {+    for (let i = 0; i < customStrategies.length; i++) {+      const strategy = new customStrategies[i]()+      if (DEFAULT_STRATEGIES_NAMES.indexOf(strategy.name) !== -1) {+        strategies[i] = strategy+      } else {+        strategies.push(strategy)+      }+    }+  }++  return {+    storage: function () {+      const stores = {}+      for (var i = 0; i < strategies.length; i++) {+        stores[strategies[i].name] = strategies[i].storage()+      }+      return ConstraintsStore(stores)+    },+    deriveConstraints: function (req, ctx) {+      const derivedConstraints = {}

This is no longer a super hot path and only gets invoked once per route match, right? Maybe not worth it, but if you wanted to be really fancy, you could set up this object's prototype outside this object literal with the early-prototype-definition trick Fastify uses elsewhere and that you mentioned in a comment.

 module.exports = (customStrategies) => {
  const strategies = [
    new acceptVersionStrategy(),
    new acceptHostStrategy()
  ]

  if (customStrategies) {
    for (let i = 0; i < customStrategies.length; i++) {
      const strategy = new customStrategies[i]()
      if (DEFAULT_STRATEGIES_NAMES.indexOf(strategy.name) !== -1) {
        strategies[i] = strategy
      } else {
        strategies.push(strategy)
      }
    }
  }

  // Bang out a full prototype ahead of time
  const derivedConstraintsPrototype = class {};
  for (const strategy of strategies) {
    derivedConstraintsPrototype.prototype[strategy.name] = null
  }

  return {
    storage: function () {
      const stores = {}
      for (var i = 0; i < strategies.length; i++) {
        stores[strategies[i].name] = strategies[i].storage()
      }
      return ConstraintsStore(stores)
    },
    deriveConstraints: function (req, ctx) {
     const derivedConstraints = new derivedConstraintsPrototype()
     let value, hasConstraint = false
      for (var i = 0; i < strategies.length; i++) {
        value = strategies[i].deriveConstraint(req, ctx)
        if (value) {
          hasConstraint = true
          derivedConstraints[strategies[i].name] = value
        }
      }

      return hasConstraint ? derivedConstraints : null
    }
  }
}
AyoubElk

comment created time in 17 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventgadget-inc/join-monster

Harry Brundage

commit sha f6980e5e1564a7469a79876da725fd4d4f490b4c

Add the ability for scalars to be powered by sqlTables join-monster excels at retrieving exactly the fields asked for by a given GraphQL query, but sometimes, there isn't an exact 1-1 correspondence between the desired fields in a GraphQL API and the table structure powering the system. Sometimes, data is normalized in the database or broken out into many tables for performance or reporting reasons or whatever, and join-monster supports these non 1-1 mappings fine with sqlExpr, alwaysFetch, and custom resolvers just fine, except when the "virtual" field is a scalar. I've ended up having to use a few custom scalars in my application, mostly from the `graphql-scalars` package as well as a couple other random ones, and I have one that is powered by a whole other table in the actual database schema. As an example, I have a `Post` object with normal fields that map to columns, but then a `tags` field on the Post that should return a string of tags, where the Tag is a custom scalar to apply some special parsing and formatting to the tag. The tags are stored in their own tags table in the database. To expose this using `join-monster`, I could create a whole new `GraphQLObjectType` to represent Tags and then have a `{name, id}` field or whatever, but I feel like that is changing the design of the API to accomodate join-monster (and GraphQL to an extent), instead of making the nicest API for developers, which would just be a plain old array of strings. So, I'd like to be able to do a `GraphQLList` of `Tag`, where `Tag` is a `new GraphQLScalar`, and have `join-monster` traverse that join and fetch my tags from the database. Turns out the only thing preventing this was the whitelist of types that `join-monster` looks for `sqlTable` on, so that's the only actual functional change in this PR. This is probably a pretty rare thing, but it's super handy for these custom scalars, as well as the JSON scalar escape hatch that folks might use to escape the strict typing shackles of GraphQL when they need to.

view details

push time in 17 days

PR opened join-monster/join-monster

Add the ability for scalars to be powered by sqlTables

join-monster excels at retrieving exactly the fields asked for by a given GraphQL query, but sometimes, there isn't an exact 1-1 correspondence between the desired fields in a GraphQL API and the table structure powering the system. Sometimes, data is normalized in the database or broken out into many tables for performance or reporting reasons or whatever, and join-monster supports these non 1-1 mappings fine with sqlExpr, alwaysFetch, and custom resolvers just fine, except when the "virtual" field is a scalar.

I've ended up having to use a few custom scalars in my application, mostly from the graphql-scalars package as well as a couple other random ones, and I have one that is powered by a whole other table in the actual database schema. As an example, I have a Post object with normal fields that map to columns, but then a tags field on the Post that should return a string of tags, where the Tag is a custom scalar to apply some special parsing and formatting to the tag. The tags are stored in their own tags table in the database. To expose this using join-monster, I could create a whole new GraphQLObjectType to represent Tags and then have a {name, id} field or whatever, but I feel like that is changing the design of the API to accomodate join-monster (and GraphQL to an extent), instead of making the nicest API for developers, which would just be a plain old array of strings.

So, I'd like to be able to do a GraphQLList of Tag, where Tag is a new GraphQLScalar, and have join-monster traverse that join and fetch my tags from the database. Turns out the only thing preventing this was the whitelist of types that join-monster looks for sqlTable on, so that's the only actual functional change in this PR.

This is probably a pretty rare thing, but it's super handy for these custom scalars, as well as the JSON scalar escape hatch that folks might use to escape the strict typing shackles of GraphQL when they need to.

+337 -10

0 comment

18 changed files

pr created time in 17 days

create barnchgadget-inc/join-monster

branch : scalar-tables

created branch time in 17 days

issue openedwhitecolor/ts-node-dev

Feature request: forked type-checker with transpile-only on

Past a certain size it gets pretty unbearable to wait for TypeScript to typecheck and compile the whole project on every startup / restart. The ts-node-dev readme suggests running with --transpile-only for these bigger projects, which speeds things up by skipping the typechecking, and just transpiles into JS to hand to node.

Webpack users building for the browser often end up doing similar, but they add typechecking back in an out of band, second process using https://www.npmjs.com/package/fork-ts-checker-webpack-plugin . This lets you have the cake and eat it too: you get fast reloads from the transpile-only method, and then you get the results of the typecheck soon after once it has completed. It's more memory intensive and means that everything is actually being compiled twice, but I think it would be great to offer this functionality to developers if they wanted it.

So, I propose a new flag along the lines of --fork-typecheck or something like that that would run a full-blown typechecker in another thread or process while the foreground one continues it's snappy --transpile-onlying for fast developer feedback.

created time in 18 days

startedcmu-db/noisepage

started time in 22 days

pull request commentdelvedor/find-my-way

Request based constraints implementation

Been talking with @AyoubElk off platform, want to post some answers here so all can see:

Considering these two routes

router.on('GET', '/users', { constraints: { version: '1.0.0' } }, handler)
router.on('GET', '/users', { constraints: { host: 'auth.airhorns.dev' } }, handler2)

Should this scenario be possible? If so, and given a request that can match both, which one should be matched?

For a request that could match both of the constraint sets, I think we should match what fastify does now for route matching precedence, which is just use whichever route is matched first. I forget if it's the first defined route or the last defined route, but, there is an ordering in which the routes were all required and registered and I assume some existing semantics for in what order the routes are tested. If those semantics don't exist already and it's undefined behaviour, then I think we should actually match that too in order to not make a bigger breaking change. I hope it doesn't depend on object key insertion order, though that is stable in node now.

In a similar vein, if the user can declare multiple routes with the same method/path but different constraints for each, I'd assume we'll match the most restrictive route: In this case, if route 1 (has 1 constraint) and route 3 (has 2 constraints) match the request, we'll use the 3rd:

router.on('GET', '/users', { constraints: { version: '1.0.0' } }, handler)
router.on('GET', '/users', { constraints: { host: 'admin.airhorns.dev' } }, handler2)
router.on('GET', '/users', { constraints: { host: 'auth.airhorns.dev', version: '1.0.0' } }, handler3)

In the previous example however, we have 1 constraint for each one of the routes, so we can't base the matching on the number of constraints. Maybe the order of the routes should then be used and go with the last defined route?

I'd say the same thing: match the first route checked that passes the constraint checks, and then hopefully there's already a well defined order that routes are checked in. I think any other algorithm around most restrictive is going to be unpredictable and therefore surprising because restrictive might mean different things to different people. I think as a developer if I defined two routes in a file, and then added a constraint to the second route, which caused it to start getting checked first and matched first, I'd be surprised.

FWIW this ordered route matching how the Rails router works, I am a one trick pony when it comes to this kind of thing.

AyoubElk

comment created time in 22 days

push eventgadget-inc/blog

Harry Brundage

commit sha 12e1e07f8a73f8eb6071255b851d522f8afe17cc

Truckin' along

view details

push time in 23 days

issue commenttweedegolf/storage-abstraction

Impossible to add parameters while storing a file

Plus one for this!

lambertkevin

comment created time in 24 days

startedtweedegolf/storage-abstraction

started time in 24 days

issue commentseaweedfs/seaweedfs-csi-driver

`weed mount` logs can't be read

Ah, bumping up the verbosity helped, found a No free volumes left! message, and bumped up the max volumes from the default helm chart output and all is working now. Sorry for the red herring!

airhorns

comment created time in 24 days

issue closedseaweedfs/seaweedfs-csi-driver

`weed mount` logs can't be read

I'm struggling a bit to get volumes in my k8s cluster working properly, and I am sure it is something I have done wrong, but debugging it is difficult because I can't see what weed mount might be reporting as an issue, but I can see the CSI attacher running it. Would there be anything wrong with forwarding the logs from the managed weed mount command to the stdout/err of the CSI components running it to assist with debugging?

closed time in 24 days

airhorns

delete branch gadget-inc/pika-plugin-esbuild

delete branch : master

delete time in 24 days

create barnchgadget-inc/pika-plugin-esbuild

branch : main

created branch time in 24 days

issue commentseaweedfs/seaweedfs-csi-driver

`weed mount` logs can't be read

Ah, I took a look through the code and didn't see where it would be doing that, but maybe my Go-fu is just not strong enough. Right now when I try to write to a file on a CSI-mounted seaweed volume the process trying to write hangs indefinitely. I can create files with touch just fine which I think means the filer and FUSE mount are working, but writing any bytes to files causes the writing process to go unresponsive, and doesn't seem to log anything on the filer, on the volume servers, or on any of the csi-seaweedfs-node DaemonSet pods. Does the verbosity have to be upped from the default to get the log entries maybe?

airhorns

comment created time in 24 days

delete branch airhorns/light-my-request

delete branch : socket-event-emitter

delete time in 24 days

issue commentsteveruizok/perfect-arrows

Arrows from a box back to itself don't look so good

@steveruizok is this something that you're planning on tackling sometime soon? No worries if not -- I can start work on a PR! If you have something half baked or almost done I would love to help push it past the finish line!

airhorns

comment created time in 25 days

issue openedseaweedfs/seaweedfs-csi-driver

`weed mount` logs can't be read

I'm struggling a bit to get volumes in my k8s cluster working properly, and I am sure it is something I have done wrong, but debugging it is difficult because I can't see what weed mount might be reporting as an issue, but I can see the CSI attacher running it. Would there be anything wrong with forwarding the logs from the managed weed mount command to the stdout/err of the CSI components running it to assist with debugging?

created time in 25 days

PR opened fastify/light-my-request

Expose a mock socket that is an EventEmitter like a real one would be

Before this change, if a Fastify user attached an onTimeout hook to their server, an error would be thrown in test mode when injecting requests with light-my-request

TypeError: request.raw.socket.on is not a function

      at Object.routeHandler [as handler] (../../node_modules/fastify/lib/route.js:350:28)
      at Router.lookup (../../node_modules/find-my-way/index.js:356:14)
      at ../../node_modules/light-my-request/index.js:101:38
      at Request.prepare (../../node_modules/light-my-request/lib/request.js:110:12)
      at ../../node_modules/light-my-request/index.js:101:11
      at doInject (../../node_modules/light-my-request/index.js:97:12)
      at Chain.<computed> [as then] (../../node_modules/light-my-request/index.js:187:23)
          at runMicrotasks (<anonymous>)

This fixes the socket object to have an on function (as well as the rest of the EventEmitter interface) so that things that add timeout handlers can at least add them without erroring. This doesn't implement actual timeout injection, but I think that could be done in userland by emitting events on the socket manually.

Similar to #99.

+29 -3

0 comment

2 changed files

pr created time in 25 days

create barnchairhorns/light-my-request

branch : socket-event-emitter

created branch time in 25 days

fork airhorns/light-my-request

Fake HTTP injection library

fork in 25 days

issue commentfastify/fastify-server-timeout

No way to know when a request times out or which one did

Ah, ok, my apologies for the extra noise, the fastify core way preserves the context explicitly and seems to solve this better so I'd agree!

airhorns

comment created time in a month

issue commentfastify/fastify-server-timeout

No way to know when a request times out or which one did

Oh, no I didn't see that! Does that mean this plugin doesn't need to exist anymore?

airhorns

comment created time in a month

issue openedfastify/fastify-server-timeout

No way to know when a request times out or which one did

It'd be great to get visibility into when requests are timing out and which ones are being timed out for operators to debug and fix timeouts. They're not supposed to happen, and give a really crap experience for a user, so providing devs with the ability to investigate why a timeout happened I think is pretty important.

The http.Server just emits a timeout event when a timeout happen, but this library nor anything else seem to listen to it by default, so there's no log entry or hook point for developers to do stuff when a request does time out. See https://nodejs.org/api/http.html#http_server_settimeout_msecs_callback .

Happy to PR something to add this, but it's a little tricky to know what to do exactly. Ideally, there'd be a log message routed through the normal fastify request logger reporting that the request timed out with all the logger's properties (like the request ID and any other stuff that the developer added). I am not really sure how to get a handle on the fastify request that did time out though, because this library implements the timeout at the node socket level, which passes the plain old socket object to the event handlers, not the fastify request or anything. Is there a way to get the request from the socket in order to get a handle on that async context for logging? Or, is there a better way to implement this timeout closer to fastify instead of at the http level that would allow us to keep that context around?

created time in a month

delete branch airhorns/seaweedfs-csi-driver

delete branch : patch-1

delete time in a month

pull request commentseaweedfs/seaweedfs-csi-driver

Update CSI yaml to allow using k8s service DNS to contact the filer

Ah shoulda mentioned that -- the controller StatefulSet works fine with hostnames already because it's not using hostNetwork: true, so it's running inside the pod networking context that already uses the in-cluster DNS. It's just the node DaemonSet that is using hostNetwork: true.

airhorns

comment created time in a month

PR opened seaweedfs/seaweedfs-csi-driver

Update CSI yaml to allow using k8s service DNS to contact the filer

I think lots of users are going to use the CSI driver with a seaweedfs cluster also running in k8s. The natural way to connect the driver to that cluster would be using DNS instead of hard coded IPs, so I set SEAWEEDFS_FILER to something like seaweedfs-filer.seaweed-namespace.svc:8888, which the driver kept timing out trying to connect. I realized the driver was running using hostNetwork: true, which means the in-cluster DNS resolution doesn't happen, so the .svc hostnames are just unresolved.

This changes the default YAML for the next person coming along to use the in-cluster DNS resolution first, and then the host's DNS resolution, so that if the filer happens to be running the cluster, it can be connected from the driver running on the host.

An alternative would be to not use hostNetworking for the driver daemonset, but I am presuming that's there for a reason.

+3 -2

0 comment

1 changed file

pr created time in a month

push eventairhorns/seaweedfs-csi-driver

Harry Brundage

commit sha d1ebf58fcff4e217488ba5ef5aa3573ca7d9a9bf

Update CSI yaml to allow using k8s service DNS to contact the filer I think lots of users are going to use the CSI driver with a seaweedfs cluster also running in k8s. The natural way to connect the driver to that cluster would be using DNS instead of hard coded IPs, so I set `SEAWEEDFS_FILER` to something like `seaweedfs-filer.seaweed-namespace.svc:8888`, which the driver kept timing out trying to connect. I realized the driver was running using `hostNetwork: true`, which means the in-cluster DNS resolution doesn't happen, so the .svc hostnames are just unresolved. This changes the default YAML for the next person coming along to use the in-cluster DNS resolution first, and then the host's DNS resolution, so that if the filer happens to be running the cluster, it can be connected from the driver running on the host. An alternative would be to not use `hostNetworking` for the driver daemonset, but I am presuming that's there for a reason.

view details

push time in a month

fork airhorns/seaweedfs-csi-driver

SeaweedFS CSI Driver https://github.com/chrislusf/seaweedfs

fork in a month

push eventairhorns/esbuild-jest

Harry Brundage

commit sha 7cb432073d379ceaede0e9b1e91c020f6662aca5

Commit build package for consumption

view details

push time in a month

create barnchairhorns/esbuild-jest

branch : gadget-hacks

created branch time in a month

fork airhorns/esbuild-jest

A Jest transformer using esbuild

fork in a month

startedaelbore/esbuild-jest

started time in a month

issue commentprisma/prisma-client-js

Stronger support for transaction management

Is there any guidance we could get from the Prisma team if this is a feature you folks are considering adding, or is the current $transaction support as far as you're going to take it? I feel like some of us might adopt Prisma now knowing transaction support is coming in the future, or might not adopt knowing it's not coming ever or for a very long time.

brafdlog

comment created time in a month

startedVictoriaMetrics/VictoriaMetrics

started time in a month

more