feat(clients): add new realtime-personalization api #4613
Conversation
✔️ Code generated!
📊 Benchmark resultsBenchmarks performed on the method using a mock server, the results might not reflect the real-world performance.
|
specs/realtime-personalization/common/schemas/personalizationFilters.yml
Outdated
Show resolved
Hide resolved
benamib
changed the title
| $ref: '#/searchFilters' | ||
|
|
||
| searchFilters: | ||
| type: object |
There was a problem hiding this comment.
Does this allow us to store search configurations for multiple groups of indices, and have a dynamic name?
Example extracted from Francois' presentation:
Not sure how we represent that in the spec though.
There was a problem hiding this comment.
The attribute additionalProperties allows us to tell the generator that the key of the object can be dynamic but that the format of the value should be of type searchFilters.
I'm not fond of this method but we don't have too much choice to respect the response we want.
We could still challenge the response format to replace the objects by arrays which would make the specs clearer imo like:
...
"search": [
{ "aliases": "abc", "strategy": "def", "filters": {...} }
]
...There was a problem hiding this comment.
With the current specs the generated exemples looks like this :
{
"version": "string",
"userID": "string",
"search": {
"additionalProp1": {
"indices": [
"storefront",
"storefront_price_asc",
"storefront_price_desc"
],
"strategy": "session",
"filters": {
"session": [
"brand:Dyson<score=12>"
],
"additionalProp1": {}
},
"additionalProp1": {}
},
"additionalProp2": {
"indices": [
"storefront",
"storefront_price_asc",
"storefront_price_desc"
],
"strategy": "session",
"filters": {
"session": [
"brand:Dyson<score=12>"
],
"additionalProp1": {}
},
"additionalProp1": {}
},
"additionalProp3": {
"indices": [
"storefront",
"storefront_price_asc",
"storefront_price_desc"
],
"strategy": "session",
"filters": {
"session": [
"brand:Dyson<score=12>"
],
"additionalProp1": {}
},
"additionalProp1": {}
}
},
"additionalProp1": {}
}There was a problem hiding this comment.
I believe the reason for this structure was so that the FE could retrieve the required attributes as quick as possible (it's more time consuming to filter an array based on a key than it is to get a specific key from a map).
This looks good for now, but if it causes issues we can rethink it
shortcuts
changed the title
| @@ -0,0 +1,8 @@ | |||
| # path | |||
| UserToken: | |||
| name: userToken | |||
There was a problem hiding this comment.
We call this userID in all the personalization APIs.
| name: userToken | ||
| in: path | ||
| required: true | ||
| description: Unique identifier representing a user for which to fetch the personalization profile. |
There was a problem hiding this comment.
| description: Unique identifier representing a user for which to fetch the personalization profile. | |
| description: Unique identifier used to retrieve the personalization profile of a specific user. |
| - name: users | ||
| x-displayName: Users | ||
| description: | | ||
| User profiles contains the search filters each user has for the different facets in your index. |
There was a problem hiding this comment.
| User profiles contains the search filters each user has for the different facets in your index. | |
| User profiles contain search filters that personalize search results in real time. |
🧭 What and Why
🎟 JIRA Ticket: https://algolia.atlassian.net/browse/PRED-3652
Changes included:
TODO
🧪 Test