Suppose, i want to keep some non-serializable data for my applciation, which the user can access and interact with across the application. So for example, a connected device (bluetooth, wlan), a media stream, something of this sort. Im wondering where to put such data, when using the Redux paradigm?
Pseudocode:
A normal lifecycle of a subscription might look like this:
Subscription connection = instance.connect(device, request).listen();
...
connection.send(data);
...
data = connection.read();
...
connection.unsubscribe();
the app store might look like this:
Store:
{
username: '',
friends:[], <--- Pulled from the server with async middleware
connections:[], <--- Connections data here ???
}
But I would go on and say, that such a device subscription or media stream is not serializable and therefore it would be not proper, to hold them in the Redux Appstate.
And i'm aware, that for example for server request, one is encouraged to use middleware. So for friends of the user, one would write asynchronous actions to pull the friends user names from the server at the login of a user. But a device id in the state wont do, since one has to actually interact with the device connection stream in the app.
So would writing a seperate middleware be an acceptable way to hold on to such data? What is the common practice herefore?
Related
In my Flutter/Dart mobile app I make use of Firebase RTDB persistence to enable offline use of the app.
My understanding is that to enable persistence you have to make the call, as per the following piece of code, before using any database references to eg. query the database. I use the following piece of code to enable persistence immediately after loading the app and it works fine:
FirebaseDatabase firebaseDatabase = FirebaseDatabase.instance;
bool _success = await firebaseDatabase.setPersistenceEnabled(true);
print(_success); // Prints true, so persistence is set 'on'.
When I logout of the app I attempt to turn persistence off with:
bool _success = await firebaseDatabase.setPersistenceEnabled(false);
print(_success); // Prints false, so persistence is still 'on', ie. the call failed.
I assume the reason persistence cannot be turned off is because there have been calls to db references prior to trying to switch it off.
This leads to three questions, I guess:
Should I be worried about turning it off at all, when I logout? The reason I attempt it is good house-keeping, mainly. I clean up shared preferences, close keepsyncd's, etc when logout is run. Also, though, the user can have multiple userids to login and I want to make sure that I am not retaining persisted data from their previous login id.
Related to 1, does setting persistence to false clear the cache of
data and potential queued calls to the db?
If the answers to 1 and 2 are 'yes', how can I switch persistence off given the code I'm using to do so keeps telling me it failed?
The typical way to handle this is to enable persistence once a user logs in.
Once disk persistence has been enabled and your app has used the database, it cannot be turned off. The documentation says this about it:
The returned Future will complete with true if the operation was successful or false if the persistence could not be set (because database references have already been created).
That last bit is clearly the case for you: you've been using the database already, which means that disk persistence is on.
To your specific questions:
Unfortunately the data in the local cache cannot be cleared up through the API at the moment. It is a valid feature request, but for now you'll have to assume that any data on the device can be seen by any user on that device (or device profile).
Disabling disk persistence keep the client from adding data to the cache. It does not clear any existing data in the cache.
I've been looking for a good way to do, but haven't found anything that doesn't seem hacky. I want to signal the client without going through the database and a subscription. For example, in a game I want to send a message to the client to display "Player 1 almost scores!". I don't care about this information in the long run, so I don't want to push it to the DB. I guess I could just set up another socket.io, but I'd rather not have to manage a second connection if there is a good way to go it within meteor. Thanks! (BTW, have looked at Meteor Streams, but it appears to have gone inactive)
You know that Meteor provides real-time communication from the server to clients through Publish and Subscribe mechanism, which is typically used to send your MongoDB data and later modifications.
You would like a similar push system but without having to record some data into your MongoDB.
It is totally possible re-using the Meteor Pub/Sub system but without the database part: while with Meteor.publish you typically return a Collection Cursor, hence data from your DB, you can also use its low-level API to send arbitrary real-time information:
Alternatively, a publish function can directly control its published record set by calling the functions added (to add a new document to the published record set), changed (to change or clear some fields on a document already in the published record set), and removed (to remove documents from the published record set). […]
Simply do not return anything, use the above mentioned methods and do not forget calling this.ready() by the end of your publish function.
See also the Guide about Custom publications
// SERVER
const customCollectionName = 'collection-name';
let sender; // <== we will keep a reference to the publisher
Meteor.publish('custom-publication', function() {
sender = this;
this.ready();
this.onStop(() => {
// Called when a Client stops its Subscription
});
});
// Later on…
// ==> Send a "new document" as a new signal message
sender.added(customCollectionName, 'someId', {
// "new document"
field: 'values2'
});
// CLIENT
const signalsCollectionName = 'collection-name'; // Must match what is used in Server
const Signals = new Mongo.Collection(signalsCollectionName);
Meteor.subscribe('custom-publication'); // As usual, must match what is used in Server
// Then use the Collection low-level API
// to listen to changes and act accordingly
// https://docs.meteor.com/api/collections.html#Mongo-Cursor-observe
const allSignalsCursor = Signals.find();
allSignalsCursor.observe({
added: (newDocument) => {
// Do your stuff with the received document.
}
});
Then how and when you use sender.added() is totally up to you.
Note: keep in mind that it will send data individually to a Client (each Client has their own Server session)
If you want to broadcast messages to several Clients simultaneously, then the easiest way is to use your MongoDB as the glue between your Server sessions. If you do not care about actual persistence, then simply re-use the same document over and over and listen to changes instead of additions in your Client Collection Cursor observer.
It's completly fine to use the database for such a task.
Maybe create a collection of "Streams" where you store the intended receiver and the message, the client subscribe to his stream and watches any changes on it.
You can then delete the stream from the database after the client is done with it.
This is a lot easier than reinventing the wheel and writing everything from scratch.
We're using redux and immutable objects on our redux store.
The scenario is that a user might dump the current store status into database and later the user might be able to restore it.
I'm a newbie to redux.
Is there any keywords to search for this kind of techniques?
We will try to dump the status into JSON format and reload it from database.
The key word is "persistence". There's dozens of existing libraries for persisting Redux state already - you can either try using them as-is, or look at how they work and implement some of the approaches yourself.
To actually persist the state, you'd normally either do it in a store subscription callback, or in a middleware. Then, as part of your app's setup process, retrieve the persisted state (from the server or localStorage or wherever you persisted it), and pass it as the second argument to createStore(rootReducer, preloadedState).
I have used window.localStorage for this.
const MyReducer = (state,action) => {
switch(action.type){
...
case 'SAVE_STATE':
stateString = JSON.stringify(state.toJS())
window.localStorage.setItem('applicationState', stateString)
return state
}
}
I'm using signalr on my site. I have just one class that inherits from hub, and several aspx forms with client code that have client functions called by the hub.
when a client connects to the hub I add it to a collection with a clientID, when a client disconnect I remove it from that collection. Just to know if any client is connected. As long as at least one client is connected, a timer call some methods that fill a data repository on the server that is propagated to clients.
then I usually do before calling customers things like this:
if (users.Count() > 0)
{
this.Clients.All.UpdateData(JsonConvert.SerializeObject(someData));
...
}
all this works fine. But what I need and can not find how to do it in the hub, is to know what clients are connected to know if I should create the data repository for those clients and avoid making unnecessary database queries.
eg.
myHub.cs
Timer_tick()
{
...
//Collect data to clients Type 1
...
Clients.All.UpdateDataType1(jsonData);
...
//Collect data to clients Type 2
...
Clients.All.UpdateDataType2(jsonData);
...
//Collect data to clients Type 3
...
Clients.All.UpdateDataType3(jsonData);
ClientType1.aspx.js (2 clients connected)
hub.client.UpdateDataType1= function (jsonData) {...);
ClientType2.aspx.js (0 clients connected)
hub.client.UpdateDataType2= function (jsonData) {...);
ClientType2.aspx.js (0 clients connected)
hub.client.UpdateDataType3= function (jsonData) {...);
I know when I call clients 2 and 3 function I not need worry about whether clients are connected. but I need to avoid to obtain data that I will not use. The goal is just obtain data I will use to the connected clients.
All I can do is see if there are clients, but not if there are clients of an specic js
Is there any way to know this?
You can use groups for that, and you can write JavaScript code reusable across pages. Before starting the connection, your JavaScript could do this:
$.connection.hub.qs = { referer: document.location.pathname };
This way you store the calling page in a query string key. Of course you can store whatever other information you think it's useful for your goal. Then you can have this in your hub:
public override Task OnConnected()
{
var referer = Context.Request.QueryString["referer"];
Groups.Add(Context.ConnectionId, referer);
}
This way each client will notify which library is using, and with the groups you created against the client information you can easily target them by client type. No need to store anything in memory, which has always a lot of drawbacks.
You can check that link to map users to conection. If you take a look at the in-memory solution, you will be able to retrieve a list of connected users.
Is there any way to write a security rule or is there any other approach that would make possible only for currently connected (not authenticated) user to write/read certain location - admin should also be able to write/read?
Can a rule be written that disallows users to read of complete list of entries and let them read only entry that matches some identifier that was passed from client?
I'm trying to exchange some data between user and Node.js application through Firebase and that data shouldn't be able to read or write by anyone else other than user and/or admin.
I know that one solution would be that user requests auth token on my server and uses it to authenticate on Firebase and that would make it possible to write rule which prevents reads and writes. However, I'm trying to avoid user connecting to my server so this solution is not first option.
This is in a way session based scenario which is not available in Firebase but I have
some ideas that could solve this kind of problem - if implemented before session management:
maybe letting admin write into /.info/ location which is observed by client for every change and can be read only by active connection - if I understood correctly how .info works
maybe creating .temp location for that purpose
maybe letting admin and connected client could have more access to connection information which would contain some connection unique id, that can be used to create location with that name and use it inside rule to prevent reading and listing to other users
Thanks
This seems like a classic XY problem (i.e. trying to solve the attempted solution instead of the actual problem).
If I understand your constraints correctly, the underlying issue is that you do not wish to have direct connections to your server. This is currently the model we're using with Firebase and I can think of two simple patterns to accomplish this.
1) Store the data in an non-guessable path
Create a UUID or GID or, assuming we're not talking bank level security here, just a plain Firebase ID ( firebaseRef.push().name() ). Then have the server and client communicate via this path.
This avoids the need for security rules since the URLs are unguessable, or close enough to it, in the case of the Firebase ID, for normal uses.
Client example:
var fb = new Firebase(MY_INSTANCE_URL+'/connect');
var uniquePath = fb.push();
var myId = uniquePath.name();
// send a message to the server
uniquePath.push('hello world');
From the server, simply monitor connect, each one that connects is a new client:
var fb = new Firebase(MY_INSTANCE_URL+'/connect');
fb.on('child_added', newClientConnected);
function newClientConnected(snapshot) {
snapshot.ref().on('child_added', function(ss) {
// when the client sends me a message, log it and then return "goodbye"
console.log('new message', ss.val());
ss.ref().set('goodbye');
});
};
In your security rules:
{
"rules": {
// read/write are false by default
"connect": {
// contents cannot be listed, no way to find out ids other than guessing
"$client": {
".read": true,
".write": true
}
}
}
}
2) Use Firebase authentication
Instead of expending so much effort to avoid authentication, just use a third party service, like Firebase's built-in auth, or Singly (which supports Firebase). This is the best of both worlds, and the model I use for most cases.
Your client can authenticate directly with one of these services, never touching your server, and then authenticate to Firebase with the token, allowing security rules to take effect.