Skip to content

feat(clients): add new realtime-personalization api #4613

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.

Sign up for GitHub

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

Merged
shortcuts merged 25 commits into from
Mar 25, 2025
Merged

feat(clients): add new realtime-personalization api #4613

Changes from 1 commit
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
75fdf13
feat(realtime-perso): add new realtime-perso api
Mar 17, 2025
8828aa5
update api url and path
Mar 17, 2025
3dfbf35
Merge remote-tracking branch 'origin/main' into PRED-3652/realtime-pe…
Mar 18, 2025
2526e89
update path and schemas
Mar 19, 2025
8ee8999
update clients config
Mar 20, 2025
dedef01
Merge remote-tracking branch 'origin/main' into PRED-3652/realtime-pe…
Mar 20, 2025
ca169fe
Merge remote-tracking branch 'origin/main' into PRED-3652/realtime-pe…
Mar 24, 2025
283ce30
try without additionalPropoerties
Mar 24, 2025
a2965f7
rollback change
Mar 24, 2025
e54f457
Merge branch 'main' into PRED-3652/realtime-perso-api
benamib Mar 24, 2025
0d9a3c8
fix: go
shortcuts Mar 24, 2025
9d48a55
chore: playground and javascript
shortcuts Mar 24, 2025
af4f5ea
chore: go cts
shortcuts Mar 24, 2025
2b5bc83
chore: add a test
shortcuts Mar 24, 2025
533cf7b
chore: dart
shortcuts Mar 24, 2025
16c351d
chore: client tests
shortcuts Mar 24, 2025
d84057a
chore: generation issues
shortcuts Mar 24, 2025
b355500
chore: pre-release
shortcuts Mar 24, 2025
ee86911
chore: lock
shortcuts Mar 24, 2025
043b672
chore: dart
shortcuts Mar 24, 2025
9d643d6
chore: build
shortcuts Mar 24, 2025
4f7426b
chore: cts
shortcuts Mar 24, 2025
7ec3c20
chore: cts
shortcuts Mar 24, 2025
efac20c
chore: cts
shortcuts Mar 24, 2025
d9c9219
chore: js snippets
shortcuts Mar 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
rollback change
  • Loading branch information
Bilel Benamira committed Mar 24, 2025
commit a2965f70b1cb3384047d48a4d76d5439b261e39c
12 changes: 6 additions & 6 deletions specs/realtime-personalization/common/schemas/user.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,12 +12,12 @@ user:
userID:
type: string
description: User ID of the user.
# search:
# type: object
# description: |
# Index personalization filters by index name.
# additionalProperties:
# $ref: '#/searchFilters'
search:
type: object
description: |
Index personalization filters by index name.
additionalProperties:
$ref: '#/searchFilters'

searchFilters:
type: object
Copy link
Contributor

@bengreenbank bengreenbank Mar 19, 2025

Choose a reason for hiding this comment

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

Does this allow us to store search configurations for multiple groups of indices, and have a dynamic name?

Example extracted from Francois' presentation:
Screenshot 2025-03-19 at 17 19 59

Not sure how we represent that in the spec though.

Copy link
Contributor Author

@benamib benamib Mar 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

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": {...} }
]
...

Copy link
Contributor Author

@benamib benamib Mar 20, 2025

Choose a reason for hiding this comment

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

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": {}
}

Copy link
Contributor

@bengreenbank bengreenbank Mar 20, 2025

Choose a reason for hiding this comment

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

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

Expand Down
Loading