feat: add option to parallelize pdfs

[awalker4]

We aren’t planning to bring server side parallel mode back, but this can be a game changer for big documents. We should have the client optionally break a pdf into pages and send these off async. See this example.

We need to see if this it's possible to hook into the autogenerated code for something like this.

[cragwolfe]

This should likely be the default. IMO, Unstructured-IO/unstructured#2461 is a blocker.

[awalker4]

Note that #32 has established the pattern for hooking into the autogenerated code. Our custom logic will live in the new decorator dir, and we'll wrap the endpoint function. When Speakeasy makes a new pr, we'll just add the one liners back (we'll have a script to do this soon).

[hubert-rutkowski85]

It's not easy with new client parameter split_pdf_page (boolean), because the python client is now generated based on the openapi.yaml , which in turn is generated based on code by unstructured-api. So, if we add there a new param, it will be also visible in the Swagger preview (like http://127.0.0.1:8000/general/docs) of endpoints, misleading users that backend API takes such parameter. But it's not, as clearly the param is for client only.

I looked for ways of hiding the endpoint param in Openapi spec, but it's not supported even for the more basic case of endpoints OAI/OpenAPI-Specification#433 Perhaps some clever hacking would work here, but it might not be pretty. So I wanted to ask if it's ok for now (or forever), if we have a parameter which will work only on client side, and will be ignored backend side? We could rename it to client_split_pdf_page.

[awalker4]

Yeah, that's a good question. Adding something on the server for this does feel messy. I wonder if we could establish a better pattern for configuring these sorts of things on the client - some sort of Configuration object that we pass in to the sdk constructor. We can see what Speakeasy thinks about this, or figure out how to support the behavior on our own.

I think, for now, we can add the logic and assume that it will be the default behavior. We could add configuration via env variable if users really want to be able to turn it off.

[hubert-rutkowski85]

Ok I asked the Speakeasy support and they suggested a way for adding the parameter only on client side, through overlay. This is relatively simple and looks like the best solution. The draft implementation is already in PR.