Protocol simplicity versus "properness"

Question

I have another argument with a friend of mine.

Consider having a need to design a simplistic JSON-based protocol, which is basically used to send sort of events (messages) between parties.

Say, something like

 { event_id: 1, chat_message: "Hello" }
 { event_id: 2, group_id: 3, presence: "online" }
 ...

I propose to keep this protocol just like above, while my friend proposes to do something like:

 { event_id: 1, details: { chat_message: "Hello" } }
 { event_id: 2, group_id: 3, details: {  presence: "online" } }
 ...

His argument is that just like TCP and, say, HTTP are at different layers of "responsibility", this protocol should use "details" sub-object in order to keep data separated.

Another argument he has is that handlers that handle matched event, should not know anything about "routing" information (things like event_id).

My arguments are:

1. We're increasing length of each message (and network traffic, this might be important for a system that exchanges with a lot of messages) for the sake of hiding this information from handlers

2. Handlers do actually need to know "routing" information, say, to answer them properly:

   this.replyTo(event['event_id'], reply); // or...
   this.replyTo(event, reply); 
   

3. Even if we'll need to hide event_id and stuff like that from handlers, we can just strip them out before passing to handlers and thus still save on traffic

This protocol is quite simple and is not supposed to be used by anybody else.

What do you think?

Answer 1

After long experience at big project I must strongly disagree with gahooa's and Charlie Martin's suggestions. There is big tension between agile and classical approach. Their suggestions can look like agile but I can't agree. If you design something, never design it in way that you know is wrong even just now. It's not agile, it's dumb. I can't believe you think that your requirements will not change in future so keep doors open and refactoring impact minimal. When in your current design event is handled by different subsystems as event type dispatcher -> router to group -> final event handler/storage or whatever, keep change in each subsystem with minimal impact to each other. Best afford for me is design protocol like onion peels bud don't design it to each subtle detail outside your current requirements. It's agile.

You arguments:

ad 1. It is premature optimization. If you really need minimize traffic, use binary protocol instead ;-) Other way cost/benefit of ti is wrong.

ad 2. It is work for internal program instrumentation, not for protocol itself. It is wrong design especially in Erlang. Your handler should not return directly to destination but to some router (typically back to dispatcher) which keeps socket ownership and similar. It looks like premature optimization again!

ad 3. I prefer opposite approach. Provide minimal dataset to subsystems to minimize side-effects, simplify (unit) testing and avoid seduction to use approach from 2. point. Extend if necessary. Don't do it in opposite way.

P.S.: Why you don't name your event but use ids? Premature optimization again?

Edit: Ids are clarified, those are event numbers but not event classes. There should be another class key.

Answer 2

Favor simplicity...

Properness will be needed when you are writing a specification, a distributed system, and one that will be used in many different circumstances outside of your control.

Being Pragmatic, it is oftentimes better to use the "power of the language" and just write code to handle each case. Don't abstract unless you need to.

Keep it simple. Keep it quick. Keep it clean.

You do not know what it may need to evolve into (features or performance), and the more abstraction you have, the harder it will be to re-factor.