Skip to content
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

Merged
merged 8 commits into from
Nov 10, 2021

Conversation

millotp
Copy link
Collaborator

@millotp millotp commented Nov 5, 2021

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 command yarn build:spec.

Some types are not correct in the SearchParams because they require union (like string | boolean).

@millotp millotp requested review from damcou and shortcuts November 5, 2021 09:06
@millotp millotp self-assigned this Nov 5, 2021
Copy link
Member

@shortcuts shortcuts left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
operationId: searchSingle
operationId: search

We should keep the same naming

Copy link
Collaborator Author

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

Copy link
Member

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:
Copy link
Member

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

Copy link
Contributor

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.

Copy link
Member

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?

Copy link
Contributor

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 🚀

spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
Copy link
Contributor

@bodinsamuel bodinsamuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good 🙏🏻

spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
@damcou
Copy link
Contributor

damcou commented Nov 5, 2021

I'm being tatillon, but shouldn't we stay consistent regarding YAML file extension between .yml and .yaml ? :p

@bodinsamuel
Copy link
Contributor

Jean Michel Tatillon

spec_sample.yaml Outdated Show resolved Hide resolved
spec_sample.yaml Outdated Show resolved Hide resolved
Copy link
Contributor

@damcou damcou left a 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 ;) .

Copy link
Member

@shortcuts shortcuts left a 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",
Copy link
Member

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

Copy link
Collaborator Author

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Collaborator Author

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)
Copy link
Member

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

@@ -0,0 +1,58 @@
post:
tags:
- object
Copy link
Member

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
Copy link
Member

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)

Comment on lines 44 to 46
strategy:
type: string
enum: ["none", "stopIfEnoughMatches"]
Copy link
Member

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

Copy link
Collaborator Author

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 ?

Copy link
Member

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.

Copy link
Collaborator Author

@millotp millotp Nov 9, 2021

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.

Copy link
Collaborator Author

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 ?

Copy link
Collaborator Author

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 ?

Copy link
Member

@shortcuts shortcuts Nov 9, 2021

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:
Copy link
Member

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

Copy link
Collaborator Author

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

Copy link
Contributor

@bodinsamuel bodinsamuel left a 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...

openapi_spec/spec.yml Show resolved Hide resolved
content:
application/json:
schema:
$ref: '../schemas/Error.yml'
Copy link
Contributor

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

Copy link
Collaborator Author

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 ?

Copy link
Contributor

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'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

openapi_spec/paths/indexes/search.yml Outdated Show resolved Hide resolved
openapi_spec/paths/indexes/saveObject.yml Show resolved Hide resolved
type: object
additionalProperties: false
properties:
indexName:
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants