DuckDB supports partial reading of Parquet files (also via HTTPS and S3) [1], so it can limit the scans to the required columns in the Parquet file. It can also perform filter pushdown, so querying data in S3 can be quite efficient.
Since the data in S3 receives updates every few hours, querying it directly ensures queries are on up-to-date data, whereas creating a copy of the dataset on the EC2 would necessitate periodically checking for updates and moving the deltas across to the EC2 (not insurmountable; but complexity worth avoiding if possible).
That’s not meta data. Claims are usually user scopes based on actor definitions. Some users can view, some can edit, some are admins. Claims are often, but not always, about resources.
You can implement a blocklist of all the revoked JWT and publish it to all servers. The list should be small, because only otherwise valid tokens need to be included. It becomes so much more complicated than a simple check-the-db setup though.
I don't think I would start with JWT if I did this again.
You're talking about tokens in general, not just JWT. The only alternative I know to tokens is to query the DB every time (or perhaps use a cache to make the lookup less often, but then you also have to find a way to invalidate the cache - back to square one?).
> You're talking about tokens in general, not just JWT.
Yes, all stateless tokens. But I have never seen an in-house token system that was not using JWT's.
Yes, query the DB or some sort of storage every time. It sounded so clean and nice and fast to just check JWTs without any network calls. But it ended up very messy and complicated. Might still be worth it in some cases, of course, but I would start my next project with random sessions stored in a db or redis or memcache or .. something :)
You can actually do crazy stuff with your sessions as well, to avoid a normal db lookup. But in practice all services I have worked on would/did not suffer noticeably for a fast DB lookup.
Having to list the tokens to revoke is a problem in several ways. Obviously publishing the tokens themselves allows attackers to use them before relying parties get the revocation notice, so publish a token hash instead. But even publishing a token hash is annoying because you then have to record all the claims + token hashes issued, and that's a failure point. Instead you'd want to revoke _subjects_ (`sub`), but since tokens don't have to have those... (In enterprise systems though your tokens should name subjects.)
the USG will never allow that to happen. boeing itself is both a significant hard-power (military contractor) and soft-power (export authorizations provide a national bargaining chip, impact on domestic economy, etc) asset for the united states.
it is like intel in a lot of ways: sure, they're massive fuckups but there simply is not any chance that the US allows one of only three leading-edge fab companies to go under. As much as things are going to suck for a while, and especially as much as things could suck for individual employees... at the end of the day the fab side is not going to go under and the USG will shovel cash into the furnace to make sure of it. It is like Boeing - think of it as "buying at a discount, for an indeterminate future time", because the value cannot ever go to zero.
And even on the IP side the ownership of x86 and the x86 license is a significant soft-power asset for the US. Having everyone on the planet able to implement their own ARM cores is not really a great thing, when you could instead use it as leverage (like we do with ASML's machines).
The way I read it, it's not about being exceptional (or not).
More like not blindly following other people's definition of success.
We all have choices to make. And most of us could, for example, choose a less prestigious job in order to have more time and energy for other stuff. Among other things..
No it's not. It's not java programmers who are wrong, it's you and golang that is wrong. You clearly don't know what you're talking about. I hate smug golang programmers who think they're gods gift to programming because they think they're so good at go when they don't realize how broken go is as a modern language. Honestly it's only the golang programmers who have this attitude.
Golang (and java) by nature has a bad type system that's fundamentally incompatible with popular data structures used in the web.
Json a very popular web data structure cannot be represented properly as a type in golang.
The standard way of dealing with a dynamic json data structure in golang is to resort to interfaces and type assertions or assuming it's some struct. There is a similar problem in java. This isn't some "wrong" thing in go as you wrongly state. It's standard practice. You are suppose to use interfaces for this purpose in go. It's standard and by design. If you haven't then you haven't worked on something sufficiently big enough such that the input parameters include json of an unknown structure. Basically you only worked in web apps where inputs aren't complex like trees which is a valid structure that can be represented in json.
Rust gets around this by something called sum types allowing you to stay type safe without ever resorting to breaking out of the type system when dealing with any json type. Typed python also has sum types which let's you easily get around this problem.
Glad you are! I don't want to be overly negative. I am comparing my M2 work macbook trackpad with my 2 year old lemur pro trackpad - it's not really a fair comparison. The problem is that the pricing is similar enough where it's hard to justify the hardware downgrade.
I should also mention that my free time to work on projects has dramatically decreased in the past few years, so I am valuing the ability to seamlessly switch between my desktop and laptop on personal projects less than I used to.
My team uses this pattern and generally speaking it looks something like this
* everybody is good at breaking down code into changes small enough review quickly but not small enough to become tedious and trivial
* people work on CRs whenever they have time. They do generally not post them after people have started going offline, and wait til next morning as a courtesy, since there is no difference between publishing for review at 5pm vs 9am the next day
One side effect of this workflow is that because the pieces are more manageable, less uninterrupted “flow” time is required to complete a bunch of small things than to make one really big change. And others digest the smaller changes easier and knowledge spreads more effectively. And with the time its easy to say “don’t make people review outside working hours.”
They are not new challenges, they are the same old challenge that led to version control procedures and systems in the first place: your incomplete or broken code is interfering with my attempts to complete or fix mine!
Whether the broken merge happens in a branch or as part of a rebase is just moving things around. The trick is to enforce good code cleanliness when pushing, whenever that may be.
My team does stuff on mainline and requires a new review on rebase.
1 TB is .. not a lot of data .. I rent a server with 15 TB for ~50$ per month and buying a new 2TB disk is less than 100$.