architecture to enable shared work - where I can start ?

architecture to enable shared work - where I can start ?

  
I was thinking to create tenant environments, but I intend to enable same behaviour as facebook where people can "call" their friends and request activities to them. Would a monolithic database be the first step to create something ?
Hi Luciano,

Tenants are used for completely separate environments that run on the same database and platform server, but are otherwise completely separate. Your use case seems to call for a different approach.
Hi Kilian,
  can I access these separated environments ? For instance, create a register, see its content  or the number of registers ?
"Seperate" in a functional way, say if you provide a SaaS application. So you have three customers that all use the same application, but don't see each other's data.
Luciano Schiavo wrote:
I was thinking to create tenant environments, but I intend to enable same behaviour as facebook where people can "call" their friends and request activities to them. Would a monolithic database be the first step to create something ?
What you need is to create user-based permissions. "This user is an owner". "That user was invited to read/edit" "If I have permissions to invite, I can invite anyone from my list of friends" ...

If you want that social network approach, you may need to distinct different connections (friend, friend of friend, member of same group, etc).
Hi Nuno,
   that is the idea. I have the customer that invite a friend. From this point they can interact between them like social network. Which approach is more suitable ?
Only to confirm my understanding Kilian,
   from user perspective tenant is totally separated but from developer perspective I can Identify the tenant area and interact sending request/updates to each tenant. Am I right ?
Hi Luciano,

I think that depends on the way you set it up. The way tenants are implemented is that they are as transparent as possible from the developers point of view. So I think (but I've never used tenants myself) that the simple answer to your question is "no".
Luciano Schiavo wrote:
Hi Nuno,
   that is the idea. I have the customer that invite a friend. From this point they can interact between them like social network. Which approach is more suitable ?
 
 
I would make an entity for permissions like this:
contentid, personid, isauthor, permissons
where permissions means "members of group x", "only me", "friends", "public" and that kind of stuff.

When someone else shares, it will be a new similar row (with isauthor false) and that person can propagate a few more levels.

To check if someone can read, you need to see if he is in personid, if he is friend with someone in a row of type friends, or member of a group in a row of type group, and so on.

Of course you need to split very well the information so this table doesn't get huge.
Hi Nuno,
   thanks for the advice. But this way should be in a tenant or monolithic database ?
Monolithic. That case is so unusual that you'd have to do the tenancy by yourself if you really need it.
Ok. Thank you so much
I'm not sure I agree with Nuno. First, the term "monolithic" is misleading. Even with multi tenancy there's a single database that contains all data. The difference is that tables can have an extra TenantId, and that queries on these tables will implicitly add a condition that reads TenantId = Session.TenantId (or the like, I'm not entirely sure where the session's tennant is stored). Multi-tenancy is just the platform making it easy for you to separate data from multiple tennants, but it has no reflection on the database itself.

Secondly, and this is more important in this case I think, we know very little about Luciano's actual application. We know he wants, apparently, users from different tennants be able to engage in conversation, but not how this should be integrated in the main app, or what that main app is. What solution you will chose is largely dependent on that, not on the chat functionality (which seems a secondary purpose).
I agree. It all depends on the application.

I think Luciano asked about my previous sugestion, so I explained the way I was seeing it.
The way Kilian sees it, he should do a tenant environment for the app and invoke some shared espace with chat.

It can go either way. Kilian's is a lot easier to implement, so, if it works, go for it.
just design the datamodel upfront.
a datamodel should be technological independant anyways...

then think which table goes where and should be partially/fully integrated with outsystems.
then you can also decided to use tenants or not..

Well guys, I intend that my architecture should be regarded as modules that I attach when new users are added if I adopt multitenant. The good news is that I can add many customers as I can. The bad news is: when I need to do an update into the tenant structure I must update all tenants ? Is that proceed ?
Other doubt: can I fetch all tenants to identify which user would like to accept invites regarding his/her profile is public ?
tbh, I would not go for the tenant-solution..

just make a good datamodel that covers it in a same way and create the businesslogic accordingly.

I agree. Tenants are useful if you have several businesses each with multiple users. Luciano's use case seems to be individual users.
Solution
Hi Luciano,

There was an application architecture guide recently published that will definately help you.

Check it out!
Mario
Solution
Thank you Mario. I will do it.