-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gateway OpenAPI schema live documentation #614
Conversation
e2833ce
to
3712dd3
Compare
d355868
to
ea138b3
Compare
import { chainEventPresenter } from '$/common/documents/getData' | ||
|
||
// @ts-expect-error: streamSSE has type issues | ||
export const chatHandler: AppRouteHandler<ChatRoute> = async (c) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reason types are not working at this level. cc @neoxelox . Not only in SSE endpoints, in any of then. No big deal tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mmm that's probably why I did what I did, handlers + route def altogether... this types are magical... but if c.req.valid
does complain when getting unknown parameters from the request schema... I guess I am okay with that
export const getRouteV2 = getRouteFactory({ | ||
path: ROUTES.v2.documents.get, | ||
tags: ['Documents'], | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With this abstraction in place reusing routes is as easy as changing the path if the implementation didn't change
ea138b3
to
acffc2c
Compare
acffc2c
to
c9ce2f8
Compare
|
||
import { swaggerUI } from '@hono/swagger-ui' | ||
|
||
import packageJson from '../../package.json' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lol
import { OpenAPIHono } from '@hono/zod-openapi' | ||
|
||
export function createRouter() { | ||
return new OpenAPIHono({ strict: false }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does strict
mean in there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}) | ||
|
||
export const configSchema = z.object({}).passthrough() | ||
export const providerLogSchema = z.object({}).passthrough() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no schema for provider log?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It has not really been used in the API afaik
@@ -122,3 +74,45 @@ async function validatedEvalConnectedToDocument({ | |||
throw new BadRequestError('The evaluation is not connected to this prompt') | |||
} | |||
} | |||
|
|||
// @ts-expect-error: streamSSE has type issues |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the type issue really because of streamSSE? I think it is because we are separating the handler from the magical createRoute, I would put that in the comment instead of streamSSE? (Also this handler does nothing about SSEs)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah there's no sse herem, why are we escaping the type checking?
@@ -18,7 +18,7 @@ describe('GET documents', () => { | |||
describe('unauthorized', () => { | |||
it('fails', async () => { | |||
const res = await app.request( | |||
'/api/v1/projects/1/versions/asldkfjhsadl/documents/path/to/document', | |||
'/api/v2/projects/1/versions/asldkfjhsadl/documents/path/to/document', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why the change from v1 to v2?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before the implementation was in v1. So the test. Now I moved the implementation to v2, so the test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Buena currada refactorizando todo! The only thing I would say it to check out the comments saying "Types not working because of SSEs", I don't think its that. I think it is because we are separating the handler from the magical createRoute, I would put that in the comment instead?
app.route('/', v1Routes) | ||
app.route('/', documents) | ||
app.route('/', conversations) | ||
app.route('/', telemetry) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm this is very painful for the reader no? now there's no easy way to know what routes we are exposing you'd have to check every router
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I would have like is something similar to rails where routes.rb declares all the routes and routers are just the controllers with the handlers for each endpoint in that route
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -118,7 +118,12 @@ describe('POST /chat', () => { | |||
messages: [ | |||
{ | |||
role: MessageRole.user, | |||
content: 'fake-user-content', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm this should be valid content
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not according to this schema
https://github.com/latitude-dev/latitude-llm/blob/main/packages/core/src/constants.ts#L226-L243
This started failing now because before we did this "truquito"
import { messageSchema } from '@latitude-data/core/browser'
const messagesSchema = z.array(z.any(messageSchema))
βοΈ This is using any
What I did was remove the any
const messagesSchema = z.array(messageSchema)
And now types works!
import { CreateLogRoute } from '$/routes/v2/documents/logs/create.route' | ||
import { getData } from '$/common/documents/getData' | ||
|
||
// @ts-expect-error: broken types |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i mean could we fix types π it looks like this PR is breaking all types
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before we were not using openapi so no old types broken. Just this
AppRouteHandler<CreateLogRoute>
And is because it does a complex generic black magic. But types inside the handlers all work nicely
What?
Implement OpenAPI + Swagger UI for Latitude gateway API endpoints
Issue
#499
TODO
/run
api v2 β@hono/zod-validator