Frontend API Bundle

[dpfaffenbauer]

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC?	yes

In order for CoreShop to be used in PWA/SPA we need a proper Frontend API.

• Define what API Endpoints we need.

[davidhoeck]

Products and Categories

Method	Description	Parameters
GET	All Products	page or skip and limit
GET	Single Product by ID	productId
GET	All Categories hierarchic with subcategories	maxDepth
GET	Single Category with its subcategories	categoryId maxDepth
GET	All products of a single category	categoryId, maxDepth, page or skip and limit

Cart

Method	Description	Parameters
POST	Add Product to the cart	productId quantity
PUT	Update CartItem	cartItemId productId quantity
DELETE	Remove CartItem from Cart	cartItemId
GET	Get the Cart	cartIdentifier(optional)
POST	Add a discount/voucher code to the cart	code
DELETE	Remove a discount/voucher code from the cart	code

Checkout

Method	Description	Parameters
GET	All Checkout steps
PUT	Persist a cart step	stepIdentifier
POST	Create a new address for the customer	-
DELETE	Remove an address of the customer	addressId

[solverat]

Cart

• Add multiple items

Index

• Get Index Data (Data Hub Thing?), related: #692

[dpfaffenbauer]

https://github.com/coreshop/FrontendApiBundle

[dpfaffenbauer]

Multiple ways of actually doing this:

• Custom FrontendAPI Bundle with API Platform
• Integration with DataHub

@davidhoeck you are working on something like this right?

[davidhoeck]

@dpfaffenbauer yes - but still under heavy development and we are trying to find the right architecture. problem is basically that datahub is not built for performance because schema cannot be cached and is initialized on every request

[dpfaffenbauer]

Will you open source what you have?

[dkarlovi]

@davidhoeck can we fix the "not built for performance" upstream? I'd expect them to cache metadata in prod, same as any other integration.

[davidhoeck]

@dkarlovi nope they don't. the schema get's initialized every time. when you take a look at a data hub request with blackfire, you see that the graph (queries + mutations) is built basically every request. I tried to implement a cache layer, but there was a loss of the resolver information.

[davidhoeck]

@dpfaffenbauer yep, but we will migrate it to coreshop 3 before that.

[dkarlovi]

@davidhoeck that's unfortunate. I'll check it out in Blackfire, thanks for the hint! :beers:

[dkarlovi]

Note for the above list, "All products" (and basically any listing) should by default support search, filter and sort params.

[davidhoeck]

@dkarlovi well, product listing is handled by the native data hub listing. CoreShop Index is a little bit more complex to use and we did not have implement it yet.

[dkarlovi]

We actually have a very custom Elasticsearch based Index which uses the Coreshop interfaces, but implements the search & filter stuff on our own. Not sure this would work by default via the Datahub feature, I'd expect it to be more tightly linked to Pimcore's implementation and database (which here doesn't exist).

I didn't look into it, but wanted to note listings should expect to accept filters, search and sort related params, for completeness sake.