I am trying to build an API first web app that has two parts:
Part A: The Project Management App. This would be built using php/mysql. One of the table in the mysql DB will be the users table where all users information will be stored viz username, password, email etc.
Part B: The online chat App. The users of the project management system will be able to chat among themselves. This will be built using nodejs/mongo. The mongodb DB would store the chat transcripts of each users and so would have a users collection containing the user details. The users collection would contain the same user information that the mysql users table has viz username, password, email etc.
Now, i have a couple of questions in terms of the architecture of this app.
Question 1: Is it at all a wise idea to maintain two different sources to store the user's information? The reason why I wanted to have a replica of the users table in the MongoDB as well is because since there will be too many reads and writes happening in the chat app so its best we use a nosql DB. (Lets assume here that my app will be used heavily going forward)
Question 2: If the answer to Question 1 is "Yes", how do we make sure of data consistency? I have thought of two approaches to achieve this:
Option A: Since we are using the API first approach, so during the registration of a user when the CREATE user api call is made, it will add the user in both mysql and mongodb databases.
Option B: I setup a cron that will sync the data between the mysql users table and the mongodb users collection periodically.
Can someone please throw some light on this and tell me if my approaches are right and that if I am going towards the right direction.
Many thanks
Related
I have 2 systems let's call them i and j. Each have it's own database.
Each have a registration page, where a user is inserted in a user table.
What is the best way to synchronize both tables, where if any user registers at system i it will be also registered at system j.
Notes:
I cannot read from each other databases directly.
I can do small changes in the code if needed and it will not affect the system performance or natural behavior.
I can create API's for both systems if needed.
I can add any tables or fields if needed.
I can create any cron jobs unless it will affect the performance of the system or server.
I'm using cPanel.
Technologies:
MySQL
PHP
REST API's
The fact that you list cpanel as a technology shows you're working with an inflexible budget hosting vendor. So it's unlikely they'll cooperate in setting up background tasks (cron jobs) to merge your user tables behind the scenes. (cpanel isn't a technology: it's a system administration user interface provided by hosting vendors who don't trust their customers' skills.)
So. you should design and implement a REST API in the code of both your apps to perform user registration and authentication tasks. You didn't show us the details of your app, so it's hard to design it for you. Still it seems likely you'll have to implement these operations:
PUT user
DELETE user
GET user
POST user to validate a user's password, etc. (Don't use GET to pass secret information: GET request parameters go into server logs.)
PATCH to update details of a user.
If you get the API working, whenever you create/retrieve/update/delete user information in one app, you'll use the API to change it in the other.
Your best bet would be to create a third app just for user management, and have both your existing apps use it. That way you're sure to have one coherent source of truth about users. But you can do it just within two apps.
I am working on a project and one of the key components is creating customized user profiles. I already have a schema design for the user data that will generate said profile. But I am lost on how the technology works.
I am mostly front-end so it has been sort of overwhelming. The goal is to allow multiple user profile creations and so far I have only seen that this can be achievable via NodeJs or PHP. I have not found any guides.
I am not sure if I am asking the right questions.
Any help is appreciated. Thank you.
Since you mention you already have schema for the user table, I assume you are going to design your own database and backend node.js API to handle user profiles. You may want to build authentication functionalities in the future. If you are not familiar with Node.js yet, I recommend you to start with https://www.tutorialspoint.com/nodejs/index.htm. It's a good tutorial for beginners.
The whole purpose of a back-end node.js API is building numbers of service with specified route. Once a http request is made to a particular path, it takes parameters and execute some script. In you case the scripts will do something in database containing user profile data, for example, add a row in your data table. This operation is equivalent to creating a new user. Then, the API send response to front-end.
Keep in mind maintaining user profile data is nothing special than regular data. You should be able to pick it up with a couple of days training if you know javascriopt. But if you have to build authentication functionality you need more technologies.
I have been trying to make a website as a side project since its summer and I have done a lot of tutorials and research with Firebase and HTML. Now I am stuck on the design aspect. My website requires making use of authentication with email and passwords.
For storing data about the user, what would be the base way to keep the user's data in Firebase database? Create childs named after the user's email, use the UID of the Firebase user, or are their other ways?
TLDR What is the best/recommended way to store a user data in a way that my website can retrieve what it needs when the user logs back on?
The idiomatic way to store user data is in a structure:
users
<uid1>
...
<uid2>
...
This allows quick and efficient lookup of the signed in user.
But you may need additional data for specific use-cases. For example: if you want to ensure that each user has a username that is unique across all users, you'll typically need to add a structure that maps from username to UID:
usernames
<username1>: UID
<username2>: UID
For more on this see one of the many examples: https://www.google.com/search?q=site:stackoverflow.com+firebase+unique+user+name
And for other use-cases you may need yet another structure.
To learn more about NoSQL data modeling in general, I recommend reading NoSQL data modeling. And for Firebase specifically I recommend watching Firebase for SQL developers.
I have an application which is currently tied to the desktop application which will specific to each of my users.
The Existing application has about 300 table
The current database design is specific to a single user. For example , for a given clinic as user , we have following tables
• Patient
• Patient_address
• Patient_Images
• Employees
• Clinic_details
• Devices
What I want is to host this database on web. I want to use this database for multiple users and need to be able to store and retrieve data on a user unique key(Let’s say user ID)
The database will be local as well as cloud based i.e. I would like user to continue work even if they do not have internet, and be able to sync it on demand when connection is back, I may also choose to run a nightly sync process on user desktop.
What is the best strategy to do this? Currently I’m using MySQL, would it help if I switch to SQL?
Any help in this is appreciated.
Thanks
Bhim
P.S. - If this is not the right forum, please suggest the right forum for this question.
MySQL is SQL. You cannot switch from MySQL to SQL. It is like saying that you want to switch from Espresso to Coffee.
If you want the ability to work offline and sync when the connection is back, be prepared to be working on that little feature for the next couple of years or so. I would say, do not even try.
For storing all of your "users" in one database, the term you are looking for is multi-tenancy, and it is a big subject, not suitable for a stackoverflow question and answer. So, multi-tenancy is the term you want to google for in order to find information on how to achieve this.
I was looking into how to add a create user account/login to my website, so I could have members join and come back, etc and ended up finding out in order to do that, I'd need to create a new database in my SQL, to store the users credentials, I dont have the option to create any new databases by my webhost. Only the one database is what I can use. Could I just add this to my existing database? Do I really need more than 1 database on SQL for my website? If so, could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website? Im sorry for the few questions, Im really new to all this and so confused and overwhelmed.
You can create multiple tables in same database.just make a table with fields such as user id,password etc. and use it for saving,fetching user details using sql queries.
Could I just add this to my existing database?
Yes, you can tables to the existing database.
Do I really need more than 1 database on SQL for my website?
There are a lot of websites that use just one database. Some websites use connections to multiple databases. What information is stored in which database is frequently the result of factors other than the website. The ability to connect to multiple databases means that a website could use authentication/authorization info from one database, store user profiles and submissions in another, and read information from other sources (for example, historical stock prices, stored in another database.
All of that information could be stored in a single database. Having them as separate databases means that the databases can be managed separately (frequencye of backups, replication to DR site) and makes it easier to share the database across multiple applications. (For example, we would probably want employee payroll and health care information stored in a separate database, with separate access controls.
Could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website?
It may be technically possible to do that, but that's not the way you want to go. That would add another dependency... the website at the web hosting provider would be dependent on having access to another database, which is not being backed up and managed along with your website.