I'm creating an app for Q&A that unifies twitter mentions/DMs, facebook wall posts/messages, as well as email and sms into one inbox. I know how I'm going to handle the SMS (storing each incoming message and outgoing response), but I'm wondering if it's realistic to apply the same methodology to twitter/facebook messages.
I figure I need to store them so I can at least mark them read/unread. Is this how TweetDeck does it? I can't imagine them polling the API constantly without caching anything.
By the way if you know of an app that does this already that would be fantastic. Hootsuite does everything but SMS and email oddly.
Assuming you're building a mobile app (since you mention SMS), if you're aiming to support arbitrary Facebook & Twitter accounts (ie including very busy ones) & use over a long period of time, then you can't store all the tweets & posts on the mobile device: this storage required would grow over time to exceed the capacity of any device.
You can store a reasonable number of "recent" tweets/posts in full; these form the backing model for your UI's views. When the user navigates past either end you can retrieve more via the APIs, and you'll perform housekeeping on this collection so it doesn't get too big, discarding older ones as necessary.
(This collection may end up being gappy: eg if I haven't run the app for a week, when I start it it would retrieve the most recent day's content, leaving a gap between yesterday's content & that of a week ago. Twitter's apps do this & show the gaps, allowing the user to fill them in via the APIs.)
If you need to keep track of read/unread status, you could store this & the unique id for a larger number of items; but again, you'll eventually need to purge these too.
You might want to look at the Twitter User Streams feature; Facebook's Realtime Updates isn't as well-suited for mobile apps (unless backed by your own server).
Related
I am building a mobile app (in flutter firebase, but the answer does not have to be firebase specific). And I would like to implement a feature that notifies users whenever anyone from their contact list joins the app. This seems like a very EXPENSIVE feature.
At the top of my head, I see a lambda/cloud function that is triggered everytime a user joins and then searches a database of users and their respective contacts for the existence of the new user's phone number. To me, this solution does not scale well for two reasons: if the number of total users is in the millions and the number of users joining simultaneously is a lot.
My better solution is to get the user's contacts upon joining and then searching a database of current users contacts for any of the phone numbers of the newly joined user.
Is there a solution better than the second one? If so, what is it? If the second solution is standard, what kind of backend storage mechanism provides the best search and retrieval time for a database of users and their respective contacts?
In the case of large users ill not do first solution because that may slow the sign up process instead i will creat a cron job that runs at a specific time or periodically it will get the list of the latest users signed up that day or that hour whatever you prefer then that cron will check the new user if related to any user in the databases and send a notification right away, or a better solution create a temporary table in a database in another server insert the notification informations into the other server, creat another cron job in the second server it will run at a specific time to sendthe notification
I'm a client side developer with little experience of server side, and I'm struggling to understand how to make a database-backed website without requiring users to login.
The usecase is fairly straightforward. The user lands on a website, uploads an image, and performs some processing to that image. Clicking 'share' POSTs JSON to my endpoint, stores it in a DB, and returns a unique URL in a textbox (eg, https://example.com/art/12345) which allows the user to share their artwork with others, or just to come back and do more editing later on.
What stops somebody from doing, POST <data> https://example.com/art 100 million times and filling my pay-as-you-go database?
I've seen examples of this link based method of sharing between users on plenty of sites but I don't understand how to stop abuse, or whether it is safe to just open up an API which allows writes to a database. I do not want users to have to login.
I believe the simplest method is having a quota, either by username for logged in users or by IP, if you don't require logins or only want to allow free usage to a certain point. Perhaps you could have a smaller quota for non-logged in users than for logged in users and even larger for paying users.
Your server side code that handles the POSTS and storing data into the database would have to take care of that. I'd add it to a user_data table on mine, making an additional column that tracks total space used. makes a todo
Then, when the user adds new data, increase the total space used. When they delete old data (I have versioned web pages so that eventually, the user will be able to rollback to previous versions) then the space used decreases. Having another page to look at to see where they're using space makes deciding what to delete to stay under a quota of X MB's/GB's/TB's/etc easier or maybe just an /api/delete_old_pages or notes or comments or all of the above.
I'm currently developing a facebook App whose purpose is to
For a given page, list the last X posts
For each of said posts, list the last Y comments
For each of said posts, list the last W reactions (e.g. likes)
For the page as a whole, display the Z most active users considering the last X posts
The app is not yet published (And, since it'll only provide server to server communication, it might never be) and it currently has one admin and 4 test users.
I'm currently hitting rate limits for the comments endpoint, whereas I've never got any alert for the reactions endpoint.
The rate limit documentation says that some endpoints do not count for rate limiting, but it doesn't say which ones. So I assume that, in my case, only the comments API calls are eating my rate limit.
One approach I might consider to go over the rate limit is to create test apps for my app. They do have their own app-id and app-secret, and share the same app-scoped User ID namespace, so user IDs will be consistent and I'll be able to use both Apps to display aggregate data.
What I don't know is do test apps have their own rate limit?, or do they "eat" part of the production app rate limit?
I want to avoid creating the logic to rotate the App credentials on each call only to discover the rate is still the same.
Edit: I created a test app and hardcoded some calls to use its credentials. However, said calls aren't shown in test app's dashboard. I believe this would mean that its calls are attributed to the main app anyway.
I need your expert advice on this one.
I have been asked to analyse a potential Facebook application.
This application is a parental monitoring for kids accounts. Basically it will search a kid status message for specific keywords amongst others things. And this application will alert the parents when it finds something.
Of course this application will have a valid token to access the kid's data. This is not a tool to spy on the kid.
I am using the Graph API coupled with the 'since' keyword to get the last updates. It's working fine with a single user.
My question is about scalability.
How should I get updates of a huge number of kids to monitor? (between 10,000 and 100,000 accounts)
And for each kids I have to monitor status messages, videos, images, friend, friends' status messages...
Here are some numbers:
~2.1M requests each day to get hourly updates of 10,000 kids' account.
~57.8M requests each day to get hourly updates of 10,000 kids'account plus their friends', with an average of 40 friends each.
And as I read here, it would be limited.
So what do you reckon?
ps: Maybe with real-time updates I won't have this problem or would it be worse?
Yes I would subscribe to real-time updates so as an account gets updated you get a callback and then you get the latest updates. This would avoid the overhead of constantly polling accounts for updates. You will need to get an offline_access token for this to work as well.
I am building app that will serve some content to the users via my private server. At the server-side I would like to identify user, so that I don't serve same content twice to the same user. How can I identify user(s)?
One way is DeviceID, but user can have multiple devices...?
Is the only way to have my own user IDs for my application (registration). I don't like this as it adds extra complexity to the app.
I know it's a hard task, but maybe facial recognition (from the webcam) could help in logging in users, since it doesn't imply any relation between user and device.
For example, face.com offers a free web-based API for facial recognition.
Although, Ishu's answer (username/password) is the easiest and most standard way to do identify users.
Make an id for user's and also a login page in the app. save his id with in you content table for send that content for that user. if that content entry already having his id then don't send to him otherwise send to him.
I don't think there is another option. You must use user id nothing else.