Service - Catalog Standard: Difference between revisions

From Izara Wiki
Jump to navigation Jump to search
No edit summary
 
(27 intermediate revisions by the same user not shown)
Line 5: Line 5:
= Repository =
= Repository =


https://bitbucket.org/stb_vit/catalog-standard/src/master/
https://bitbucket.org/stb_working/catalog-standard/src/master/


= DynamoDB tables =
= DynamoDB tables =
Line 15: Line 15:
<syntaxhighlight lang="JavaScript">
<syntaxhighlight lang="JavaScript">
{
{
configTag: "CatalogTreeServiceName"
configTag: "CatalogServiceNameTag"
configKey: {eg: "CatalogTreeServiceName"}
configKey: "CatalogServiceNameTag"
configValue: {eg: "CatalogTreeStandard"}
configValue: xxx // this own services CatalogServiceTag, eg "CatalogStandard"
}
}
</syntaxhighlight>
</syntaxhighlight>


== Catalog ==
<syntaxhighlight lang="JavaScript">
{
configTag: "CatalogGraphServiceName"
configKey: "CatalogGraphServiceName"
configValue: xxx // eg: "CatalogGraph"
}
</syntaxhighlight>
 
<syntaxhighlight lang="JavaScript">
{
configTag: "CatalogManagerServiceName"
configKey: "CatalogManagerServiceName"
configValue: xxx // eg: "CatalogManager"
}
</syntaxhighlight>
 
<syntaxhighlight lang="JavaScript">
{
configTag: "TranslationsServiceName"
configKey: "TranslationsServiceName"
configValue: xxx // eg: "Translations"
}
</syntaxhighlight>
 
<syntaxhighlight lang="JavaScript">
{
configTag: "CategoryTreeService"
configKey: xxx // categoryTreeServiceNameTag, eg: "CategoryTreeStandard", this is what is saved in each catalog record
configValue: {
serviceName: xxx // eg: "CategoryTreeStandard", this is the actual deployed service name}
}
}
</syntaxhighlight>
 
= Graph database =
 
== [[Service - Catalog Graph]]==
 
=== Nodes ===
 
==== catalog ====
 
Is an origin/home/top-level node, one per catalog, allows for top level categories in that catalog to be point to a single origin node.
 
* NodeIdentifierLabels: catalog
* NodeIdentifierProperties: catalogId (random uuid)
 
Properties:
 
# searchType: sellOffer|product|variantProduct, will match the setting in the catalog service
# filter: full filter for the catalog, will combine all child categoryNode filters with the setting in the catalog service
# requiredData: full requiredData for this catalog, will match the setting in the catalog service
 
==== catalogSettings ====
 
Versioned data Holding the editable settings for a catalog.
 
Properties:
 
# searchType: product|variant|variantProduct
# filter: stringified object containing default search result filter
# requiredData: stringified object containing default search result requiredData
# categoryTreeServiceName: eg: "CategoryTreeStandard"


=== Fields ===
== [[Service - Translations Graph]] ==


; catalogId
=== Nodes ===
: (partition key)
; filter
: stringified object containing default search result filter
; searchType
: product|variant|variantProduct
: default searchType


= Filter for each categoryTreeNode =
==== CatalogName ====


* In most cases all categoryTreeNodes will share the same filter, matching the catalog's filter, but allow for each categoryTreeNode to set its own. When this happens it will likely add to the default filter, to maintain a standard experience for the user.
* NodeIdentifierLabels: catalogName
* When creating a new categoryTreeNode for a catalog the requiredData and filter for the node can be set, if not set the default is to inherit from that node's parent categoryTreeNode. If is a top level node it inherits from the catalog's (default) filter.
* NodeIdentifierProperties: catalogId
* Not sure how to handle updating catalog's (default) filter, perhaps have a bool in the categoryTreeNode that sets whether it's filter should track and update when catalog filter updates.


= Ideas =
= Ideas =

Latest revision as of 11:46, 26 June 2021

Overview

Handler service for the standard catalog type.

Repository

https://bitbucket.org/stb_working/catalog-standard/src/master/

DynamoDB tables

Standard Config Table Per Service

Configuration tags

{
	configTag: "CatalogServiceNameTag"
	configKey: "CatalogServiceNameTag"
	configValue: xxx // this own services CatalogServiceTag, eg "CatalogStandard"
}
{
	configTag: "CatalogGraphServiceName"
	configKey: "CatalogGraphServiceName"
	configValue: xxx // eg: "CatalogGraph"
}
{
	configTag: "CatalogManagerServiceName"
	configKey: "CatalogManagerServiceName"
	configValue: xxx // eg: "CatalogManager"
}
{
	configTag: "TranslationsServiceName"
	configKey: "TranslationsServiceName"
	configValue: xxx // eg: "Translations"
}
{
	configTag: "CategoryTreeService"
	configKey: xxx // categoryTreeServiceNameTag, eg: "CategoryTreeStandard", this is what is saved in each catalog record
	configValue: {
		serviceName: xxx // eg: "CategoryTreeStandard", this is the actual deployed service name}
	}
}

Graph database

Service - Catalog Graph

Nodes

catalog

Is an origin/home/top-level node, one per catalog, allows for top level categories in that catalog to be point to a single origin node.

  • NodeIdentifierLabels: catalog
  • NodeIdentifierProperties: catalogId (random uuid)

Properties:

  1. searchType: sellOffer|product|variantProduct, will match the setting in the catalog service
  2. filter: full filter for the catalog, will combine all child categoryNode filters with the setting in the catalog service
  3. requiredData: full requiredData for this catalog, will match the setting in the catalog service

catalogSettings

Versioned data Holding the editable settings for a catalog.

Properties:

  1. searchType: product|variant|variantProduct
  2. filter: stringified object containing default search result filter
  3. requiredData: stringified object containing default search result requiredData
  4. categoryTreeServiceName: eg: "CategoryTreeStandard"

Service - Translations Graph

Nodes

CatalogName

  • NodeIdentifierLabels: catalogName
  • NodeIdentifierProperties: catalogId

Ideas

  • One filter that will normally be on, but could be removed, is to only show items that have available quantity, this will tie into the locationtreenodeid.

Working documents

Catalog Standard