gkaemmer

This is cool, I'll probably end up using this (we store sqlite snapshots in S3).

It'd be very handy if this was packaged as a CLI that worked like `sqlite3`, so you could get a SQL repl by running:

    s3sqlite mybucket/mydb.sqlite3

Very groovy visuals.

There was something sort of terrifying about the enemy tanks. Maybe a minimap would help with this, but I almost got Slenderman vibes when I would turn around and see a tank right there in front of my face. Got my heartrate going.

Yeah, although mostly variations on that basic premise.

Airbnb Himeji: https://medium.com/airbnb-engineering/himeji-a-scalable-cent... Carta's AuthZ system: https://medium.com/building-carta/authz-cartas-highly-scalab... Slack's architecture is a bit different, but solves some of the same challenges: https://slack.engineering/role-management-at-slack/

I've also talked to a number of teams who just implemented pattern 3 internally with a custom service. Generally they've determined it's worth it to centralize all authorization data (like roles, groups, etc) into one place and perform ALL permission checks there.

There are also some companies building essentially Zanzibar clones, like Auth0, Authzed, Ory Keto, and a few more.

Oso engineer here. It's a good question -- definitely a dearth of content about this topic.

Like pphysch said, using RBAC generally gets you 90% or more of the way there on this, and a good intro to this concept is the Tailscale post: https://tailscale.com/blog/rbac-like-it-was-meant-to-be/

In most cases (even with many 100s of thousands or millions of users), there are far fewer _roles_. So you can generally answer the question of "which users can access this resource" by answering the questions "which roles can access this resource", and "which users have those roles". If you're using SQL to store roles and role assignments, your query for all users becomes:

    select * from users
    join user_roles on user_roles.user_id = users.id
    where user_roles.role_id in [... small list ...]

This can get tricky if you have 100s of thousands or millions of _roles_, and each of those roles can be dynamically assigned access to a significant percentage of your resources. But that might suggest you're structuring roles incorrectly in the first place (and you should be using fewer roles with more users per role).

All that being said, I think there's definitely more to be written here. Keep a lookout -- we might do some more writing about the topic.

Hey, Oso engineer here. Good question.

The rust core is indeed called from the ruby library (as it is with all of our 5 other host libraries). The core itself is pretty complex (there's a whole parser/interpreter in there), so maintaining it in a bunch of languages would be a bit hectic.

There are some files inside `lib/oso/polar/ffi` that define the C bindings used by the rest of the library. Here's an example: https://github.com/osohq/oso/blob/main/languages/ruby/lib/os...

We use the ffi gem to make that work: https://github.com/ffi/ffi

EDIT: hobofan beat me to it! :)

I actually came to this thread expecting more people to call out MobX. When I use MobX with react, I find it to be as simple and _fun_ as the author finds svelte. Most of the problems people tend to raise with React are problems that are solved by observable state objects.

I also evangelize it whenever I can -- I don't want MobX to be forever doomed to its status as a cult hit!

In my experience it’s not about “bad” vs. “good” code, and not about a tradeoff between speed and quality.

It’s more about how much abstraction is built into the system. A mature codebase has a clear purpose and therefore can contain durable, high level, even beautiful abstractions. On the other hand, a founder doesn’t always (nor should they) know what their code will need to do in 6 months time, so they typically avoid writing abstractions.

You can still write good code as a founder—it’s just that good founder code looks different than good BigCo code.

Curious why you're so opposed to spacer components. In my experience they work quite well--often a designer has specified that two widgets lie a certain distance apart, either vertically or horizontally, and the programmer needs to express that in code. Makes much more sense to use a spacer component than to add a margin to one or both of the widgets themselves.

If responsiveness is what you're after, you can easily make your spacers adaptable to different screen sizes.

At the same time, I find that it's often hard to comprehend projects that are broken into too many little files. There's normally no guide on what pieces are where, so you don't know which order to read things. Makes it a little tougher to dive in. I just want to find the file that has the "meat", and I don't mind if that file is 1000+ lines long, especially if the code itself makes sense and is clear.

I really like this.

Except the way the button grows vertically and pushes down the rest of the page.

Brex (YC W17) | Software Engineer, Frontend and Backend | Full Time, Onsite | https://brex.com/

Brex is rebuilding B2B financial products, starting with a corporate credit card for technology companies. We're looking for strong frontend and backend engineers to join our small but talented team.

Check out our openings on AngelList: https://angel.co/brex/jobs

Also potentially https://common.net/ though I’m not sure which specific transmission mechanism they use.

Funny, I just had the exact same experience. Had been fixing compiler errors by adding lifetimes to my structs instead of boxing the values.

I need a good reference on the right way to un-learn certain C concepts to make learning Rust concepts easier.

PatientBank (YC S16) | San Francisco, CA | Onsite | Full-time | Full-stack software engineering

We're looking for exceptional software engineers to help us build a patient-centered health record system. We build technology that lets patients gather, share, and analyze their medical records online, pulling data from anywhere in the healthcare system.

We work in Rails, Angular, and React. We value simple solutions to complex problems. If you're interested, get in touch: careers+hn@patientbank.us.

Full job post here: https://jobs.lever.co/patientbank/184fb6c5-cad9-4f86-9120-71...

Our data is primarily stored in postgres. We've looked into using Mongo to store FHIR-compliant documents, which is the newest standard (and best standard, IMO) proposed by HL7.

Haven't looked at that many immutable databases, but they seem interesting. Most of the time medical data does not require many writes (rarely are two doctors editing your record simultaneously), but the audit trail that datomic provides could be very useful as a built-in feature.

Thanks for the comment, leovander—very good points! Right now we give hospitals a number of ways to respond to PatientBank requests. Currently, the most common one is fax and we don't (yet) perform much processing of that data. In addition to fax, we allow hospitals to send CCD/CCDAs to us via DIRECT, and we allow them to upload arbitrary files directly to PatientBank as well.

In the future, we'll use whatever APIs we can to get records from hospitals. There's a lot of promising work going on in this space, and we're excited to see where the industry leads!