holtalanm
if you _had_ to do that, I would put the counter into something like redis instead.
A short-lived JWT that fits into an HTTP Header is not going to _massively_ increase your bandwidth usage. At most, you will end up with a single refresh request every few minutes as each short-lived JWT expires.
> 2. Has problems with users less reliable connections (they'll be randomly logged out all the time)
Usually if your request failed due to a bad connection, the client wouldn't be designed to automatically log out the user. That would be just terrible UX.
> 3. Makes "Remember Me" style features impossible (unless you use a server-side store for that, which brings us back to it not being stateless)
Incorrect. A short-lived JWT tied to a refresh token allows for a remember-me style feature by checking account access when issuing a new JWT token.
im curious about this. normally 'logging out' just involves deleting the secure http-only cookie where the jwt was stored. is there something I'm missing here?
if it is the former, i can see there being cause for concern. if it is the latter, this is just pure fear-mongering.
are we really concerned about console tools overreaching their telemetry? personally, I am not.
I would love to know why others think this is some kind of huge issue, without a bunch of 'what-if' scenarios.
`Object.freeze` is what I used. This causes Vuex to not traverse the object for changes. in my case, the objects I was pushing into the Vuex state were essentially immutable once I pushed them in, so this did the ticket.
well, that, and only pushing partials of the entire state, so the object model didn't get too unwieldy. To get the total state, i just replayed the changes on top of the base state. base state was reset once the number of changes got to a certain size.
Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.
Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.
Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.
My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.
am i being punkd?
That is the whole premise of the site, though. They even say that these examples aren't common syntax or patterns before you start.
Fool me once, shame on you. Fool me twice, shame on me.
too bad most ISPs have literal monopolies over entire regions of people.
Will have to check it out again, I suppose.
I did a quick google search because I had never heard of Skypack.
Skypack seems to be a far cry away from what WebContainers is claiming to do. Like, they're completely different products. I guess I don't understand why you're even comparing the two.
Supporting chrome/chromium doesn't seem like a bad place to start with a prototype with that kind of potential adoption.
seems relevant.
On a more on-topic note -- this data-oriented structure seemed to be at the core of the goals of Vue 3, to the point where you don't even need to use their Flux implementation, Vuex, anymore for 100% vue3 projects.
this was my first thought, too. We have polyfills for js features that don't yet exist in a lot of browsers, but polyfills for css are either very complicated or just don't exist in some cases.
if you have data you don't want publicly available, just.....don't include it in the model, and make sure your server implementation doesn't return it.
It is possible I don't understand your comment, I suppose, but I really don't see what is so unique about graphql from a security standpoint.
a lot of people don't exactly understand just how _sprawling_ the US is.