Closed joshdaloewen closed 11 months ago
Hey @joshdaloewen, thanks for opening an issue.
result is different than what I get when I run a curl command to hit the API
May you please share your cURL command?
By running the code you shared, here's the underlying cURL equivalent generated by the Gem:
curl --request POST \
--url https://generativelanguage.googleapis.com/v1/models/gemini-pro:streamGenerateContent?key=$GEMINI_API_KEY \
--header 'Content-Type: application/json' \
--data '{
"contents": {
"role": "user",
"parts": {
"text": "Write an essay on the history of Canada."
}
}
}'
I figured it out, but I'm not sure how you'd want to handle it.
The problem is that
def stream_generate_content(payload, stream: nil, &callback)
request('streamGenerateContent', payload, stream:, &callback)
end
uses the endpoint "streamGenerateContent" regardless of whether stream
is true or false. But that endpoint should be "generateContent" when not streaming.
In my mind, the refactor that would be the most intuitive for users would be to:
stream
from the user configuration all togetherstream_generate_content
and generate_content
methods, which hit request
with the different endpoints and an internal stream
parameter (see below)request
method so that it requires the stream
argument, and then it handles it as it does currentlyAll that being said, you could also allow stream
to be passed by the user, but perhaps stream_generate_content
could have a less confusing name??
Got it.
I infer that generateContent
will eventually become deprecated, as the new API, Vertex, no longer includes this method. Regardless, you can use streamGenerateContent
without streaming by choosing not to enable server-sent events (?alt=sse
). Curiously, you can also use server-sent events with generateContent
, even though it is not designed for "streaming". Yeah, this is confusing.
I would be inclined to distinguish between the concept of an HTTP request that creates a stream to receive server-sent events and the concept of streaming related to the expected behavior and output format of the endpoints.
Why? We have a lot of possible endpoints in the API:
All of them may support "streaming" (Server-Sent Events) or not.
I would prefer to keep the names of the methods faithful to the original names of the raw cURL API:
Allowing any of them to be accessed through a standard HTTP request or by enabling server-sent events.
Perhaps the refactoring needed to eliminate ambiguity and confusion for users would be renaming stream
to server_sent_events
. This change would clearly distinguish the concept of streaming from SSE, I believe:
client = Gemini.new(
credentials: { ... },
options: { model: 'gemini-pro', server_sent_events: true }
)
client.stream_generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: true
) do |event, parsed, raw|
puts event
end
result = client.stream_generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: false
)
result = client.generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
)
client.generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: true
) do |event, parsed, raw|
puts event
end
Does that make sense?
Yeah I'm liking that, and I also strongly agree that keeping the method names the same as the raw API urls will be most intuitive moving forward.
I'm wondering if I'm missing a configuration. My response is broken up into numerous parts. I know I could combine them, but I'm wondering why this result is different than what I get when I run a curl command to hit the API.
I run this:
and I get this response: