I'm fairly new to programming and I'm studying App development with Ionic and using Laravel as a backend. So far I have created a simple system with sign up and login of users and creation of "events" by the users. I have made the relation between the users and events as the app will need to know which user created an event, and the participants of such event.
Now, I was wondering about adding a messaging system between users and obviously push notifications and stuff and came across Firebase. I've read about it before, but haven't really used it so I'm not quite familiar with it.
My question is, is it possible or even recommended that I use both MySQL and Firebase in my app or should I just stick to one? I've read about Websockets if I stick with Laravel, but on the other hand, Firebase also handles user login and registration in case I want to move to Firebase completely. I'm having some technical questions, such as:
if I'm using both MySQL and Firebase in my app, how would I connect the user that was registered with an ID and a username stored in my MySQL to Firebase, which will need to know which user has sent a message to another one? Can that be done, or recommended?
Should I just stick with just one for my use case (MySQL or Firebase, instead of both)?
I have researched about use cases similar to mine and couldn't find anything, if you guys have come across such situation, could you recommend any materials? It would be much appreciated!
Thanks a lot everyone! I hope my questions were clear, if you need more details, please let me know!
If you decide to use Firebase, it comes with a built-in authentication system so you wouldn't need a MySQL database or your own server.
If you decide to use both anyways (if you have a good reason to do so), you would have to handle all the logic for copying the authenticated user id over to firebase (and validating access) on your own server. If you don't need to do that just keep it simple: Firebase or your own server + MySQL.
Related
I am working on a social network app from scratch,
I designed my database (choosing Mysql) to store and retrieve data
The problem starts when I am posting videos and photos and when data become larger and larger when I am waiting to view news feeds (depending on sql query that brings the last posts from friends ans Pages).
The question is :
How can I manage and handle the big data, and how can I make the news feeds service more efficient ?
What do you think of using (Real-time) Databases from Firebase?
If you're thinking about putting up Firebase as your choice for your database, then there's nothing wrong with that. Firebase realtime database is a very secure and great option.
Firebase gives you functionality like analytics, databases, messaging and crash reporting so you can move quickly and focus on your users.
Firebase is built on Google infrastructure and scales automatically, for even the largest apps.
And on top of that, many great apps do use Firebase as their backend.
I'd say to know more, you can just start with a demo project on Firebase to learn how the things happen with Firebase, and after learning, start using it as backend for your social app.
Just go to Firebase Console and start with your own project. To learn how to use Firebase, do refer Firebase docs and if stuck, StackOverflow is always there.
If you want to get some inner details, I have some repositories on GitHub, that might help you in understanding about Firebase and the security rules and other important things.
Demo App
Firebase Security Rules
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'm new to webdev and I'm trying to use passport for registration/authentication on a site I'm setting up. I'm also going to write an application in node later on that will be using some of the user data (users will need to provide an API key for an account on another site that I will use to pull data into the application).
At the moment, the main issue I'm having is figuring out what goes where. I've found plenty of resources that explain how to create an app using passport, but nothing shows how it would be incorporated into your website or where the files should be in relation to your website. I'm relatively new to Node.js, and while I've written a few small applications I have never hosted them anywhere.
Bonus question: I'm using MongoDB with passport and I was also planning to use it to store some JSON my application will be receiving from API calls. However, I wanted to use MySQL to store some data as well. More specifically, I'm planning to save the raw JSON then I'll create a relational database out of the data I need from the JSON and then keep the rest in MongoDB for easy access. Is this common/smart, or should I focus on keeping everything in my MongoDB? I'm relatively new to NoSQL.
Thanks in advance for any help.
I would reference this tutorial. I just recently used this to help myself with a new application. Also there is an example of the same thing but in SQL here. So not sure what you mean by " where the files should be in relation to your website". The information related to to authentication should go in your database.
To your "bonus question" you can use two databases. The key here is to ask yourself why and what are the true needs for data, and how is this data accessed and used. From ground up I would like one and stick with it. If at some point later you realize a certain type of data would be better in a different database then you can add it.
Side note: look into an IDE such as webstorm to help you out.
At the moment I am working on a CRUD app that I am going to deploy (someday) and use for my own startup company. However I am nowhere near finishing this product and I stumbled upon a question that I can't seem to figure out.
I am using Express to serve angular the data out of my MySQL database. To do this I had to create '/api/' routes. However if I go (for example) to '/api/clients' I will be able to see the entire list of clients in an ugly array. In this case that does not really matter since it's just the data they were able to see anyways.
However my question is, is it important to block these kind of routes from users? Will problems arise when a user goes to 'api/createClient'? Could this result in a DB injection that could ruin my db?
My project can be found here: https://github.com/mickvanhulst/BeheerdersOmgevingSA
The server-side routing code can be found: server > Dao > clientDao.js
Controllers, HTML & client-side routing can be found in the 'public' folder.
I hope my question is clear enough and someone will be able to answer my question. If not, please state why the question is not clear and I will try to clarify.
Thanks!
Looking at the code, it looks like your URLs can directly be accessed using browser and if yes, then this does pose a security concern.
Doing DB transaction with the user provided fields or values is major security concern, if these data are not validated and sanitised before making a database call.
I would recommend following minimum steps to follow before crafting APIs which is internal but can be accessed using browser -
If this is internal, then do not provide HEADER ACCESS CONTROL from the server or keep it confined only to your domain name. This prevents any ajax call to be made to your APIs from another domains.
Do sanitise and validate all the data thoroughly before doing any kind of database transactions. There are lots of material on this everywhere on how to do it.
If these APIs are meant to be used for internal purpose, then kindly provide some kind of authentication to your APIs before doing the logical work in your routes with the help of middle-wares. You can leverage cookie authentication for very simple API authentication management. You can also use JSON Web Tokens, if you want a more levels of security.
If you are manipulating your databases then I would highly recommend to use some kind of authentication in your APIs. Ofcourse, point number 2 is must.
I'm working on a bunch of cakephp apps that are all services that you have access to when you login to the main website. Each app will be hosted on a separate server, and there will be a separate login server as well.
Doing the research, I found Cakephp supports writing sessions to a database, http://blog.jambura.com/2011/08/24/should-i-use-database-for-storing-sessions-in-cakephp/
And also it supports having multiple database connections,
http://bakery.cakephp.org/articles/mithesh/2008/09/02/talking-to-multiple-databases-from-single-cakephp-application
So I was considering the possibility of storing the sessions on the login server, which the other websites all access, and then they all use their own databases for the rest of their data. It seems like it would be simple to implement, but I have concern that there would be too much reading and writing on the login server's database. Is there a way to optimize for this? Or should I do another approach entirely?
Try check useDbConfig property of model. Think, that it will be simpler if your sessions and users tables will be on the same database, then you will common user database and sessions. So, you will not require to implement SSO.