a node.js application written for the mcgill codejam in 48 hours
Give your JS App some Backbone with Models, Views, Collections, and Events
Fighting Crime and Kicking Apps
Easily use batman.js with Rails 3.1
Teensy node service for receiving BLE beacons and firing them onto an MQTT bus
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
commit sha a0e8905548f7aa67d8a5f5ff2417449b1cef6a41
Add function names to route handler pretty print if they are present
push time in 20 hours
PR opened delvedor/find-my-way
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.
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! 🥳
comment created time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
push time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
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?
comment created time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
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)
comment created time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
push time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
push time in 2 days
push eventairhorns/find-my-way
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 > [email protected] 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) > [email protected] 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) ```
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 :)
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.
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
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?
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.
comment created time in 2 days
push eventairhorns/find-my-way
commit sha 6170204c26bcb6fb9f6d46320d8c11785c483257
Add constrained route pretty printing
push time in 3 days
push eventairhorns/find-my-way
commit sha 57e7a6d6f1bb26ac3239bbfd839c81311e3dd9a4
Add some couple realistic routes and benchmarks for a REST API
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 > [email protected] 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) > [email protected] 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) ```
commit sha a0232ed9f54dbba148e39d0a3751157c544e11e7
Merge branch 'one-tree-per-method' into constraints
push time in 3 days
PR opened delvedor/find-my-way
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) |
pr created time in 3 days
push eventairhorns/find-my-way
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
push time in 3 days
push eventgadget-inc/deploy-container
commit sha ee60651b0745ee37a1a18d70ea8569be2cef560e
Use a hacked up version of krane for newer gke support
commit sha 1640fc0459026e96d6ec111d188db7534d4fd21f
Upgraded krane
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?
comment created time in 6 days
PR opened Shopify/krane
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.
pr created time in 6 days
push eventairhorns/krane
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
push time in 6 days
PR opened mkinoshi/fastify-opentelemetry
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.
pr created time in 6 days
push eventairhorns/fastify-opentelemetry
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.
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!
comment created time in 8 days
issue commentShopify/krane
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.
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
I think the user's options still need to be respected in some instances, like the JSX pragma or the tslib stuff, no?
comment created time in 8 days
push eventgadget-inc/baseweb
commit sha 94e3279d50f76ca5d06a170c0f033d5309dc28cd
fix(input): add missing clearOnEscape prop to TypeScript types
commit sha 9fd97e9a64224edd8da469e464049eee985d7ec6
Merge branch 'add-clear-on-escape-to-input' into gadget-hacks
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 <[email protected]> * fix(data-table): lint Co-authored-by: UberOpenSourceBot <[email protected]> Co-authored-by: UberOpenSourceBot <[email protected]>
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 <[email protected]> * 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 <[email protected]>
commit sha 64033ed0a402780e2cbf14507a308157db97206a
fix(styletron): relax styletron-component (#3759)
commit sha 43a6ea3708b334b3a06d40c2efb3562d924e55f3
fix(input): add missing clearOnEscape prop to TypeScript types (#3756)
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
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 <[email protected]> * feat(slider): update disabled styles * test(vrt): update visual snapshots for fe4f441 [skip ci] (#3764) Co-authored-by: UberOpenSourceBot <[email protected]> Co-authored-by: UberOpenSourceBot <[email protected]> Co-authored-by: UberOpenSourceBot <[email protected]>
commit sha 8caef4a76202b6f7c5e34e76b407a37cfe5b5ac1
fix(combobox, menu, popover, skeleton): overrides (#3765)
commit sha 58789f949a69c00920ea5c99396f0d0ca61f7dde
docs: remove guidelines prototype (#3769) * docs: remove guidelines prototype * fix: remove a few more things * fix: add back node-fetch
commit sha 5094cf80a782a0d168fd8ae11268a0dff44d2ff0
fix(radio): cleanup unused path (#3770)
commit sha bf42bc645014563bad363503746494b957d509ab
fix(nav-bar): fix spacing of navigation bar in rtl (#3754) Co-authored-by: Chase Starr <[email protected]>
commit sha 2417e08fd131462cca480d9a097261da62b19bec
fix(link): styletron component typescript (#3773)
commit sha 2aadd314040365cf8c6cc96a73d9ff4c85be3990
fix(data-table): reflect applied filters correctly in datetime filter (#3776)
commit sha d9fce32d8479cac2f938a3d760e85c873eaae977
Release v9.100.0 (#3778) 💯 💯 💯
commit sha 3753e66f8ab21b4ca3a3bf3f7c354d26dcf32897
feat(theme): export typescript theme properties (#3779)
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 <[email protected]> * 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 <[email protected]> Co-authored-by: UberOpenSourceBot <[email protected]>
commit sha 3d2217e9084104def9860903d2ca9765e0f29774
feat(menu): export the nested menu context (#3782)
commit sha c8d2a4ee35ddc82a6ff5451cf79e4a2e7850712c
Release v9.101.0 (#3783)
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.
push time in 9 days
startedplanety/prologue
started 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/
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.
comment created time in 9 days
issue commentUnitech/pm2
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.
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.
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?
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!
comment created time in 17 days
push eventgadget-inc/join-monster
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
commit sha ad1615ecce7d016ea1e1d7b9854af0957b5fa8e0
Release 3.0.0-alpha.1
commit sha b4c54263355820ff0777052717b3fe93a9c164bd
Add v2 docs link to README
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] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
commit sha 2220811127868d5743403d2902fade07d6e8c376
Accept orderings in arrays of {column, direction} for explicitness
commit sha 8797f3d978af0647164d11eb3efa2b30a154f70b
Add support for multiple independent sortKeys for cursor pagination
commit sha 57b3700d7f86deef708ded5b2b2d43c70cb36bbc
Merge pull request #421 from gadget-inc/multiple-sort-orders Multiple, independent, and ordered sortKey and orderBy directions
commit sha 3d579f38508d8c5e23d79e6a12418e33e27ef7c8
Add note about npm tags to CONTRIBUTING
commit sha 5d0dd042008621062a0646063b528b393ca7084e
Release v3.0.0-alpha.2
commit sha 819cd03c8eca3421bf3008594ea84db8fad057d4
Update npm release instructions
commit sha 4b6065e1afb5ccc4151ab4cf4b75710f8e05cd2e
Update TypeScript alwaysFetch definitions to permit arrays of column names
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.
commit sha f8e69ab44214bfae94a760a94018ca0930e9c022
Build
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.
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
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
}
}
}
comment created time in 17 days
push eventgadget-inc/join-monster
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.
push time in 17 days
PR opened join-monster/join-monster
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.
pr created 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.
comment created time in 22 days
push eventgadget-inc/blog
commit sha 12e1e07f8a73f8eb6071255b851d522f8afe17cc
Truckin' along
push time in 23 days
issue commenttweedegolf/storage-abstraction
Impossible to add parameters while storing a file
Plus one for this!
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!
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
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?
comment created 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!
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
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.
pr created time 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!
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?
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
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.
comment created time in a month
PR opened seaweedfs/seaweedfs-csi-driver
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.
pr created time in a month
push eventairhorns/seaweedfs-csi-driver
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.
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
commit sha 7cb432073d379ceaede0e9b1e91c020f6662aca5
Commit build package for consumption
push time in a month
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.
comment created time in a month
startedVictoriaMetrics/VictoriaMetrics
started time in a month
issue commentsteveruizok/perfect-arrows
Arrows to small boxes next to big boxes unnecessarily cross the big box
Thanks Steve!!
comment created time in a month