faststore
faststore copied to clipboard
vtex
Change API of Simulation
When building in a marketplace project, it gives the error "Could not communicate with seller XXXX", this happens because of the seller's problems but we can't depend on it, since this error is not constant, but with the load used in the build it happens more often.
So I wanted to change the API used, which today is the orderForms/simulation API in simulation.ts, to another one where this error does not occur.
But I saw that you use the API to get prices from sellers, but there are others that come with a price, such as the catalog, or the offers API, but I came to see that in the product.ts resolver that the simulationLoader.load is called (items) that fetches this information from the seller, there is the "product" object that has the seller's data as well.
So no request need to be made, but since I'm not aware of the whole code context, I wanted to know why they decided to use the simulation API just to get prices instead of another one, or even get the data from that "product" object.
Hi @LucasFrSoma! I'm not sure I understood the problem you're facing. Is the build failing because of that error?
What are some of the pros and cons you see in changing the API used? And what API would you changed it to?
Yes, the build is failing because of that error.
The pros I see that it will not depend on communication with the seller, and to talk about the cons, I will comment on the three APIs that I was thinking, either the catalog search, or the offers.
Search API - https://developers.vtex.com/vtex-rest-api/reference/search-3#productsearch Offers API - https://developers.vtex.com/vtex-rest-api/reference/offers#get_api-catalog-system-pub-products-offers-productid-sku-skuid SKU API - https://developers.vtex.com/vtex-rest-api/reference/catalog-api-sku#catalog-api-get-sku-context
The problem with using the SKU and Offers API is that we have to do one request for each SKU. That way I see that the Search API is more advantageous, but one cons I'm not sure, you know if the simulation API has less cache than the catalog?
Also, I realized that an object before any request is made already has the data, so I was wondering why you used an API for this.
Tomorrow I will populate here with more data.
In general, the main advantage in using the Simulation endpoint of the Checkout API is that it will consider the same conditions as our Checkout - including special pricing for customer clusters, promotions, multiple sellers, freight SLA, etc. So that yields conditions that are closer to the ones seen by customers at checkout.
Could you list a few builds that are failing in your store because of that error? I think we need to understand in more depth why this error is occurring and in which pages.
Also, are you just worried about prices? Or are there other variables you'd like to change how we fetch from VTEX?
Of course, follow some builds failing:
I'm worried about the prices because the reason I saw they used the simulation API was just to get the prices of the products. I talked internally with a team that has already worked with this Simulation API, and they told me that they had several problems with it, and VTEX itself recommended not using it anymore, so they switched to the one from Calculate SLA, https://developers.vtex.com/vtex-rest-api/reference/sla.
It turns out that their demand was different, but I'll see if this API work for what we need.
