I've developed a React Application that has form where users can update their Birthdate along with their ID. All my team members would be able to access the Application through http://<IP Address>/3000 When each person updates the form the data should to stored in my Local machine.
How can i achieve this?
You cannot handle this in the client side, because you do not have a mutual state that is shared amongst you and your friends.
One possible solution, given your requirements, is to use a global data structure that you can put somewhere in the backend of your react app. This is so that your friend would be able to access the same data as you. There are a number of ways you can do this, depending on how you set up your react application. What I would do is set up 2 RESTful endpoints in your react project's backend. So, something like:
GET /data
POST /data
In the handler of both endpoints you'd be able to access the data that you declared. Now, each time you want to update your shared data, just make a network request to the above endpoints.
Related
I am creating a simple chat app using react and node js. When using socket to establish a connection between server and client, I was wondering the point of using this package. Since react re-renders the page upon state change, I can fetch messages from my database and change the state, allowing for a presumably seamless chat application. Will there be any problems with such a chat application, where the chats would be displayed by fetching data from the database? Adding a new message would again update the database and the data would be fetched. So, the page would update with the new chat being displayed as it has been re-rendered due to change of state. So what is the need for socket in such an application ?
You could build what you describe without socket.io. Socket.io simply allows the messages to be delivered in real-time using websockets and a few other technologies so you don't have to build long-polling.
Said in a different way, when you fetch data from the database, you'll have react perform an API call and fetch new messages from a node.js API endpoint. This API call will need to be performed on a very short interval to make it feel like messages are showing up in real time.
This is one of many situations in programming where you could totally write something yourself, but there are industrial grade solutions that will help speed up your development.
I would like to store the payload of REST API calls made by a user in frontend and be able to make the calls to recreate what the user did (like a replay button)
I have the following scenario:
User opens website.
User picks a product and configures it.
How can I store the REST API calls payload from frontend: Is there a framework that does that? Which database should I use?
You can implements it by state management.
I think the user data shoud be stored firstly in some state in front-end by using a Redux library for example.
Finally you can send the data for a data base (MongoDb for example) to persist the data stored in Redux state.
So, in terms of Data base use, that depends on if you need that data, even when the user close the browser.
I have an express server setup that is handling all of my routing and session stuff. I want the system to work so that when a user is logged in they are able to connect to a "hub" like entity that is uniquely based on the location of the "hub". I thought about working it like each of the "hubs" is a collection in a database, but the way it works is that a user connects to the "hub" and then disconnects from it when they are done but can connect to different "hubs" based on a location. How should I go about creating a unique group of "hub" like things that all act as objects with storable data?
Instead of connecting to a "hub", why not just present them with different information from a database based on their location. The user will never really connect to anything other than your single backend. Unless, ofcourse, you set up different servers all over the world (known as a CDN, and probably a bit too much effort).
If you're using express, you could use something like mongodb for data storage.
With mongodb you get the mongoose npm package. With that, you can create Schemas. You could have different Schemas as "hubs" and load the correct ones based on location data. That would let the user see different information for different locations.
Im coding a static page app using Angular, which shows various Instagram and Twitter posts of the company, and shows the details of the members. I have few questions regarding this, and would like any help.
Firstly, I have about 100+ contacts to display on the first page. Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ? I do not have any backend as of now.
Other thing, I was able to retrieve Instagram Json with media content using their API, the doubt im facing is, once I have the call done, will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with? Any help is appreciated. Thanks.
For your case, as you have fewer data using Firebase is the best approach. If you write a backend and maintaining it would cost you more. You can use Firebase service URL to retire those records. In future, if you want to add more data it would be easy.My suggestion is Firebase.
Should I create a Json by myself and retrieve it from the service, or should I create a backend and save it there ?
Are you revealing credentials or other sensitive information in the client? That would be one reason to have a backend apart from Instagram or Twitter. Do you envision exhausting API rate limits of Instagram or Twitter APIs? That would be another reason; you could cache results in your backend to reduce external API traffic. Do you need to process (reduce? translate?) the data before it gets to the client, or are you satisfied with performing any processing on the client (e.g. is it fast enough)?
TL;DR: It depends a lot on your particular requirements.
If you do want a backend, the recommendation in the answer from #praneeth-reddy to use Firebase is excellent. If you only need processing/transformation but no caching or separate storage, then AWS Lambda may also be worth considering. If you need more control (build vs. buy), you could write your own backend.
...will the Json change automatically when the user adds/edits their posts? Or will the Json be the same as I first called it with?
Angular can help you update content automatically if the client side data (think browser JavaScript memory) changes via its automatic change detection functionality, but you would have to provide your own logic (e.g. in Angular services perhaps leveraging RxJS) to update the client side data based on data from the APIs. You could poll to update periodically, or for better performance listen for changes using an asynchronous event/push mechanism such as websockets or streams.
I currently have a React-Redux Application.
I want to create an admin user in React-Redux.
If I create a state with userAdmin true or false will users be able to access the state and change this value? That is to say, is this a secure method of creating such access?
I am using webpack to create a bundle.js, and have a node.js server for serving data that is secured using JWTs.
Furthermore, is there a standard or semi-standard pattern for creating an admin user in a react-redux application?
My thoughts on this are:
Create a separate app for admin user management.
Create a state for the admin user and if that state is true then query the serverAPI for any admin action. But show the admin capability only if that state is true eg. delete other users, view details of users, but do not serve that data without an authorised API call. Then if the state is changed surreptitiously the user can only see the actions but is not able to access the API without the required authorisation.
tldr: your thoughts are correct
You are right in the assumption that the user could manipulate the state of the client side app to escalate her privileges. However, that shouldn't give any useful benefits if your architecture is done right.
Data that only admins should have access to shouldn't be transmitted to a regular user in the first place and changes that only admins should be able to do should only be accepted with JWTs that identify admin users.
Right management is something that has to happen server side. The client app just reflects that in the UI.