Python SDK - update servicer/server to allow more data access flexibility

[magelisk]

Summary

The current Server/Servicer structure directly ties a Servicer to the server. When dealing with more unary data types, this isn't a big deal as you can't do much more than one data in, one data out. But when adding more gprc stream servers, there becomes a lot more flexibility in how users might want to be presented data.

There is an example of this for batch-map here: https://github.com/kohlisid/numaflow-python/pull/1

General implementation is very simple

• BaseServer and BaseServicer
• Specific Server instance, provides an already initialized servicer
• BaseServicer will still do primary GRPC receiving and sending. It will receive data, and provide a normal presentation format (ex AsyncIterable[Datum]. This is generally always done already
• BaseServicer then calls a present_data fuction which allow specific implementations of specific Servicers to then call the user's handler function in an appropriate manner.

When would you use this?

This allows maintaining a streamlined usage interface, while giving users a relatively simple method to provide customization for handling data patterns. Just some examples with a bi-directional vertex

• Can do pure streaming with input AsyncIterable and output AsyncIterable
• Can do presentation in a sync or async unary by doing the primary async for within present data
• Can request just X messages at a time, could be useful to avoid overloading a given handler with all data at once.
• If 10 messages sent to handler, but handler 'reduces' them to a single message, a PseudoReduceServicer.present_data function could automatically send the appropriate 'ack' messages for each allowing actual handler function to simply deal with business logic, and less with message bookkeeping.

To be clear, many, if not all, of these things could be done anyways within the handlers directly, or some other custom layer that they put on top of things. This simply provides a more SDK-friendly style for accessing data. There could actually be some performance benefits by have a more "close to source" resulting in less marshaling between different presentation formats.

---

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.