feat: bump protos to support list caches with metadata around limits

[bruuuuuuuce]

protos now contains cache limits around

  // The amount of transactions per second that can be exercised
  uint32 max_traffic_rate = 1; 
  // The amount of traffic per second that can be exercised in KiB
  uint32 max_throughput_kbps = 2;
  // The maximum size of a single item in KiB
  uint32 max_item_size_kb = 3;
  // The maximum TTL allowed for a single item, in seconds
  uint64 max_ttl_seconds = 4;

and topic limits around

  // The amount of messages that can be published per second
  uint32 max_publish_rate = 1;
  // The maximum amount of active subscriptions per cache
  uint32 max_subscription_count = 2;
  // The maximum size of a single publish message, in KiB
  uint32 max_publish_message_size_kb = 3;

unblocks ui for https://github.com/momentohq/momento-console/issues/293

[pratik151192]

The code LGTM but there aren't tests. Looks like we haven't implemented it on the backend yet? I think even if we haven't, we could just wire the tests to assert on 0 for the limits, and when we do implement it, we can just change them?

[cprice404]

couple of nitpicks/questions but nothing big

[cprice404]

what's the difference between type and interface here?

[cprice404]

nit: I'm guessing you did these as classes because the main CacheInfo object is a cache; but is there any reason to do these as classes instead of interfaces?

[bruuuuuuuce]

yea I think an interface should work here as well

[cprice404]

I feel like that might be a little simpler/cleaner, wdyt?

I know it's not a huge deal either way but since this is technically going to be public API, just wanted to make sure our decision was deliberate.

[cprice404]

just checking my understanding of the proto changes - cache.cache_name is always present but the cache_limits and topics_limits were modeled as optional?

[bruuuuuuuce]

they are modeled as always present, but until the change gets all the way through the backend, they will be returned as null

[cprice404]

but I'm surprised the TS compiler will accept this? If the type is defined as non-null?

[bruuuuuuuce]

it just thinks that || 0 will never be true, but it doesn't fail compilation because of that

[cprice404]

okay. interesting.

worth capturing a ticket to come back and remove the ? later?

[cprice404]

why is it different for cache_name though?

[bruuuuuuuce]

I believe because it is a grpc object vs a string, but I am not entirely sure

[cprice404]

okay. it's probably fine like this. thanks.

[bruuuuuuuce]

ill make a ticket to remove the ? for the nodejs sdk tho

[bruuuuuuuce]

#755