Since Parse is shutting down, we are currently using Firebase to support basic data storage and real-time messaging. However, in order to implement a key feature in our app, we need to run some code on a server. The following is what we are trying to accomplish:
We allow users to upload key words to Firebase, then we want to send notifications to them if any new posts that contain these key words were uploaded by other users. For example, userA wants to know if anyone posted information related to chemistry, so userA enters key words "chemistry" and "science" in our app which get stored in Firebase, userB posted an article called "chemistry rocks!" which contains the key word "chemistry", userA will then receive a notification immediately about this post.
We have a couple of solutions in mind, but we are not sure which way to go and how to properly implement these solutions.
1 - Build a server that listens to Firebase changes and also supports sending notifications to individual users. However, to host and maintain a server just to run a search algorithm is just too much work for this simple task.
2 - Store the key words in another database that somehow can send notifications according to the search result. This would be faster because we wouldn't have to connect Firebase server to our own server, but again we would still have to host and maintain a separate server.
I have looked into Google App Engine, their push/pull queue feature sounds like something we want, but does GAE support notifications? And also how can we hook it up with Firebase? We also came across Firebase+Batch to send notifications, but I don't think Batch supports cloud computation.
Has anyone run into this problem? Any solutions?
Related
I'm working on a project using React 18 with Firebase Authentication and Realtime Database.
The project is a real-time chat between two users, I wan't this project to be very secure and protect messages/conversations. I have the following "cases" or "rules" to specify this chat functions:
User with profile Volunteer can chat with maximum 10 users with the simple-user profile.
Volunteer can see previous messages or the "history" with a registered simple-user but simple-user can't see previous messages. I need to protect chats for simple-user.
All the active "chats" between one volunteer and maximum 10 simple-users have to be seen just for the Volunteer profile. The simple-user just send and receive messages with a random Volunteer.
I search on the Internet which database fit better with my project model and Realtime Database looks like the better option. But now I would like to have your opinions about how can I handle the database to get the data and connection that I need according to the previous rules I wrote.
I know Firebase is a No-SQL database, but I create this diagram to know if the data structure for this chat could work.
If I store different information like the image above, could I get the information I need from each chat?
Turn is the working shift time that "volunteer" is working on the chat platform.
Session is the information of the turn of that volunteer and simple-users that they talk.
Chat is the "conversation" or the instance to generate messages between two different users.
My questions are:
Do I need a backend project such as nodejs? This backend would be for store the endpoints to firestore and apply some logic rules for queries this way I can have a React project without logic
If I structure my database like the image above, can I be able to get the information to achieve the "rules" that I need?
Do you have any suggestion to build a chat like this? In the future this project could be huge with a lot of data store and multiple users chatting with each other. Right now I have just the UI code and firebase connection. No other code yet.
Thanks for your contributions!
I'm building a SPA site in React (using redux).
To my site, any user can connect through Google or Facebook.
Each user who logs in to the site receives a personal user_id.
For each user, the system needs to keep a history of documents created by this same user (like the recent docs in Word).
I need to create functionality that whenever the user is logged in he will be able to see a history of the five documents he has created/updated.
In addition, the latest documents will load even after disconnecting and reconnecting to the system.
To load the history into the system I am thinking of using a dedicated index in ElasticSearch.
My question is which way would be suitable the most to use when the user is already logged in and creates several documents one after the other -
Should I need to save everything within the index in ES or is there a smart way to save and update the information locally without producing a lot of calls to DB?
I want that in the end there will be only 2 DB calls that are made in total - one call to load the information on login and one call to update the information when the user logs out. Any other create and update docs will save locally on the client side until leaving the site.
I'm trying to make a simple React app that uses Cloud Firestore for user auth and storing data; something that I could serve using heroku or something like that.
I'm running into trouble with enabling a user to delete their account (and associated data), as Firestore tells me that it's a bad idea to delete collections from the client side. Here's what they say:
Deleting a collection requires coordinating an unbounded number of individual delete requests. If you need to delete entire collections, do so only from a trusted server environment. While it is possible to delete a collection from a mobile/web client, doing so has negative security and performance implications.https://firebase.google.com/docs/firestore/manage-data/delete-data
While I might be able to delete the document connected with the user's account, this suggests that I can't really delete the sub-collections under that document.
So what would be a good way of automatically removing both the user document and user sub-collections? Can I achieve this through my react code? If not, is there a relatively easy way to do it without building a fancy back end?
Well, the documentation never says that this is not possible, just not recommended.
This makes sense if you consider that if you want to delete everything, including documents from subcollection, you would have to create a logic that will do this one by one, which is a very read intensive process and all of this data processing happening in your webapp is not a good practice, it might slow your app down or even block functionality while this process is occuring, etc.
What I would recommend for you is to follow the recommendations of Firestore itself, which is to create a Callable Function that will perform this actions for you, all processing will be done by that function and this will not degrade your app performance, you can find more details in this documentation.
I'm creating my first application that requires me to update the app based on user input. I've been searching for the best way to send input to me. For example, I have a button that when the user presses I would like to send me the information they've added to a text field. Being new to this, I thought this could be done by simply sending the information to a specified email, but from what I've researched I will need some sort of database. Looking through the Apple Developer Documentation I don't even know which topic I should be looking at to figure this out, any help or direction would be very helpful!
You need to setup a server (using an API) to receive the information.
Usually you will use a webservice to receive the info from the app, although there are other ways to do that.
Sending an email through iOs would require the user to accept the email that is being sent, so doesn't look like a good idea.
Take a look at some options available to create webservices (django rest framework or flask), Google's Firebase also can be handy in this situation, since is only integrating it with your app and storing the data you want to store, with easy integration for Authentication and user tracking.
I am working on a WP7 application. This WP7 application will interact with some web services that I have created. I do not want other applications interacting with these web services. The reason why is because I do not want them stealing my data. With that in mind, here is what I'm currently doing:
Connecting to web services via HTTPS
Making my users initially login to the application
Passing the users username / password with each web service interaction
At this time, I don't see what is stopping a malicious developer from creating a username / password combo and using that account in their application to interact with my web services. How do I really lock this thing down?
Thanks!
As a start towards a more secure system you should stop storing the password and sending it over the wire with each request (even if you're using SSL).
If you must pass it with each request, store a salted hash of the password and use that instead.
I'm using a multi layered approach to this problem. I recommend thinking creatively and using a variety of methods to validate that requests are coming from devices you expect requests to come from.
Alternatively, if there is any merit in your scenario, open up your api to 3rd party developers and make this work toward your objectives.
If you do decide to store a key in your app, don't store RAW text but instead declare a byte array of the UTF8 values, this won't be as easy to read.
You can then handshake with your service using a salted hash of the key the first time the app is run, the service hands out another key for the device to actually use day-to-day.
The phone should have an almost accurate time, so you can recalculate the key each day or hour. You can also revoke the key at the server end for just that device.
This API will be useful in ensuring you can blacklist a device permanently.
DeviceExtendedProperties.GetValue(“DeviceUniqueId”).ToByte();
I've not looked into symmetric encryption by you might even be able to use the above unique ID as a private key.
I think the key to success is that first hand-shake, and ensuring that is not snooped. If it's a really important system, then don't use any of these ideas since rolling your own encryption is always flimsy to anyone with serious intent - use well-known methods and read up.
Luke
You could introduce an "Authorized Application ID" feature where the application sends its name or identifier within each HTTP request body. Then on the server side you can verify the application's identity (e.g. store the authorized app ID's in a table). The application ID would be encrypted within the HTTP(S) body.
This would also give you the option of pushing out new application ID's in updated versions of the WP7 application if you wanted to get rid of an older application ID. You'd also be able support new applications on difference devices or platforms in the future.
You may want to look at this
http://channel9.msdn.com/Blogs/Jafa/Windows-Phone-7-Trade-Me-Developer-Starter-Kit