I created a telegram bot with Nodejs and node-telegram-bot-api package and Mongodb for the database. Now, I want to add multiple languages in the bot and I want to keep the user language selected, and back data with his language.
I know I can save user language on a field in Mongodb. but I wanna know if there is any best way to keep that for the best performance. because there are many responses to users, I must check the language users every second with this method.
Related
I wrote a telegram bot using telegram bot python API, I want to implement two button option for user to select but I don't have any database to save the option with chat_id.
For example: A user want to translate a Eng text to another language, And has two languages available: 1.Persian 2.Spanish
user will select a language and then send the text and its choice will be saved for other texts
Can anyone help me to do that? Personally I thought that I can initialize a python dictionary with chat_id and its option but this is not practical.
Recently, I heard something about conversion handler that added in alpha version of telegram bot API, can I use it in this situation?
I’m planning on abuilding a nextjs app and connecting it to a DB. I’d like users to login to their profiles where a summary of their calendly charged sessions through stripe is visible in a table format.
What would be the best way to get this done? I know both stripe and calendly have their own APIs to pull the data in but how can I connect them to save records in DB for a user with a unique email and ID?
Your question is too general. I think this is due to a lack of information about Stripe's features. To narrow down the problem, I'd recommend to start from Usage-based pricing. This will allow you to understand what data structure you will have in Stripe and what part of it you want to store in your database. So, in general you should pass session time from Calendly to Stripe. I don't know how it is in Calendly, but for Stripe, an email is not a unique identifier. Thus, ensuring uniqueness is up to you.
I am building a job portal for the web using React, Redux and Firebase/Firestore. I've completed all the features I needed except one.
I want unregistered-users/job-seekers to be able to:
Bookmark job posts.
Keep the record of applied jobs.
Keep the record of search queries.
I am thinking about using IndexedDB for this feature. Particularly Dexie.js to make things easier. However, this data will be persisted in user's browser and user will have no access to it in another browser or device. Therefore, I want to give users an option to be able to save all the data to Firestore if user sign into the website and I need this to be automatic. So, as soon as user signs in, I will save it to the database.
I thought about using Anonymous Authentication instead of IndexedDB/Firestore, so all the data will be saved into the database and as soon as user signs in using credentials, the user can claim the ownership of the data. However, this is an extra step to use these features I listed above and not everyone is happy with authenticating an app even though nothing is required from the user. Besides, there will be so many ghost accounts.
So, as I mentioned in the title; I want to save everything to IndexedDB (I will take care of this), but how am I going to synchronize all the data in IndexedDB to Firestore as soon as user signs in?
I imagined the basic process will be like this:
User clicks "Bookmark Job Post"
App checks if users is authenticated or not.
If authenticated, save the bookmark to the Firestore.
If not authenticated, save the bookmark to the IndexedDB.
If User decided to sign in or sign up, check IndexedDB and synchronize it with Firestore and clear IndexedDB.
How can I achieve the 5th step technically? Is there any built in system in Firebase? Also, please feel free to share your idea if you can think of another way implementing this feature. Should I be using firebase.auth().onAuthStateChanged() for the 5th step?
And lastly, how should I structure the Firestore to save bookmarked jobs, applied jobs and search history?
Should I create a bookmarkedJobs collection and have documents of jobPosts duplicated for each user, who bookmarked the job post? And every time a job post is updated by an employer, I will have a cloud function going through bookmarkedJobs collection, updating every instance of it?
Thank you
This may be of interest to you
https://dexie.org/docs/Syncable/Dexie.Syncable.js
Been looking into making my website fully static/pwa, and just using indexeddb, and some webservice for data handling/storage ..this seems like a interesting route to explore.
I have just created a bot on telegram. The purpose is to create private conversations with users (each user separately)
With my facebook bot I can go into the Page "Inbox" and watch all conversations. Is there such an option on telegram ? This helps me alot debugging my system.
To "watch all conversations" you can store them to database (e.g. csv file, SQLite, Postgresql, MongoDB, or any other depending on your environment). And later you can query for them when you need.
Another option, you can create separate predefined chat with you and bot, where bot will write some logs. Or if you have time - you can develop advanced mechanism that will show history (from database mentioned above) and will have ability to reply directly to that chat by chat_id.
I used rocket chat for that. I was creating private room for every user and was adding there the user and the bot (I was doing that via my backend). Then I used rocket chat ui to view the conversations. Currently, I see they have built-in integration with telegram bots: https://docs.rocket.chat/guides/administrator-guides/integrations/telegram
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).