Add support for Async Low Fare Search request

[skills-up]

Hi,

Just wish to know whether the API is using Async version of LowFareSearch request, or the synchronized one? Also, going by the issue log, there seems to be a lack of support for Provider = '1G'. Is this the case, or an isolated issue?

Apologies for posting the query as issue, in the absence of any direct mechanism for posting these questions.

[shmuga]

Hello @skills-up

For LFS we are using sync version. You can check that here For now we are supporting only 1G provider. There is no support of any other.

[skills-up]

Just curious, in your opinion, would async version provide a performance improvement? Specially for listing options, and booking a selected option among the retrieved list.

[articice]

@skills-up there only will be an improvement of resource usage on your side and on the front-end in the simplest use case. With async request, your server will have to process a smaller amount of options, and you can add paging or infinite scroll to your website (which preserves resources). Applicability of such solution depends on your desired functionality and system design.

We've never tested it, but IMHO the initial search time is not likely to improve. There's a basic undividable search operation underneath with request time of around 5-15 sec, which creates a TTFB (time to first byte) and it should be the same for async. It also doesn't depend on your level of provisioning, e.g. level 3 generates hundreds of pricing options (up to completely absurd ones), but search time is not longer compared to previous level.

If you're not quite satisfied with such long response times, you should try:

• provisioning e-Pricing meta search from Travelport (a simpler and faster cached request, caching provided by Travelport)
• connect an external cache, e.g. https://www.cee-systems.com/estreamingapi
• create your own caching solution.

[skills-up]

The reason I was looking for an improvement is because I've to query two fares: public fares and private fares, and then show them side by side. Since there is no option to fetch them in a single request, we end up making two requests, and the response time accordingly double to an average 13 seconds. This is basically a huge amount to time from the end user perspective. Thus, I was looking for speeding up things a bit.