调用 10 个 API 同时保持良好用户体验的最佳解决方案?

发布于 2024-11-25 12:57:26 字数 275 浏览 1 评论 0原文

我有一个类似于 Expedia 和 Priceline 的网站。用户输入日期,然后调用 10 个不同的 API 来返回结果。从所有 10 个结果中获取结果可能(有时)最多需要 90 秒。

我想要的是在用户等待结果时显示启动/加载屏幕(类似于 Priceline)。

我尝试使用 jQuery Ajax 调用 API 并生成结果,但某些浏览器遇到问题(当结果不够快时锁定)。

我在 LAMP 环境中,我想过使用 cronjob 来处理 API 并将结果保存在数据库中,但我不确定这有多实用。

I have a site similar to Expedia and Priceline. The user enters dates and then 10 different APIs are called to return results. Getting results from all 10 can (at times) take up to 90 seconds.

What I'd like to have is the splash/loading screens (similar to Priceline) to display while the user waits for results.

I have tried using jQuery Ajax to call the APIs and generate results, but some browsers experience issues (locking up when results aren't fast enough).

I'm on a LAMP environment and I've thought of using a cronjob to process the APIs and save the results in a database, but I'm not sure how practical that would be.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

夜光 2024-12-02 12:57:26
  1. 所有 ajax 调用都需要异步,以便用户界面保持活动状态。这应该是显而易见的,但既然你提到了浏览器锁定,我想我最好提一下这一点。
  2. 您可能需要了解浏览器是否对每个浏览器窗口允许的并发 ajax 调用数量有限制。如果他们这样做了,而且数量少于你想要的,你将不得不重新考虑事情。
  3. 在等待结果时,您肯定想放置一些“正在加载结果...”类型的指示器。
  4. 如果您的数据是可以显示渐进式结果的数据(例如,当每个 ajax 调用返回时显示一些新信息),那么用户会感觉该函数比您等待所有 10 个操作完成后再显示任何内容的响应速度更快。
  5. 对于任何事情,只要您的呼叫正在进行,用户就应该有一种简单的方法来停止事务并返回到您网站中的有用位置(无需关闭浏览器窗口或离开您的网站)。您希望即使是不耐烦的用户至少再试一次而不是离开。
  6. 如果您在同时连接时遇到浏览器模仿,您可能希望让服务器代理该请求。向您的服务器发送少量请求,然后让它根据需要触发尽可能多的总请求并返回整理后的数据。
  7. 如果所请求的数据可以有效地缓存或预取到您的服务器上而不影响准确性,那么这可能确实有助于提高性能。
  8. 确保处理 ajax 调用上的所有错误条件,以便用户体验至少允许用户重试,或者在某些连接不起作用时最多继​​续执行,但结果较少。
  9. 了解 ajax 代码中所有连接超时的设置,并确保它们适合您的应用程序。如果默认连接超时时间不足以封装大部分 ajax 调用,您可能需要延长它。
  10. 针对一个或多个 ajax 调用失败的情况进行设计。了解您的应用程序中将发生什么,并测试该情况以查看所需的用户体验是否真正有效。
  11. 请注意(当使用异步 Ajax 调用时)用户可以与您的页面进行交互,因此您可能需要禁用、隐藏或以其他方式阻止与用户在异步调用期间不应进行操作的页面部分的交互。
  12. 上一点的另一面是,您可能希望在等待异步调用完成时允许某些类型的交互。例如,您可能希望允许用户改变主意并开始新的请求。您可能希望他们在等待时与流程的下一步中的某些内容进行交互,等等...基本上,您在等待时可以为他们提供的信息越多,包括进度信息、部分结果或其他需要处理的内容,他们就越不会注意到或介意等待。
  1. All your ajax calls need to be asynchronous so the user interface stays alive. That should be obvious, but since you mentioned browser lockup, I figured I better mention this.
  2. You may need to find out if browsers have any per browser window limitations on the number of concurrent ajax calls they will allow. If they do and the number is less than you want to have, you will have to rethink things.
  3. You definitely want to put up some "Loading results..." type of indicators when waiting for results.
  4. If your data is the kind of data that you can show progressive results (e.g. show some new info when each ajax call returns), then the user will feel like the function is more responsive than if you wait for all 10 to finish before showing anything.
  5. For anything as long as your calls are taking, the user should have an easy way to stop the transaction and return to a useful place in your site (without having to kill the browser window or leave your site). You want even impatient users to at least try again rather than leave.
  6. If you run into browser imitations on simultaneous connections, you might want to have your server proxy the request. Send a small number of request to your server and have it, in turn, fire off as many total requests as are needed and return the collated data.
  7. If the data being requested can be effectively cached or pre-fetched on your server without influencing accuracy, then that might really help performance.
  8. Make sure you handle all error conditions on the ajax calls so the user experience at least allows the user to try again or at best continues on with fewer results if some connection doesn't work.
  9. Understand what all connection timeouts are set to in your ajax code and make sure they are appropriate for your application. If the default connection timeout time isn't long enough to encapsulate most of your ajax calls, you may need to lengthen it.
  10. Design for the condition where one or more of the ajax calls fails. Know what is going to happen in your app and test for that condition to see that the desired user experience actually works.
  11. Be aware that (when using asynchronous Ajax calls) the user can interact with your page so you may need to disable, hide or otherwise prevent interaction with parts of the page that they shouldn't fiddle with during the asynch calls.
  12. The other side of the previous point is that you may want to allow certain types of interaction while waiting for the async calls to complete. For example, you may want to allow the user to change their mind and start a new request. You may want them to interact with some things in the next step in the process while they are waiting, etc... Basically, the more you can offer them while waiting in terms of both progress info, partial results or something else to work on, the less they will notice or mind waiting.
浅浅 2024-12-02 12:57:26

您是否尝试过类似 beanstalkd 的东西?似乎如果延迟长达 90 秒,您应该对作业进行排队并在结果准备就绪时通知用户,而不是同步运行作业并显示长时间运行的启动页面。要实现推送通知,请尝试 jQuery Comet

Have you tried something like beanstalkd? It seems like if the latency is up to 90 seconds, you should queue up the jobs and notify the user when the result is ready rather than run the jobs synchronously and display a long-running splash page. To implement push notification, try jQuery Comet.

秋叶绚丽 2024-12-02 12:57:26

如果您需要一次显示所有结果,请触发对 php 页面的单个调用,并让它通过curl 进行调用。但请记住设定时间限制。

否则,将工作分成两到四个页面,并对每个页面触发 ajax 调用。当每个人返回时,显示这些结果。在这种情况下,一个简单的加载图像就足够了。这里没有溅水。

并记住尽可能缓存。

***编辑

请注意,我在这里重点关注 php 执行 api 调用。您的服务器及其 T1+ 连接肯定会比我的拨号更快地处理 10 个呼叫。 :)。

If u need to show all results at once, fire a single call to a php page and let it do the calls via curl. Remeber set time limit though.

Else, split the work up between two to four pages and fire ajax calls to each. As each returns, show those results. In this case, a simple loading image will suffice. No splash here.

And remember to cache what you can.

***Edit

Note that I'm focusing on php doing the api calls here. Your server with its T1+ connection is definitely going to handle 10 calls faster than my dialup. :).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文