Protobuf, nested maps?

Question

I'm using Protobuf 3. From the docs, it seems like it's not possible to define nested maps:

message MyMessage {
  map<string, map<string, string>> nestedMap = 1; // doesn't work
}

I'm trying to create a message type to represent pricing information (bid and ask prices) for an Option Chain. For those unfamiliar with these financial instruments, basically, I have a set of "expiration dates (YYYYMMDD)". In each of these expiration dates I have a set of "strikes (float numbers; could be represented as strings if necessary, I'm ok with that)". In each strike I have 2 options, one "put" and one "call" (this is called the "right" of the option). Each one of these options will contain a "bid" and an "ask" price.

Conceptually, I would like to have something like

message OptionChain {
  // doesn't work:
  map<Expiration, map<Strike, map<Right, BidAskData>>> whatever = 1;
}

The alternative I found is this:

message OptChain {
  map<string, OptChainExpirations> expirations = 1;
}
message OptChainExpirations {
  map<string, OptChainExpirationsStrikes> strikes = 1;
}
message OptChainExpirationsStrikes {
  OptBidAsk put = 1;
  OptBidAsk call = 2;
}
message OptBidAsk {
  double bid = 1;
  double ask = 2;
  // any other fields that might be necessary in the future
}

This seems to work. But this also seems to add unnecessary complexity to my system, by defining a ton of "intermediate" messages.

Are there any alternatives?

Thanks!

EDIT: for some extra context:

• an option chain will typically contain no more than about 6-10 different expirations, each expiration will typically not contain more than about a few dozen strikes. In other words, we're talking of about take a few kilobytes of data at most, for each option chain.

• I'll be using this as the return value of one gRPC call. Feel free to suggest alternative designs for this!

Answer 1

To me, your alternative with intermediate message types seems fine. It might be worth to simplify the naming a bit, e.g. Strike instead of OptChainExpirationsStrikes. If you fear name collisions, put it all in its own namespace/package.

Also consider whether you will be looking up strikes based on the string key, or if it would be better as a normal repeated field.