Separation of Concerns

[shz]

This is becoming more of an issue than we thought, unfortunately, and may require more re-architecting.

Here's a sample workflow:

The owner of a listing answers a question. The client understands that to do this, it must update the "answer" field on the model. As such, it pushes a diff ({answer: foo}) down the line via the update message.

The server receives this message and applies it to the database. Next, it checks the update to see what fields were changed. It notices that the answer field was updated, and says "aha, this means the owner of a listing has answered the question" and performs special logic accordingly (in this example, sends an email to the guy who asked the question).

See the issue? The action being taken is "answer the question," but this action is obfuscated when the update is sent. Is it an issue now? Not so much. A bit of special logic here and there. It'll become an issue when we start adding more "special functionality" to the server. Rep, for example. We'll need to start inspecting every single update/create/delete operation and trying to figure out what actually happened. This could get messy.

Compare that to this workflow:

The owner of a listing answers a question. The client sends a message (do-answer:{inquiry: "deadbeef", answer: "An Answer!"}) to the server. The server knows that answers need to update the relevant inquiry data, and that it should send an email to the user. It does so.

I'm not saying this is the approach we can take, but it's food for thought.

[defrex]

This is a really good point. The architecture we came up with really expects the server to be "dumb", that is, just auth and storage. That's a fantastic ideal, but in practice there are just some things that can't be done reliably and securely from a client, such as sending email, assigning rep, and so on.

We should be careful not to throw the baby out with the bathwater though. We have a really good thing going with model pub/sub. I think we should leave our current "read" mechanism alone. create makes sense for some data-types, such as listing, but less with others, such as conversation.

Perhaps create and update messages should be rolled into data-type-specific operations. These will have to be worked out on a case by case basis, and will make adding new data-types more time-consuming, but it should help the server's operating model stay clean.

What do you think?

[shz]

Agreed, the current read side of things works super well.

As it is currently I've actually got the server handling different data types just as you described. I've got a generic handler for create/update/delete that delegates down to type-specific handlers if needed, and I can always tell the type of data being operated on for those messages since it's always somewhere in the message.

[shz]

So as we talked about before, leaving update to be its simple self is low-friction and nice. What's not so nice is that we lose the intent behind those actions, which means the server does more work.

So what about this: updates include an extra field intent that says what the actions did. So say someone's answering a question: intent: "answer-question". Boom. Update messages would now look like this:

{
    key: String,
    diff: Object,
    intent: String
}

Are there security implications to this?