-
Notifications
You must be signed in to change notification settings - Fork 17
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
feat: openapi sample with search, index, and batch API #4
Conversation
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.
Great work!
We know we will break a lot of things with this new client, but we should limit the footprint if possible like keeping the naming consistent (unless the previous naming does not make sense of course)
spec_sample.yaml
Outdated
post: | ||
tags: | ||
- search | ||
operationId: searchSingle |
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.
operationId: searchSingle | |
operationId: search |
We should keep the same naming
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 agree but the operationId
must be unique in the file, how do you differentiate all of those:
POST /1/indexes/{indexName}/query
GET /1/indexes/{indexName}
POST /1/indexes/*/queries
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.
IIRC there's two search
method but they are not both available on the client:
- on an initialized index:
/1/indexes/{indexName}/query
- on the client:
/1/indexes/*/queries
Since we don't have any init method yet we should only focus on the second
spec_sample.yaml
Outdated
- search | ||
operationId: searchSingle | ||
summary: Get search results | ||
parameters: |
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.
We are missing the query
here
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.
Just to be sure, we want to get rid of the other params (appId, apiKey and IndexName) to replicate what's in the current javascript client right ? As we're going to implement the init method.
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.
Indeed
I guess we could have two spec files, one without init (this one), and a new one once we know how to generate the init?
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.
Ok let's do this 🚀
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.
Looking good 🙏🏻
I'm being tatillon, but shouldn't we stay consistent regarding YAML file extension between .yml and .yaml ? :p |
Jean Michel Tatillon |
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.
Great work !
Just left comments on some structural aspect of the POC as you saw ;) .
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.
Awesome :D
I'm not able to generate from the bundle yet, maybe some missing compatibilities between openapi/swagger CLI?
@@ -6,6 +6,7 @@ | |||
], | |||
"scripts": { | |||
"generate": "PACKAGE_VERSION='4.11.0' TS_POST_PROCESS_FILE='yarn prettier --write .' yarn openapi-generator-cli generate --generator-key client && yarn install", | |||
"build:spec": "yarn swagger-cli bundle openapi_spec/spec.yml --outfile dist/openapi.yml --type yaml", |
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.
Have you been able to generate a client after building? I got some errors using the outputted file
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 with the generated file, the option --skip-validate-spec
isn't taken into account for some reason, but it works with the original openapi_spec/spec.yml
file.
default: "" | ||
similarQuery: | ||
type: string | ||
description: Overrides the query parameter and performs a more generic search that can be used to find “similar” results. |
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.
description: Overrides the query parameter and performs a more generic search that can be used to find “similar” results. | |
description: Overrides the query parameter and performs a more generic search that can be used to find "similar" results. |
Does it work without weird quotes?
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.
That's a copy paste from the doc, I didn't notice them, thanks
type: string | ||
description: Filter the query with numeric, facet and/or tag filters. | ||
default: "" | ||
# There could be a pattern for this one (complicated one) |
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 think it's close enough for our testing phase, but let's not forget later
openapi_spec/paths/indexes/batch.yml
Outdated
@@ -0,0 +1,58 @@ | |||
post: | |||
tags: | |||
- object |
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.
This is bundled with the search package atm, do we want to change it?
post: | ||
tags: | ||
- search | ||
operationId: searchMulti |
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 important at all for now but searchMulti
is a bit vague)
strategy: | ||
type: string | ||
enum: ["none", "stopIfEnoughMatches"] |
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 think this should be an object with only the strategy
option for now, it's closer to what we have actually and avoid breaking the API if we add requestOptions
in the future
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.
You mean removing the requests
property ?
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 search
methods both receive 2 parameters, query
(or queries
here) and requestOptions
(which contains the strategy
), we should have the same shape here.
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.
From the doc I understand that the body should contain the requests
and maybe the strategy
, it's not in the requestOptions
I think.
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 it a usual in the API clients to bundle the real property in a requests
property ?
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 it a usual in the API clients to bundle the real property in a requests
property ?
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.
From the doc I understand that the body should contain the requests and maybe the strategy, it's not in the requestOptions I think.
Oh I see, I was referring to our API client structure and not the REST API. Since we pass options to our transporter etc. it may differ
- $ref: "../../parameters.yml#/AppId" | ||
- $ref: "../../parameters.yml#/ApiKey" | ||
- $ref: "../../parameters.yml#/IndexName" | ||
requestBody: |
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 think we are missing the query here
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's in the search params with the rest
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.
LGTM 🪨
Potential next step is to finish one endpoint entirely so we can highlight everything, exhaustive listing of errors, all parameters, all responses, etc...
content: | ||
application/json: | ||
schema: | ||
$ref: '../schemas/Error.yml' |
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.
Might be confusing to reuse Error at this point since the example won't reflect the actual error
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 don't know if we can be exhaustive about the actual error, I agree that this is bad for the doc but the error can be anything, even for a single endpoint.
What do you have in mind to reflect the actual error ?
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.
we probably need to dig a bit deeper in the API, but not for this PR indeed
content: | ||
application/json: | ||
schema: | ||
$ref: '../schemas/Error.yml' |
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.
Same
type: object | ||
additionalProperties: false | ||
properties: | ||
indexName: |
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.
Same
@@ -0,0 +1,451 @@ | |||
type: object |
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.
This file won't scale well, I suppose we need to split it or add comments/line break/grouping because it's already hardly readable.
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 will split it in another PR, I'm still thinking what's best
Ticket: APIC-156
This is a first sample with various API to test the capabilities of the generation.
The files are split by schema and path, to bundle all the file into one big file (
dist/openapi.yml
, it can be useful for swagger editor), use the commandyarn build:spec
.Some types are not correct in the
SearchParams
because they require union (likestring | boolean
).