These are chat archives for ractivejs/ractive

26th
May 2018
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:07

I'm currently building realtime web based ERP solution for a company. there are actors in the system, like clients, databases and some custom built physical devices. it can be thought as a chat room + issue tracker

Simplest thing is sending any message to some clients. what if some messages will be delivered to some clients fully and some clients partially? for example, some users/workers can see the price of a product and some others can not. some users can see client names and some other can not. how and when can you blackout the appropriate fields?

Cerem Cem ASLAN
@ceremcem
May 26 2018 06:19
("client names" means "customer names" here)
Chris Reeves
@evs-chris
May 26 2018 06:24
I've done similar things before where the outgoing message is passed to a clean function along with an auth object
if the user has permission to view everything, the message goes straight through
if not, it gets cleaned up
same happens for incoming messages/data
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:25
that's the way I've been following
exactly
...so if all of this filtering is happening in the database, it has to re-transfer all form of messages to each role (unless all clients are connecting to the database directly). which means overall performance will be decreased.
this filtering has to be done in the server where clients are connected
if one is planning distributed architecture, this filtering will be happening in many places
Chris Reeves
@evs-chris
May 26 2018 06:30
yep, at the app server is where I handle it
auth is shared across a redis cluster, along with message pubsub to the socket endpoints
if there are a few clearly defined roles (categories of user), you can reduce filtering to once per role per socket server
my experience has been that that scales pretty well to at least a few thousand concurrent users if the messages are reasonably scoped and not super frequent (faster that 1 per second or two)
of course we have reasonably study dedicated hosts, so your cloud mileage may vary
Chris Reeves
@evs-chris
May 26 2018 06:35
also only a few thousand users 😀
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:35
in my case, roles are defined like hell :))) any user may inherit some other client's or clients' roles and overwrite some permissions.
Chris Reeves
@evs-chris
May 26 2018 06:35
I have a similar situation with group permissions and overrides at the user level
any time there's a change, I recompute all effective permissions and store it in a cache column
most groups don't have more than a few tens of members, including other groups, so updating the cache entries is usually pretty painless for the system
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:39

most groups don't have more than a few tens of members, including other groups, so updating the cache entries is usually pretty painless for the system

I agree, it won't be a headache unless you are updating very frequently

that's also the way I'm following, but without a separate server (redis or like)
Chris Reeves
@evs-chris
May 26 2018 06:42
postgres tends to perform much better without a ton of connections, so redis caching the auth and messages makes a significant performance diff
probably not as big a deal with couch, which is designed to be fully distributed to start out
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:46
there are 3 concepts in my case: routes, permissions and filters. filters are two separate (incoming and outgoing) functions. routes are simple topics. if message route matches with user's permitted routes, message will be delivered to the target. there are permissions where users send messages to the target (for example, database) by including "I have some.permission" string. this is checked and approved by the intermediate server. this string is directly handled by target.
permissions are used to decide if a client side widget will be shown or hidden to the user. if user is able to see something, Ractive will show that to the user.
Chris Reeves
@evs-chris
May 26 2018 06:50
I tend more toward a room-like approach e.g. user foo is interested in bar messages and wants to register, so check to see if that's ok and add that socket to the bar room if it is
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:50

probably not as big a deal with couch, which is designed to be fully distributed to start out

actually I'm not using any bit of authorization or authentication features of CouchDB anymore because its authentication mechanism does not fit in my case

Chris Reeves
@evs-chris
May 26 2018 06:50
I mean, just to store auth entities
Cerem Cem ASLAN
@ceremcem
May 26 2018 06:51
oh, yes, that fits absolutely :))

I tend more toward a room-like approach e.g. user foo is interested in bar messages and wants to register, so check to see if that's ok and add that socket to the bar room if it is

that's how routes work in my case. routes are lists that user is able to register. if user registers to that route, then it starts sending and receiving by that route. user may subscribe or cancel its subscription dynamically

Cerem Cem ASLAN
@ceremcem
May 26 2018 06:56
my point is, authorization is not a simple task that a database or any single process can handle all by itself. it must be performed in many places
I think you agree also :)
Chris Reeves
@evs-chris
May 26 2018 07:28
Definitely