I am developing a platform that involves DialogFlow (CHATBOTS) with different types of integrations (Whatsapp, Facebook, twitter, etc.).
That is solved, since it has its own ecosystem.
The problem is that I need to model in firestore to store user interactions with the BOT.
When a user begins an interaction, it remains in the entire conversation through a SESSION attribute.
The data I get is:
userSay,
agentResponse,
agentResponseId,
intentDisplayName,
intent,
createdAt,
session,
platform.
With some variation or extra attribute depending on the platform where it comes from (WhatsApp, Facebook, Telegram, etc)
The storage of these records is merely by way of consultation and reports and metrics, to offer substantial information to whoever uses the platform.
I would love to be able to guide me, thanks.
Here is a guide for getting started with Firestore, in case this would be your first time using it.
For this specific use case, the implementation could be done by using a Cloud Function which would receive and parse the request payload from Dialogflow, and update the Firestore database. Webhooks will fulfill the Dialogflow Intents, which are used by the function. Here is a tutorial using this approach, and here is another one.
Related
Seems like majority of solutions here require the developer to manually save each user's push token in addition to Firebase saving these tokens as well, then iterate through these and send out notifications. This is not really desirable since I would be storing push tokens in two separate places and need to make sure their lifecycle management is synchronized, which is error prone 😢Is there a better way?
Some options I considered:
Give each user a person/unique topic, then map out a geolocation per topic; then filter through these locations, aggregate these topics into batches of 500 and send a push. This is probably the best option so far 🤷♂️ but seems like a silly use of topics API.
Bucket users in cities, with each city corresponding to a topic; then find all cities near a location, and send a push to those topics. This is doable, but lots of complex city mapping code without much flexibility (vs. considering a simple radius).
Manually store push token → user → geolocation; filter out the ones you want, then send a push to the token specifically. This is problematic for many reasons (multiple device management, push token lifecycle management, data duplication, etc.)
Ideally, there is a way to send out a push notification to a list of user IDs, without even touching push tokens, is there a way to do this?
The only way to associate a device token to a user ID is to store that mapping yourself. You should also assume that one user could have multiple devices. FCM doesn't have a concept of a "user". It only knows device tokens. Your app has to bring the concept of a user, then map that to tokens in code.
Note that any messaging solution that requires topics is not "secure". Anyone can effectively receive messages from any topic.
When we are talking about individual private push notifications per user (rather than per device), there are couple of ways to send them via Firebase:
Collect registration tokens, associate them with the user on the trusted server and send notifications to all registered tokens.
Assign a topic per user, e.g. topics/user-id and let the app subscribe to it upon successful login / unsubscribe on logout.
However, Firebase documentation recommends to use approach no. 1, saying "For fast, secure delivery to single devices or small groups of devices, target messages to registration tokens, not topics."
One concern is the latency (referring to "fast") issue. Is it really that significant in practice comparing registration tokens vs topics-based messaging?
More serious concern is security.
What does Firebase documentation mean exactly by "... secure delivery..." as opposed to topics?
In our case one device will likely be used by multiple users logging in and out. That means registration tokens will have to be disassociated from the user in the backend when user logs out. If something goes wrong and registration token is not disassociated, device will continue getting previous person's notifications.
Is this the trade-off I have to accept or am I missing some other option?
There are a few questions in there. Let's see if I can cover them main ones.
If you need to deliver messages to multiple tokens, the two approaches you're considering are:
Subscribe the app installs/tokens to a specific topic, that you then deliver the message to.
Keep your own registry of tokens for the user, and do the fan-out of user-to-tokens in your own code.
The biggest difference is in where the fan-out of a user to their tokens happens. When you use topics it is done by Firebase on Google's servers, while in the second case you do it yourself. There is no guaranteed performance difference between these two, but in the latter case you have more control. So you spend more effort (writing your own code for something Firebase can do for you), and in turn gain more control (which may or may not translate into better performance)..
The second question is around the security of topics. The documentation contains that note because topics often have a much simpler structure than tokens. For example, if you have a topic-per-user, you will often use the UID as the topic ID. And since you may be sharing that UID in other places, it is possible that other users may know a user's UID. And since subscribing to a topic only requires that you know your own token and the topic ID, that means that any user can subscribe to another user's topic.
Is it necessary to create Terms and Conditions in an application developed with firebase (Auth, real database and storage)?
I get Mac and email always. If the user want NickName, Social Networks Accounts, age, sex, and interests.
If its necessary, some example?
If you are developing a product that uses Firebase you should be doing a careful read of the Firebase Terms of Service yourself, or seek legal advice on the matter. StackOverflow probably isn't going to be a good place to get advice of this nature.
It is clear from the Firebase documentation that different Firebase products carry their own policies that you should adhere to. You'll need to review the policies of each product. Firebase Analytics, for example, indicates notifications that must be provided to users in the Google Analytics for Firebase Use Policy.
Your users deserve to know how their data is being handled, stored, used, etc. Let them know!
I am considering firebase for an app - mainly for the real-time but other features like the analytics and authentication (and price) are other bonuses.
I have my own database and I want everything saved in there. Firebase will have a small portion of the dataset I push as it's needed.
So I'm basically thinking that the firebase data will be read only to the users. If a user comments, that will actually go to my server, I'll authenticate, clean, whatever.. and push to the that feed.
Are there problems with this approach? Are there other (better) ways to solve the problem?
This is a completely valid approach. Firebase is designed so you can use specific features that suit your needs.
I'm building an app which uses user contributed content.
The contribution by each user should be available to all others in real time.
I was looking into firebase Realtime database for this.
However, when a user contributes content, there are quite heavy validations and calculations (read server side) to be done on the data before making it available to others.
Is it possible to have a server side validation in firebase ? Or should I look for alternatives ?
Initially, Firebase did not have a feature to implement server-side processing/calculations. All your processing had to be done on the client side.
Now, they've recently introduced a new feature called Cloud Functions For Firebase. Its a really useful new addition where you can write server-side code without the hassles of managing servers or instances. Read up more about it from the above link.
Also, this Youtube playlist by Jen Person is a great start. And, you can find examples similar to your use case here.