Hi I Have to create a timeline feed activity like facebook. I give the likes and comments using reactions.but if i give the likes again to a same post by a same person the likes count get increased. how to resolve it.
and how to use the aggregated feeds.. please give some example regarding this..
Multiple reactions from a user are allowed with the Stream API. We have a feature in the backlog to toggle this to allowed/not allowed, but I don't have an ETA for release. You can find aggregated examples here: https://getstream.io/blog/aggregated-feeds-demystified/
I'm working on an app that would automatically generate instagram hashtags for the user, allowing them to snap a photo, get auto hashtags, and post right away. Is there a way I can pull the most trending instagram hashtags in real-time and have the app generate them for every user at the time they're posting?
No, there is no direct way to get this information from the API. Though you might be able to get clever with the endpoints that are there and figure out what's trending that way.
You could query a user using the users endpoint, search through all the hashtags they've used on the last 100 or so media captions, and then infer "trendy" hashtags that way.
You could query a hashtag using the hashtags endpoint, search through all the hashtags used on the last 100 or so media captions, and then infer "trendy" hashtags that way.
One thing that I do in my app (https://app.promoplanner.net) is I look at the frequency of posts for a given hashtag (i.e. what's the average time between each post for a given hashtag). Small time deltas tell me that a hashtag is popular.
Either way, you need to start your query with either a user or a hashtag, you can't as a broad question like what's trending. You can only ask questions like "what's trending relative to #kesha" or "what's trending relative to #urbanfarming"
How to filter activities in e.g. If I want to filter activity based on some content, it should list all the activities which had that content. Is there any such functionality provided by getstream?
Could you please suggest ?
I'm looking for the same thing. If we assume GetStream is like Facebook, Facebook doesn't really let you search their feed, and in general I think it's a tricky thing to do. What Facebook DOES do is have that SLOW search up at the top (you can tell it takes a long time and half the time doesn't even really have good results). If we accepted that our search would be slow we can paginate through a list of all the objects in our feed from GetStream then search through them on our site. Not a good solution but haven't really seen any other ones.
The original plan was to write this as a blog post, entitled "Inefficiencies in the Spotify Metadata API : Or, How the Jackson 5 killed my Browser", but changed my mind at the last minute as I have a habit of missing the obvious in documentation,perhaps an undocumented feature might exist which I have missed, or someone else has solved the issue - so hence this question has a certain blog-post tone about it!
I am developing a small web-app, mostly for a small group of people, which will allow anyone to update a Spotify playlist. As not everyone has Spotify (though I don't know why!), the page will update a database with songs, as App running in Spotify on my laptop polls the database for updates, then using the Spotify Apps API, the playlist is updated, and anyone subscribing to the playlist gets the update. This is ok, though I would like to use push rather than poll, but that's a topic for another day.
I searched around for a Javascript library to use with the Spotify Metadata API, and found one (https://github.com/palmerj3/SpotifyJS) though it was basically a wrapper and still required you to parse the JSON yourself. Thinking I could go one better and put some basic parsing in for the most common fields (title, artist, album, Spotify URI) I started working on my own library/JQuery plugin.
Search by track is not a problem, it's a single call to the spotify metadata API, the results are easily parsed, matching the returned artist with the requested artist (if present) makes for an easy search by title/artist.
Search by Artist (obtain a list of all songs by a particular artist) though, appears to be a pain-in-the-**! As best as I can tell from the docs, this is the process.
Search for the artist: this will return a list of artists which match the query
For each artist, lookup their albums: this will return a list albums
Lookup each album and retrieve a track list
Compare the artist for each track with the search artist, if it matches output
The first step will return a small list of artist matches, Foo Fighters has 2, Silverchair 1, and The Jackson 5 has 4. This small list turns into a larger number of album matches - from memory Foo Fighters returned 112, which then turns into even larger number of track lists. From a Javascript/JQuery perspective, this leads to daisy-chained AJAX request, for each step, and at each step massive numbers of, nearly concurrent GET requests against the Spotify servers.
The initial version I wrote cheated and used synchronous AJAX, and worked ok, as each request must complete before the next would start, though, this would lock the browser up for some time, and removed the possibility of using feedback to the user that the system was running. I then switched to asynchronous requests and all hell broke loose! You immediately hit issues with rate limiting on the Spotify end, which returns resoponses with 502 bad gateway (not listed in the spotify docs as a status by the way), or 503 - both of which JQuery interpreted as status code 0 - which was interesting, requiring debugging in Firebug. I throttled the requests down on the client side, I found that 1 every second was about right, to avoid rate limiting and ensure I got a response containing data each time, however, this then causes massive lock ups in the browser as it had upwards of 30 or 40 GET requests in parallel, all returning pretty much at the same time (though some requests responded after 15+ seconds!) and then parsing all the JSON responses.
I looked into alleviating the load by using a server-side approach, though this has downsides as well:
1. you don't avoid the basic issue in that the API can not handle the task in an efficient manner
2. for a busy site, the bandwidth usage will be against the server, which will also present a single IP, for multiple users you will soon hit the rate limit due to parallel users
The server side does offer caching though which could be beneficial, to this end I found a PHP Library - metatune (https://github.com/mikaelbr/metatune) advertised as the "The ultimate PHP Wrapper for the Spotify Metadata API", but unfortunately only offers the same basic lookup/search as the Spotify Metadata API - i.e.: no listing of all songs by an artist.
Thus, I have now disabled searching by artist, until I find a suitable solution.
Assuming I have not missed anything, it seems, to me at least, to not be an efficient API design, as it encourages you to make large numbers of requests to the Spotify servers, which is not good for me as a client, and not good for Spotify as a server. I can't help but think that if there was a request such as:
ws.spotify.com/search/1/artist.json?q=foo+fighters&extras=tracks
then the issues discussed here would be alleviated, a single request would cover what requires 3 sets of multiple requests currently; rate limiting wouldn't be as big an issue; the overheads to process the data on the client are greatly reduced; the overheads for Spotify to handle would be reduced and the entire service would be more efficient. The fact that the request would return a very large data set is not an issue, as the API already splits data into "pages".
So, my questions to the crowd:
1. Have I missed something obvious in the documentation, or is there a secret request?
2. In the absence of an API request, does anyone have a suggestion on how to make my system more efficient?
3. Has anyone solved this issue before?
Thanks for reading! Took a long time to get to the questions, but I felt it necessary to provide as much reasoning to find the best solution, and also, it illustrates the deficiency in the API, which I hope someone from Spotify will notice!
Finally as an aside, projects like this make me feel like we've swapped Flash for Javascript but the performance is still as bad! Anyone else feel the same?
Cheers!
sockThief
Unless I'm missing something, does this do what you want?
http://ws.spotify.com/search/1/track.json?q=artist:foo+fighters
The artist: prefix tells the search service to only match on artist. You can read more about the advanced search syntax (which also works in the client) here.
This article explains very clearly how to implement a voting system with MongoDB, and to limit one vote per user and per object.
I have one extra requirement. I need the votes of a given user to be visible for the objects displayed. For example, if I am displaying 20 tweets, and the user has voted on 3 of those tweets, I want those votes to be visible. (For example, using a green up-arrow.)
One solution is to send to the client, for each question, the set of voters. Another solution is to send to the client the set of votes he has cast. I do not see either solution as a scalable one. Any suggestions?
This is something you would do client side.
Once you have the object that contains the vote cound and the array of voters you can check to see if the current user's id is within the array of voters while you iterate over the set of (stories, tweets, what have you)
Does that make sense?
Not a full answer, but a link to a good voting library (fast!!!) for ruby/mongoid. Should be easily portable to node.js, perhaps mongoose.
https://github.com/vinova/voteable_mongo
I need something similar eventually, perhaps we should chat (I am martin_sunset on node.js on freenode)