I got confused with the right data flow when I have a backend API and a redux state that passing the data to the components.
The question is: What is the right methodology to handle 2 data resources, API and Redux?
should I update the state and then fire a send request to the API with the update?
or, let the redux send that request for me every time the state changes?
or, should I update the API directly and then fire a get request to update the Redux store?
I'm really confused and do not know what is right approach should I take with less error in the future use
Appreciate any help, even sending me an article that talks about this issue and I'm gonna read it
Thank you
should I update the state and then fire a send request to the API with the update?
That's called "optimistic update", the advantage is that your app feels fast and responsive, since the network delay is hidden from the user. The downside is that the request might fail and you have to undo what the user did and inform them that it failed. For simple operations (for example marking a product as a favorite in an ecommerce website) this works great in my opinion.
To explain how it works with the example in mind:
User action triggers update of redux state (product is immediately shown as favourite on the page)
At the same time, an API request is fired to favourite the product on the backend side.
You fetch the product data again from the API and render it
Now either the request has successfully changed the product, so visually nothing changes on the page for the user - to them it looks like the operation happened without network delay - Or the request failed and you show the old state where the product is not a favourite and and error message appears.
or, let the redux send that request for me every time the state changes?
Parts of redux-toolkit embrace this approach if I'm not mistaken. If you decide to go down this road, I'd recommend to not implement it yourself but instead rely on existing libraries/middlewares.
or, should I update the API directly and then fire a get request to update the Redux store?
This is the classic, safe, and simple approach.
My advice is:
If you have lots and lots of CRUD operations against your API, and you want to not write lots of boilerplate code, look into redux-toolkit (specifically https://redux-toolkit.js.org/rtk-query/overview ).
If you care about perceived performance of your app, try optimistic update.
If you want to keep it simple and just get things to work, follow the classic approach.
Related
The problem
I am following a Vue.js 3 tutorial on youtube and I tried to implement the app shown in this video.
Then I started improving it a bit at a time. You can view my project here.
One of the main features I am trying to add is a Hall of Fame component in which you can view the best ten scores of anyone who plays. You can submit your score just after finishing the game. I decided to use Firestore to hold the data.
However, suppose I build the app for production and host it in a server. Then, I can download the whole project on my laptop, change a little bit the logic, and then play it locally on my computer. That way, I can send any type of data to my firestore database (because my credentials are injected in the javascript by Vue). I can then just send the ideal score of 1 ms to hack the game (this is indeed what a friend of mine managed to do).
The question(s)
The question is: how can I prevent this from happening?
Should I make a few changes in the code about the firebase configuration?
Should I use some other way to store the data, and not firestore?
Should I config properly the firestore security rules?
Also, what are the best security practices in JS frameworks like Vue.js (or React, in general) to prevent the insertion of non-wanted data on the client side? How do I manage the connection to a cloud database from such front-end frameworks?
Disclaimer
I learn everything about programming on my own, by watching youtube videos or googling and so on. I am new not only to Vue and Firebase, but to web development in general. Please consider this when answering.
TL;DR;
If the score is calculated on client-side (in browser) you can't secure it.
Anyone can just see the API call being made from the app to the server and replicate that with rest API tool like postman, so you wouldn't even need to download it locally to make changes.
If your game relies on client-side as a source of data, there is no way for the server to ensure that it is un-tampered.
You can try obfuscating the source code and doing client-side data encription, but it's all in javascript so everything is readable.
If you were to implement it in a more secure way, you would have the server trigger an action (as opposed to the script) but then the times would end up being longer because of the data turn-around time. Since the event fired from server to client and back would be reflected, but even then the automated response can be hacked by handling it with a script.
I am new to redux/redux saga and I am trying to develop an app where I have two browsers interacting with each other via redux saga actions. Currently, I am able to dispatch actions within the same browser, but if I want to dispatch an action to the other browser, the app does not appear to be responding to the dispatched actions. I'm pretty much using the tutorial on https://redux-saga.js.org/docs/introduction/BeginnerTutorial.html for my code.
Before I share my code I want to understand if it is possible to dispatch an action using redux to another user on a different browser. If so, can someone please help me understand how to do so?
You could establish a websocket connection to your server and subscribe to actions to dispatch on each browsers redux store (Publish-Subscribe).
Its not an easy task though. You will have to make sure the actions are dispatched in the exact same order in each browser, to make sure to keep the states synchronized.
Downside is, in order to maintain order, you will have to wait for your server to process your actions, and have no immediate visual feedback (or at least delayed by networking). So you will probably end up with two separate stores, or have to handle that delay somehow visually.
(this was originally a post on the flutter-dev reddit that was redirected here)
So I started making this flutter app using firebase as a backend and after looking at all the options for state management I finally realised that the tools provided by firebase already handle pretty much everything I would need state management for.
For example:
I could set the currently logged in user in my state to show the right login or home page and make the user uid available to widgets for their firestore API calls.
OR
I can just listen to FirebaseAuth.instance.onAuthStateChanged to show the right page and just use FirebaseAuth.instance.currentUser() from anywhere to get the logged in user uid and do my firestore calls.
What I mean is, for every thing that would require global state, I can just basically have a firebase stream listener.
Is this right ? Or am I missing something here ?
You're not missing anything. Since most Firebase APIs rely on data from Google's servers, many of them are designed to be used in a reactive way. Making your UI reactively respond to those asynchronous changes is (in my experience) the best way to keep your code simple.
There may be slight behavior between the different types of listeners. But the onAuthStateChanged listener immediately fires with the current state when you attach it, which makes it a good example of a listener that you can use everywhere you need to respond to auth state (instead of also storing that state somewhere in your app).
In that scenario I would say yes, you can read the onAuthStateChanged stream and react to changes. But there are also scenarios where I need a stream for interacting between widgets without a parent/child relationship. For example, in one of my apps I have a company selector, and the rest of the app reflects to the selected company. I created a stream, so that the company selector doesn't need to be a parent of the other widgets, and especially so that I don't need to pass the company parameter to all the widget tree.
I also have one scenario where I need to load extra information about the user that isn't available on the FirebaseUser object. So when the user is logged on I load their information from a "users" collection and then I add that to a custom stream.
So to conclude I would say yes, you should use the default Firebase streams when possible, but that doesn't mean you can or should use that solution for everything.
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.
I really need some expert help here!. Does anybody knows of a way of getting the list of the users currently connected to a BlazeDS server? Is there any built-in mechanism of knowing this? or do I have to implement some kind of server side logic every time a user access my Flex application and store all logged in users details somewhere and retrieve them later?
The nearest thing I can think of, using BlazeDS, is to obtain a list of clients currently subscribed to a destination, but this won't solve the problem IMO.
First of all, you need to define a destination and make sure that all clients will actually subscribe to it (see BlazeDS documentation for this). Then, on the server, you can then get a reference to the message service
MessageService messageService;
messageService = (MessageService) messageBroker.getService("message-service");
and ask for all subscribers with the getSubscribersIds method on the MessageService instance, specifying the name of your destination. This will only returns a number of identifiers, internally generated by BlazeDS (they are also available on the client side of the connection).
To resolve the same problem, I used this approach in combination to a custom server-side logic to store logged-in users (explicitly invoked login/logout methods). Regularly looking at the subscribers can help to clean this store, because in my experience there's no way to be sure that a "logout" method will always successfully called, expecially from Flex client running in the browser, while BlazeDS will automatically take care of cleanup of the subscribers.
I don't like very much this approach, probably someone came up with a better solution..