[LRUG] Multi-tenanting

[Daniel Garland]

Hi Mike,

See also: Milia gem https://github.com/dsaronin/milia

HTH
Dan

On 25/02/16 22:01, chat-request at lists.lrug.org wrote:
> Send Chat mailing list submissions to
> 	chat at lists.lrug.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> or, via email, send a message with subject or body 'help' to
> 	chat-request at lists.lrug.org
>
> You can reach the person managing the list at
> 	chat-owner at lists.lrug.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Chat digest..."
>
>
> Today's Topics:
>
>     1. Multi-tenanting (Michael Pavling)
>     2. Re: Multi-tenanting (Riccardo Tacconi)
>     3. Re: Multi-tenanting (Ben Jamin)
>     4. Re: Multi-tenanting (Glenn @ Ruby Pond Ltd)
>     5.  [JOBS] Mid-level Ruby/Rails - permanent role (Tim Robertson)
>     6. Re: Multi-tenanting (Kasper Grubbe)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 25 Feb 2016 09:24:35 +0000
> From: Michael Pavling <pavling at gmail.com>
> To: London Ruby Users Group <chat at lists.lrug.org>
> Subject: [LRUG] Multi-tenanting
> Message-ID:
> 	<CA+_7RLyQjPjnaiuUCWbAtz-ou-Qu706XPf9dTg3fJKgoAZ7moQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hiya,
>
> I'm looking at the ways I can have multiple users share an app, but
> keep all their data separate.
>
> Now, I suppose the first way is to just make sure all queries are
> scoped to the user (and keep fingers crossed that no future me ever
> writes an unscoped `Order.all`). But there's *got* to be a range of
> good ways.
>
> Looking at multi-tenanting gems, they seem to either take the approach
> of scoping for you, or creating separate DBs/schemas for each tenant.
> Does anyone have any opinion on the pros and cons of the different
> approaches, or indeed, the specific gems?
>
> I'm leaning toward the "scope for me" approach, because it seems
> simplest to grok - and the app isn't *that* serious (although thinking
> about it... there is risk of personally identifying data being stored,
> so I probably should prioritise a secure approach).
>
> Michael
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 25 Feb 2016 09:32:41 +0000
> From: Riccardo Tacconi <rtacconi at gmail.com>
> To: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Multi-tenanting
> Message-ID:
> 	<CAAvWcKEyMh6ALakKVCV9tcxdvp7OLkaeVGq0bHeu+pfPz-kW_w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> You should keep your target customers, in enterprise apps you have to have
> a different database per account and even separated queues (like RabbitMQ
> queues) too.
>
> If your app is not too serious, as you say, may be you could have a layer
> where every query has to pass an account_id in order to retrieve data.
>
> On 25 February 2016 at 09:24, Michael Pavling <pavling at gmail.com> wrote:
>
>> Hiya,
>>
>> I'm looking at the ways I can have multiple users share an app, but
>> keep all their data separate.
>>
>> Now, I suppose the first way is to just make sure all queries are
>> scoped to the user (and keep fingers crossed that no future me ever
>> writes an unscoped `Order.all`). But there's *got* to be a range of
>> good ways.
>>
>> Looking at multi-tenanting gems, they seem to either take the approach
>> of scoping for you, or creating separate DBs/schemas for each tenant.
>> Does anyone have any opinion on the pros and cons of the different
>> approaches, or indeed, the specific gems?
>>
>> I'm leaning toward the "scope for me" approach, because it seems
>> simplest to grok - and the app isn't *that* serious (although thinking
>> about it... there is risk of personally identifying data being stored,
>> so I probably should prioritise a secure approach).
>>
>> Michael
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
>
>