[Ur] Multitenancy
Adam Chlipala
adamc at csail.mit.edu
Sun May 13 10:03:28 EDT 2018
I'm not sure which aspect of deployment you're worried about. With
Apache, you can configure as many FastCGI applications as you'd like,
and they will all be started automatically on each reboot. It only
takes a few lines of configuration per application. Similarly, creating
a new database is a few lines of shell script, using the .sql file that
the Ur/Web compiler produces for an application. All of the details are
independent of application specifics.
I am not aware of any existing tools for doing these simple steps
automatically, but it should be easy to roll an all-inclusive shell script.
On 05/13/2018 09:48 AM, Simon Van Casteren wrote:
> I considered it briefly as I was doing some research on the topic.
> It's the first time I'll be running and deploying a SaaS app myself
> (I've so far always been on the programming side only) so it felt more
> natural to me to keep everything inside a single application. Running
> the application right now consists of me ssh'ing into a Linode and
> running the exe by hand. If I want to split this into one application
> per database (which does guarantee data security better, that's really
> nice) then deployment seems to become much more complicated.
>
> But let's say I do go that route. Is using one of the new deployment
> tools a good idea for a just-started scenario? I appreciate how ur/web
> uses very basic and simple tools, eg: Using curl in the Worldffi
> project to do HTTP requests, not having editor tooling but having the
> compiler use standard error formatting so emacs picks it up
> automatically. This is in strong contrast to the javascript community
> where I normally reside, which likes to re-implement things a lot. So
> I'd like to know what advice the community has on the right tools for
> setting up a new application and database automatically (probably via
> the C FFI?) and then running and updating them together. I would like
> to note that adding and running new clients without any manual work is
> strongly preferred.
>
> Because I don't have any idea of how I would handle this adding and
> deploying of clients, I can't weigh the two alternatives: Complicating
> the app with tenantIds, or complicating the deployment with seperate
> apps.
>
> 2018-05-13 15:31 GMT+02:00 Adam Chlipala <adamc at csail.mit.edu
> <mailto:adamc at csail.mit.edu>>:
>
> Can you explain why you don't want to run separate applications
> with separate databases?
>
>
> On 05/13/2018 05:50 AM, Simon Van Casteren wrote:
>> Hi,
>>
>> I'm in the process of making a new application for music schools,
>> using ur/web for front and backend. I'm at the point where I have
>> two customers and am starting to implement support for multiple
>> clients/tenants in one DB (postgres). I've been planning to
>> implement multitenancy from the start, but haven't had the time yet.
>>
>> Has anyone implemented a form of multitenancy in ur/web before?
>>
>> I see two areas that need consideration.
>>
>> 1. Deciding which user belongs to which tenant. Ideally I'd have
>> a seperate url for each tenant that I can give out to my clients
>> (=the schools), do some dns magic to send them all to the same
>> exe, extract the tenantname from the url and save the tenantId in
>> a cookie. Also ideally, the user's url would not change, ie. All
>> urls should go to myschool.coolschools.be
>> <http://myschool.coolschools.be> during a session, not getting
>> redirected at all. This is all in an ideal situation of course.
>>
>> 2. Database access: I'll have tenantId columns in all tables +
>> foreign keys and indexes on these columns. I'm a bit afraid I'll
>> forget adding tenantId = cookie.tenantid somewhere, so I was
>> thinking I could make a function that takes a sql_exp and a
>> tenantId and adds these clauses to all tables involved. Not 100%
>> sure that will work but I think it's possible, I haven't had to
>> dive into the internals of sql_exp yet. Secondly, I wonder if I
>> can somehow declare my endpoints to be tenantdepandent (all but
>> the most general will be) maybe via newtyping the transaction
>> datatype and then allowing the execute only sql queries that have
>> the above function applied. Just dreaming out loud here.
>>
>> I'd be very interested in any ideas or examples!
>>
>> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20180513/10f4d62c/attachment.html>
More information about the Ur
mailing list