swiftcommerce / productmanager Goto Github PK

Add RevertCommand to CommandConfig and register it to the application's services. This allows you to run vapor run revert to revert the database.

This is neither urgent nor needed right now but it will be needed soon:

Every list return (categories + products) needs to be returned in a format that we can put it on different pages. Say we have 1000 categories and 1000 products:

1. We need a return with a max number of results ("per page") Like "25 per page". So every call should return max 25 results.
2. We need a number of results in total (1000 products)
3. We need an offset that we can set so that we get for example products 100-125.

Ideally this will look like:
products?max=25&offset=100
categories?max=25&offset=100

Should not be very hard to implement. It really just comes down to the sql function "LIMIT x, y".
Important though: The total number of results needs to be returned as well.

We are storing a price value as a Double. That is a really bad idea.

We need to store the value in a different format. See Vapor Slack #beta channel starting here: https://codevapor.slack.com/archives/C4QRYJ6DD/p1523653483000064

We need a field "currency" that is 3-letters long and would be "EUR", "USD", "GBR" etc.

This is neither urgent nor needed right now, but attributes should be translatable.

Use case is that an attribute may be a description that needs to be available in multiple languages.

We need to have a flag that indicates whether a category is a main category or not. Some categories will only be sub categories and never main.

I suggest a flag called "mainCateegory" that is either true or false.

The tree should start with the main categories.

Prices need to be assignable to products. Note: Multiple prices need to be assignable to the same product.

For example:

• Piano = 50 USD, 45 EUR, 40 GBR (so 3 prices for the same product)

Categories need to have a "sort" flag (integer) that will dictate the order in which they are showing. lowest = top, highest = bottom.

...

The way it should work is:

Attribute-Table contains all attributes that are available at all. Pretty much just the same.

Attribute-Product-Tabe contains the associations between the attribute and the product. So it would be:

1. Attribute id
2. product id
3. value

just like the other services :)

We need to add CORS headers so that web browser clients can load content.
"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://product-manager-development.vapor.cloud/categories. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).".

In Vapor 2 there was a middleware module that did the trick, do we have that in vapor 3 as well?

it really should just link the existing attributes to that product

When two entries are invested (left = right & right = left) it can lead to endless recursion.

To prevent this we should:

• Prevent the user from entering such a condition in the first place
• More importantly though: Have the category-tree parser detect this and stop by itself

We need to implement a few filters for products:

• By category (we have that already but we may want to change the URL structure for it)
• By price (min & max price)
• By attribute
• By status

Ideally I would like to have a call like:

/products?minPrice=10&maxPrice=50&attribute[name]=Test+Product&status=1

or something like that

Not urgent!

We need to add UpdatedAt and DeletedAt as all as CreatedAt for:

• Products
• Categories
• Attributes
• ProductAttributes
• ProductCategories

This is neither urgent nor needed right now but will be relevant soon:

Every attribute and field of a product or category needs to be sortable. So for example:

• Sort products by lowest price
• sort products by name ascending
• sort products by category name

This one is not needed for quite a while but I don't want to loose sight of it:

We should use ElasticSearch as a Cache as well as a search engine for products. So every product would be put into elastic search as an exported json-string.

Through elastic search we can run effective searches and also cache outputs.

The attribute controller/routes should have their own identity.

So we should have routes like
attributes/create
attributes/update
attributes (list)

etc. that deal with the attributes independently of products

likewise when creating an attribute for a product it should link to the ID of attribute.
so
POST products/1/attributes should take arguments such as (attributeId,language, value)