Question

I’m currently reworking a somewhat extensive communications protocol into something easier to work with, and this is kind of an opinionated question, but based on your experiences, which of these two ideas is easier to maintain as code grows larger and larger.

There’s a client and a server. The server has pieces of information the client might want, A, B, C, D, etc. A piece of information isn’t a single set of data, like a name, but rather a list of names. Generally the entire contents of a column. The client will generally want this stuff in groups, like ABC, DEF, ABD, etc. There isn’t a ton of overlap (meaning, generally 80% of the requests for A are also requests for B and C).

As the system grows larger is it easier to maintain a system where the communication protocol works like:

Request 1: Server returns ABC
Request 2: Server returns ABD

or

Request 1: A
Request 2: B
Request 3: C

etc

I’m inclined to go with the first one because it seems to make the code a bit easier to read and work with, and having special requests for groups, like ABC, can often let the server run fewer queries on its database to get the information needed. But the code base is going to get significantly larger than it is right now, and since I’m already taking the time to overhaul how the client and server are communicating, I wanted to hear some experiences people here have had with either/or method.

Edit:
Note that I’m not just talking about network traffic, but also things like how the server will handle these requests. If the client makes three individual requests, the server will have to make three DB queries, where as the grouped request could be most likely run as a single query.

Answer 1

I think this is a case of ‘premature optimisation’.

1. You don’t know if there’s actually going to be a performance issue.
2. You’re going for what you state is more complex code for a perceived performance issue.
3. In reality, the second option may well performance worse (consider which is heavier – accepting a connection and processing a request, or sending out a slightly longer response)?

Now, you are more likely to find that any bottlenecks or performance issues may be related to where you look this information up (say, in a database). In which case, you can tune for performance on that end without affecting your protocol (for example, you can cache the values returned by the DB).