sheharyarn
Joined 10 years ago
Karma
123
Submissions
36
Member since
Mar 24
[ my public key: https://keybase.io/sheharyar; my proof: https://keybase.io/sheharyar/sigs/PAl5t1g2hhLmKsut41MudcthQoPQvZLAoqTc27C-xEo ]
View on Hacker NewsRecent submissions
Comment · 5 years ago
Here's a little context on Delta (https://github.com/slab/delta-elixir) and the linked blog post:
Delta is a format to describe documents' contents and how it changes over time. This is a core piece of technology at Slab, that powers our real-time collaboration engine, thanks to the built-in support for Operational Transform (think multiple users working together in Google docs).
Though we've been using it internally for almost 4 years now, we're finally open-sourcing it to the wider Elixir community.
Would love your feedback!
Comment · 5 years ago
Not an alternative, but as a companion to it. In our use-case we use a custom `OrgRepo` wrapper around `Repo` which handles a lot more read/write scenarios.
Comment · 5 years ago
This obscure little feature in Ecto/Elixir is something we've been using at Slab.com for about a year. While the blog post only covers the feature itself, I wanted to give a better overview of *WHY* we're using it.
Slab is a multi-tenant Phoenix app where all tables in our database, including pivot tables, have an `org_id` foreign key that references the team the data belongs to. Using association defaults enforces that the correct `org_id` value is automatically set for all resources.
We combine this with an `OrgRepo` module that wraps around our default `Repo`, which can only write or read other resources with the same `org_id`, ensuring that data for one team has no possibility of accidentally leaking to another team (using `Repo` is forbidden in our codebase).
An added bonus is; when we eventually have to scale our databases via something like sharding and have to vertically partition the data based on `org_id`, we would already have this system in place to support us.