I run this website for my dad which pulls tweets from his twitter feed and displays them in an alternative format. Currently, the tweets are pulled using javascript so entirely client-side. Is the most efficient way of doing things? The website has next to no hit rate but I'm just interested in what would be the best way to scale it. Any advice would be great. I'm also thinking of including articles in the stream at some point. What would be the best way to implement that?
我为我的父亲运行这个网站,从他的推文提取中提取推文并以其他格式显示它们。目前,推文是使用javascript完全拉客户端的。是最有效的做事方式吗?该网站几乎没有命中率,但我只是对什么是最好的扩展方式感兴趣。任何建议都会很棒。我也想在某个时候在流中包含文章。实现这一目标的最佳方式是什么?
6 个解决方案
#1
7
Twitter API requests are rate limited to 150 an hour. If your page is requested more than that, you will get an error from the Twitter API (an HTTP 400 error). Therefore, it is probably a better idea to request the tweets on the server and cache the response for a certain period of time. You could request the latest tweets up to 150 times an hour, and any time your page is requested it receives the cached tweets from your server side script, rather than calling the API directly.
Twitter API请求的速率限制为每小时150个。如果您的页面请求的次数超过此值,您将收到来自Twitter API的错误(HTTP 400错误)。因此,在服务器上请求推文并在一段时间内缓存响应可能是更好的主意。您可以每小时请求最新的推文达150次,并且每当您的页面被请求时,它都会从您的服务器端脚本接收缓存的推文,而不是直接调用API。
From the Twitter docs:
来自Twitter文档:
Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request.
未经身份验证的呼叫每小时允许150个请求。未经身份验证的呼叫是根据发出请求的服务器或设备的面向公众的IP来衡量的。
I recently did some work integrating with the Twitter API in exactly the same way you have. We ended up hitting the rate limit very quickly, even just while testing the app. That app does now cache tweets at the server, and updates the cache a few times every hour.
我最近做了一些与Twitter API集成的工作方式与您完全相同。即使只是在测试应用程序时,我们也很快达到了速率限制。该应用现在可以在服务器上缓存推文,并且每小时更新缓存几次。
#2
1
I would recommend using client-side to call the Twitter API. Avoid calling your server. The only downfall to using client-side js is that you cannot control whether or not the viewer will have js deactivated.
我建议使用客户端来调用Twitter API。避免调用您的服务器。使用客户端js的唯一缺点是你无法控制观众是否会停用js。
What kind of article did you want to include in the stream? Like blog posts directly on your website or external articles?
您希望在流中包含哪些文章?喜欢直接在您的网站或外部文章上的博客文章?
#3
0
By pulling the tweets server side, you're routing all tweet traffic through your server. So, all your traffic is then coming from your server, potentially causing a decrease in the performance of your website.
通过拉动推文服务器端,您将通过服务器路由所有推文流量。因此,您的所有流量都来自您的服务器,可能会导致您网站的性能下降。
If you don't do any magic stuff with those tweets that aren't possible client side, I should stick with your current solution. Nothing wrong with it and it scales tremendously (assuming that you don't outperform Twitter's servers of course ;))
如果你不对那些不可能是客户端的推文做任何神奇的事情,我应该坚持你当前的解决方案。它没有任何问题,并且它的规模非常大(假设你当然没有超越Twitter的服务器;))
#4
0
Pulling your tweets from the client side is definitely better in terms of scalability. I don't understand what you are looking for in your second question about adding articles
从可扩展性方面来说,从客户端提取推文肯定更好。在你关于添加文章的第二个问题中,我不明白你在寻找什么
#5
0
I think if you can do them client side go for it! It pushes the bandwith usage to the browser. Less load on your server. I think it is scalable too. As long as your client can make a web request they can display your site! doesn't get any easier than that! Your server will never be a bottle neck to them!
我想如果你能做到这一点客户端就去吧!它将带宽用法推送到浏览器。减少服务器负载。我认为它也是可扩展的。只要您的客户可以发出网络请求,他们就可以显示您的网站!没有比这更容易!你的服务器永远不会成为他们的瓶颈!
If you can get articles through an api i would stick to the current setup keep everythign client side.
如果你能通过api获得文章我会坚持当前的设置保持每个客户端。
#6
0
For really low demand stuff like that, it's really not going to matter a whole lot. If you have a large number of tasks per user then you might want to consider server side. If you have a large number of users, and only a few tasks (tweets to be pulled in or whatever) per user, client side AJAX is probably the way to go. As far as your including of articles, I'd probably go server side there because of the size of the data you'll be working with..
对于那种非常低需求的东西,它真的不重要。如果每个用户有大量任务,那么您可能需要考虑服务器端。如果您拥有大量用户,并且每个用户只有少数任务(推文或其他内容),那么客户端AJAX可能就是您的选择。至于你的文章,我可能会去服务器端,因为你将使用的数据大小..
#1
7
Twitter API requests are rate limited to 150 an hour. If your page is requested more than that, you will get an error from the Twitter API (an HTTP 400 error). Therefore, it is probably a better idea to request the tweets on the server and cache the response for a certain period of time. You could request the latest tweets up to 150 times an hour, and any time your page is requested it receives the cached tweets from your server side script, rather than calling the API directly.
Twitter API请求的速率限制为每小时150个。如果您的页面请求的次数超过此值,您将收到来自Twitter API的错误(HTTP 400错误)。因此,在服务器上请求推文并在一段时间内缓存响应可能是更好的主意。您可以每小时请求最新的推文达150次,并且每当您的页面被请求时,它都会从您的服务器端脚本接收缓存的推文,而不是直接调用API。
From the Twitter docs:
来自Twitter文档:
Unauthenticated calls are permitted 150 requests per hour. Unauthenticated calls are measured against the public facing IP of the server or device making the request.
未经身份验证的呼叫每小时允许150个请求。未经身份验证的呼叫是根据发出请求的服务器或设备的面向公众的IP来衡量的。
I recently did some work integrating with the Twitter API in exactly the same way you have. We ended up hitting the rate limit very quickly, even just while testing the app. That app does now cache tweets at the server, and updates the cache a few times every hour.
我最近做了一些与Twitter API集成的工作方式与您完全相同。即使只是在测试应用程序时,我们也很快达到了速率限制。该应用现在可以在服务器上缓存推文,并且每小时更新缓存几次。
#2
1
I would recommend using client-side to call the Twitter API. Avoid calling your server. The only downfall to using client-side js is that you cannot control whether or not the viewer will have js deactivated.
我建议使用客户端来调用Twitter API。避免调用您的服务器。使用客户端js的唯一缺点是你无法控制观众是否会停用js。
What kind of article did you want to include in the stream? Like blog posts directly on your website or external articles?
您希望在流中包含哪些文章?喜欢直接在您的网站或外部文章上的博客文章?
#3
0
By pulling the tweets server side, you're routing all tweet traffic through your server. So, all your traffic is then coming from your server, potentially causing a decrease in the performance of your website.
通过拉动推文服务器端,您将通过服务器路由所有推文流量。因此,您的所有流量都来自您的服务器,可能会导致您网站的性能下降。
If you don't do any magic stuff with those tweets that aren't possible client side, I should stick with your current solution. Nothing wrong with it and it scales tremendously (assuming that you don't outperform Twitter's servers of course ;))
如果你不对那些不可能是客户端的推文做任何神奇的事情,我应该坚持你当前的解决方案。它没有任何问题,并且它的规模非常大(假设你当然没有超越Twitter的服务器;))
#4
0
Pulling your tweets from the client side is definitely better in terms of scalability. I don't understand what you are looking for in your second question about adding articles
从可扩展性方面来说,从客户端提取推文肯定更好。在你关于添加文章的第二个问题中,我不明白你在寻找什么
#5
0
I think if you can do them client side go for it! It pushes the bandwith usage to the browser. Less load on your server. I think it is scalable too. As long as your client can make a web request they can display your site! doesn't get any easier than that! Your server will never be a bottle neck to them!
我想如果你能做到这一点客户端就去吧!它将带宽用法推送到浏览器。减少服务器负载。我认为它也是可扩展的。只要您的客户可以发出网络请求,他们就可以显示您的网站!没有比这更容易!你的服务器永远不会成为他们的瓶颈!
If you can get articles through an api i would stick to the current setup keep everythign client side.
如果你能通过api获得文章我会坚持当前的设置保持每个客户端。
#6
0
For really low demand stuff like that, it's really not going to matter a whole lot. If you have a large number of tasks per user then you might want to consider server side. If you have a large number of users, and only a few tasks (tweets to be pulled in or whatever) per user, client side AJAX is probably the way to go. As far as your including of articles, I'd probably go server side there because of the size of the data you'll be working with..
对于那种非常低需求的东西,它真的不重要。如果每个用户有大量任务,那么您可能需要考虑服务器端。如果您拥有大量用户,并且每个用户只有少数任务(推文或其他内容),那么客户端AJAX可能就是您的选择。至于你的文章,我可能会去服务器端,因为你将使用的数据大小..