|
haproxy can't route http requests, can it? nginx forwarding to node.js is fine
|
# ? Feb 12, 2017 22:03 |
|
|
# ? Jun 1, 2024 05:13 |
|
I use varnish for that role. I like varnish
|
# ? Feb 12, 2017 22:07 |
|
Suspicious Dish posted:haproxy can't route http requests, can it? nginx forwarding to node.js is fine It can do some really wild poo poo and I think it should just be in front of everything and anything. Wouldn't be hard to have it route to nginx by subdomain or something if you don't feel like parsing URIs. I have haproxy terminating LetsEncrypt tls and splitting http and websockets between nginx and node.js. This lets me have both the (nginx+php served) pages and (node.js game server) websocket both on 80 or 443, so as long as you can hit the page you can hit the game server too instead of being on some strange port, and I don't have to touch certs in either nginx or node. I'm still a filthy PHP user for normal scripty request antics though. Node is almost strictly a websocket application server for me, for shared javascript between client and server. "Do one thing and do it well" right? Ranzear fucked around with this message at 00:07 on Feb 13, 2017 |
# ? Feb 12, 2017 23:30 |
|
Haproxy can proxy basically anything. We used it for http and DB replica routing. And people use node because they know front end JS so how bad can it be in the backend. When they say content like HTML I assume it's generated after hitting the DB.
|
# ? Feb 13, 2017 02:29 |
|
The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter).
|
# ? Feb 13, 2017 16:37 |
|
Another benefit is great plugins like Naxsi to help prevent a bunch of attacks.
|
# ? Feb 13, 2017 17:18 |
|
edit: wow wrong page
|
# ? Feb 13, 2017 18:14 |
|
Munkeymon posted:The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter). And even when you do that you should pipe it through to X-SendFile features to avoid the slower scripting Lang doing the file serving.
|
# ? Feb 13, 2017 22:18 |
|
Munkeymon posted:The only use case I can think of for writing even one line of code to serve a static file is to restrict access to the file in some way and I don't understand why people are weirded out by using nginx with Node (or Python or Ruby for that matter). it's not that nginx is bad. nginx is great. the problem is that anything is great behind nginx. if node really scaled, then nginix would be a nice-to-have instead of a requirement.
|
# ? Feb 15, 2017 13:40 |
|
Is Comet still a thing that exists and people have even heard of? Or should I be using websockets now, or some other thing for server push functionality. The application is that I want to stream binary data from server to clientside script and visualize it in realtime. The data is from an accelerometer with up to 3200 samples/s, similar to a raw audio stream. I'm looking for minimal latency, minimal bandwidth overhead, and high update rate.
|
# ? Feb 15, 2017 17:41 |
|
peepsalot posted:The data is from an accelerometer with up to 3200 samples/s, similar to a raw audio stream. Now there's a term I haven't heard in a long time. Websocket is the way to go, yes, but regardless of whether a websocket could handle such data (it totally can), do you really need to display 3200 samples a second? If not, 120/second is nothing to a websocket and enough for anybody. Else, pack some few ms worth of samples together and throw them across to save some overhead. If they're already in a JS datastructure of any sort, JSON them and chuck them across as strings, no sweat. Websockets are supposed to do binary streams too, but most browser websocket APIs are ... futzy about it.
|
# ? Feb 16, 2017 04:32 |
|
Ranzear posted:Do you really need to display 3200 samples a second? If not, 120/second is nothing to a websocket and enough for anybody. Else, pack some few ms worth of samples together and throw them across to save some overhead. The purpose of this project is to act more or less like a digital storage oscilloscope. How many of those samples are visible at any given time is dependent on how much the user is zoomed in, and if it is autoscrolling but either way I need to capture all samples so that there can be an option to save a full log to disk, or to pause and zoom in on a particular event, scroll through different points in time etc. The data is coming from a microcontroller (esp8266) so all data is raw binary with minimal processing so as not to overload the MCU with JSON processing etc.
|
# ? Feb 16, 2017 21:49 |
|
peepsalot posted:The purpose of this project is to act more or less like a digital storage oscilloscope. How many of those samples are visible at any given time is dependent on how much the user is zoomed in, and if it is autoscrolling but either way I need to capture all samples so that there can be an option to save a full log to disk, or to pause and zoom in on a particular event, scroll through different points in time etc. You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself.
|
# ? Feb 16, 2017 22:01 |
|
Skandranon posted:You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself. You absolutely would not want to use the DOM for this, however if you've got the stomach for it you should be able to make some canvas WebGL stuff that would fit the bill. As far as storage goes you can fit a whole lotta gigs in the indexeddb.
|
# ? Feb 16, 2017 22:27 |
|
I thought indexeddb storage limits varied pretty wildly because unrestricted size databases in browsers is insanely stupid. Like from 5 to 10mb not gigabytes
|
# ? Feb 17, 2017 02:17 |
|
Oh right you can request an arbitrary amount for private ones or whatever. So not a guarantee.
|
# ? Feb 17, 2017 02:19 |
|
Anyone have any suggestions or experience with a comprehensive(ish) component library? Anything like http://www.material-ui.com/ There's plenty of libraries with specialized components, but I can't seem to find many larger, more generalized libraries like Material-UI
|
# ? Feb 17, 2017 17:12 |
|
Bruegels Fuckbooks posted:I'm just going to post this without comment: Besides being poorly written, this article does a poor job explaining how exactly serving static files locks the thread that processes the event loop. Is it assuming you (or Express's middleware) are reading the files synchronously?
|
# ? Feb 17, 2017 23:02 |
|
ROFLburger posted:Besides being poorly written, this article does a poor job explaining how exactly serving static files locks the thread that processes the event loop. Is it assuming you (or Express's middleware) are reading the files synchronously? the article is terrible. one of the selling points of node.js is that it's supposed to be good at serving a high number of requests that don't use a lot of cpu, and using asynchronous IO instead of threads to read files is supposed to be like, beneficial and poo poo. then you read more and people are like "don't use it to serve static files, it's not as good as etc. etc." it's a bunch of bs.
|
# ? Feb 18, 2017 03:40 |
|
Skandranon posted:You will likely run into issues if you try updating the DOM every 0.31ms. If you need that data at that granularity, I'd do batch updates via websocket every few 100ms, and do DOM updates then. Also, watch out for running out of memory. Chromes V8 engine can only allocate ~1.5gb of memory to a single tab before making GBS threads itself. I'm asking only about the mechanism of data transfer, from server to client. I'm looking into websockets, right now I'm confused that there seems to be two different ways to send over WebSocket: Blob or ArrayBuffer? But you have to read both via a DataView anyways, or something? When would you choose one over the other?
|
# ? Feb 18, 2017 17:35 |
|
What lightbox/slideshow/photo gallery library is everyone using these days? Preferably mobile-friendly with a license that permits redistribution.
|
# ? Feb 23, 2017 11:51 |
|
peepsalot posted:I'm looking into websockets, right now I'm confused that there seems to be two different ways to send over WebSocket: Blob or ArrayBuffer? But you have to read both via a DataView anyways, or something? When would you choose one over the other? Blobs are immutable, can have MIME types, and can be used as a source for URLs (image sources, file downloads, etc). ArrayBuffers are basically an array of ints that can be monkeyed with using appropriate TypedArrays or DataViews (usually using uint8 to access as an array of 8-bit bytes). For most purposes you'll want to use ArrayBuffers internally (possibly with a helper lib like feross/buffer), and generate a Blob from that if you're specifically doing a file download thing or whatever at some point. Roadie fucked around with this message at 01:59 on Feb 24, 2017 |
# ? Feb 23, 2017 19:57 |
|
I'm writing a library function that changes the src of a <img> and does something when it loads. I'm looking at http://stackoverflow.com/a/2342181 and worrying about the possibility of the previous src finishing loading at just the right moment to trigger my new handler. Is that possible? If so what should I do? edit: Screw it, I'll just poll img.complete instead. Xom fucked around with this message at 01:01 on Feb 27, 2017 |
# ? Feb 26, 2017 23:52 |
|
Xom posted:I'm writing a library function that changes the src of a <img> and does something when it loads. I'm looking at http://stackoverflow.com/a/2342181 and worrying about the possibility of the previous src finishing loading at just the right moment to trigger my new handler. Is that possible? If so what should I do? what exactly are you trying to do? you can just script it to not trigger if something is already triggering it by using a variable as a flag/lock.
|
# ? Feb 27, 2017 03:50 |
|
I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with. What I'm imagining, though I'm not familiar enough with web development to know for sure if it is possible, is that I set the handler, then <img src="Sigmund.png"> finishes loading, then I set the src to data:bLaHbLaHbLaH, then from the trigger from the original Sigmund.png tells me to continue on to invoke dom-to-image, even though it was the dataUrl that I intended to listen for. Admittedly, my concern here is somewhat academic, given that _.defer is enough of a wait most of the time.
|
# ? Feb 27, 2017 04:54 |
|
Xom posted:I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with. Could you simply have a 2nd image tag that is invisible? This would allow you to keep your handlers separate.
|
# ? Feb 27, 2017 06:34 |
|
Xom posted:I'm working on http://www.cardery.org/ which uses dom-to-image to convert DOM elements to PNG. Something about the way dom-to-image inlines images causes Firefox to blank out images from file:///. If I reimplement this step myself, then Firefox lets the file:/// images through if they're in the same folder. (Chrome doesn't let them through in any case.) But if I don't wait for a tiny moment before continuing on to invoking dom-to-image, then the output still has blanks where the images were. If I do wait for a moment, such as by using lodash.defer, then I mostly don't get blanked. Naturally I would like to wait for as few milliseconds as I can get away with. What I don't really get is why you're jiggering around in-place with stuff that's in the visible output of the page. Even if dom-to-image requires a visible element, you could use "workspace" stuff positioned outside the viewport (e.g. position: absolute; left: -10000px type wrapper), append a new node for each conversion, and delete that specific node and add the result to the visible viewport in the result callback. Edit: Wait, maybe now I think I get what you mean. Why make the image tags like that and then alter them after they're already in place? I don't really get why it's file source to data source, instead of waiting, generating a new Image() when you have the data URL, and adding that to the right node. Roadie fucked around with this message at 07:02 on Feb 27, 2017 |
# ? Feb 27, 2017 06:59 |
|
Roadie posted:What I don't really get is why you're jiggering around in-place with stuff that's in the visible output of the page. Even if dom-to-image requires a visible element, you could use "workspace" stuff positioned outside the viewport (e.g. position: absolute; left: -10000px type wrapper), append a new node for each conversion, and delete that specific node and add the result to the visible viewport in the result callback. dom-to-image uses an SVG feature that allows you to embed HTML into an SVG and I'm guessing there are protections around using that to hide access to file:// URLs. Sounds like a way around that is to replace every file:// URL with a data: URL with the same content before trying to make the SVG turduckin. I've done a thing that waited for a bunch of images to load before and IIRC, I put a handler on all of their onload events and counted the handlers as they were created. Then each handler decremented the counter until it was zero which allowed the last one to run a callback, which would make the dom-to-image call in this case. Pretty sure the modern way would be to wrap all of that in a promise.
|
# ? Feb 27, 2017 17:12 |
|
Munkeymon posted:dom-to-image uses an SVG feature that allows you to embed HTML into an SVG and I'm guessing there are protections around using that to hide access to file:// URLs. Sounds like a way around that is to replace every file:// URL with a data: URL with the same content before trying to make the SVG turduckin. Right. What I mean is (now that I've got my head more wrapped around it), it'd be better to do that file url to data url step before even creating the DOM nodes that get run through dom-to-image. code:
Roadie fucked around with this message at 19:46 on Feb 27, 2017 |
# ? Feb 27, 2017 19:27 |
|
Turns out dom-to-image already does element.onload = resolve; element.src = dataUrl, which implies onload doesn't necessarily avert my problem. I don't feel like investigating, so I'll take my chances with setTimeout. I don't want to bother the user about dataUrls. I can handle it in the library. The user shouldn't have to do anything special.
|
# ? Mar 1, 2017 06:39 |
|
What does Google docs use for screenshots in the help system, is it something like dom-to-image?
|
# ? Mar 1, 2017 16:27 |
|
MrMoo posted:What does Google docs use for screenshots in the help system, is it something like dom-to-image? They wrote a mostly-complete DOM to canvas renderer in JS, if it's the reporting system I remember reading about.
|
# ? Mar 1, 2017 17:42 |
|
Is there a way to display an image at its actual resolution, ignoring the user's OS zoom and/or browser zoom, showing one image pixel per monitor pixel?
|
# ? Mar 1, 2017 17:58 |
|
Xom posted:Is there a way to display an image at its actual resolution, ignoring the user's OS zoom and/or browser zoom, showing one image pixel per monitor pixel? window.devicePixelRatio will give you the ratio of device pixels to CSS pixels. If you use that to scale the image's size, you can make it map image pixels directly to monitor pixels. Careful though, as the documentation mentions, this value can change (i.e., if the user moves the window between monitors of different DPI levels), and there's no event to tell you the value has changed.
|
# ? Mar 1, 2017 22:34 |
|
biznatchio posted:window.devicePixelRatio will give you the ratio of device pixels to CSS pixels. If you use that to scale the image's size, you can make it map image pixels directly to monitor pixels. Careful though, as the documentation mentions, this value can change (i.e., if the user moves the window between monitors of different DPI levels), and there's no event to tell you the value has changed. Yeah, but the output image will still be scaled and have scaling artifacts unfortunately. It comes pretty close.
|
# ? Mar 2, 2017 02:00 |
|
Bruegels Fuckbooks posted:Yeah, but the output image will still be scaled and have scaling artifacts unfortunately. It comes pretty close. Not in my experience on desktop Google Chrome on a high DPI screen. I can't vouch for other browsers, but in that setup, if you use the devicePixelRatio to scale an image's size down via CSS to the proper screen size, it will display properly imagepixel-to-monitorpixel. Example: Raw Image: Chrome on a High DPI display -- top image is a raw <img> element, bottom image sets CSS to the image's naturalWidth and naturalHeight divided by window.devicePixelRatio: The scaled image is pixel perfect. After zooming the browser to 110% and reloading, to make sure the devicePixelRatio wasn't a whole number: The scaled image is still pixel perfect. Code below: code:
code:
biznatchio fucked around with this message at 11:23 on Mar 2, 2017 |
# ? Mar 2, 2017 11:06 |
|
biznatchio posted:Not in my experience on desktop Google Chrome on a high DPI screen. I can't vouch for other browsers, but in that setup, if you use the devicePixelRatio to scale an image's size down via CSS to the proper screen size, it will display properly imagepixel-to-monitorpixel. Let me mess with this today at work. There were three things I did that were different: 1. I used Chrome in high DPI mode. 2. Using PNG (smpte as the test pattern) instead of JPEG. 3. Using HTML5 canvas drawImage call.
|
# ? Mar 2, 2017 13:20 |
|
Canvas was where I originally noticed the behavior, actually. If the width and height attributes of the canvas are scaled by devicePixelRatio with respect to the element's DOM width and height, it'll also display pixel perfect.
|
# ? Mar 3, 2017 07:10 |
|
This is a Vue.js framework question, so I understand this may not be the perfect thread for it. I am having issues with the scoping of slots. Here's a simple list example. Most Vue tutorials will end up with the HTML on your main page looking like this (pre-render) code:
code:
Before I give up and conform to the ridiculously vague top example, can anyone offer any help here?
|
# ? Mar 3, 2017 16:42 |
|
|
# ? Jun 1, 2024 05:13 |
|
Has anyone here ever used Collections.js, and can you explain why it's shrieking at me? I specifically gave it an equals function and a comparator function, so I don't know why it's complaining about things being "incomparable". It works fine if I give it an array of objects with only the 'v' property and "null" as an equals function, or an array where only one object has 'a' set. Maybe I'm overlooking something really stupid.code:
code:
|
# ? Mar 4, 2017 16:42 |