I'm dabbling with using PubNub for various parts of my app. I'm using their AngularJS library for this.
Right now, I'm just testing it for doing "analytics". Basically, I want to track ever more a user makes in the app - buttons pressed, states navigated to, etc. So, I track actions and publish on a channel.
It all works great - when the user is online. However, when offline, I lose all this tracking. I was sort of hoping that PubNub client would automatically queue all the publish requests. It does not seem to do this.
So, I'm thinking I'll have a service to collect all publish requests and put them in a queue if the device is offline. Once the device is back online, I'll publish any queued requests.
Is this the best approach? Does anyone have a better suggestion? Does PubNub already have this ability and I'm just not finding it?
Yes, currently, this is the best way to achieve this.
There are different scenarios for queuing / retrying, for example -- depending on the content of the message (eg expiration/timeliness of the message), and depending on the reason (no internet, channel permissions) you may want to re-queue/retry some and not others, etc.
So if you can implement your own retry logic custom to your use case, thats ideal. We may provide more productized options on this moving forward...
geremy
Related
I make a web service and I'm going to use a React. A data for the service will be fetch from my API.
But there is a simple way to find out which endpoints I'm using, and what data I'm sending. This knowledge gives a lot options to make bots for my service.
Is there any option to prevent this?
I know, I can require a signing all requests, but it's also easy to get to know.
This cannot be done. Whatever is done in client-side JavaScript, can be reverse-engineered and simulated.
Efforts should be focused on preventing API from being abused, i.e. throttling or blacklisting clients based on their activity or available information (user agent, suspicious request, generated traffic). If the use of API allows captcha, suspicious clients can be asked for proving their humaneness.
There are half-measures that can be applied to client side application and make it less advantageous for abuse (and also for development).
Prevent unauthorized access to unminified/unobfuscated JS AND source maps. There may be a need to authorize them on per user basis. This will make debugging and bug reporting more difficult
Hard-code parts that are involved in request signing to browser APIs, e.g.:
apiKey = hash(NOT_SO_SECRET_KEY + document.querySelector('.varyingBlock').innerHTML)
This requires bots to emulate browser environment and makes their work much less efficient. This also affects the design of the application in negative way. Obviously, there will be additional difficulties with SSR and it won't translate to native platforms easily.
here two basic preventive measures that you can use.
Captcha
Use a captcha service like recaptcha. so that user can use your website only after passing the captcha test. Its highly difficult for bots to pass the captchas.
Rate Limit Api usage.
Add rate limiting to your api. so that a logged in user can only make 100 requests in 10 minutes, the numbers will depend on you use case
I'm working on a simple chat application that uses this frameworks, libraries: react, socket.io, express.
When a user opens the web app for the first time, he sees a login form, and after login, the server retrieves the list of all users and sends it to the client. When someone writes a new message, the server sends the message to all the clients.
As you can see, every part of the app depends on the server.
Does it make sense to use a service worker? Can it be at all?
As far as I know, a service worker is good at storing images, css, js files, and it help the users to use the app while they don't have internet connection.
But I do not know when everything depends on the server what can be done.
You have a great question.
You can most certainly use a Service Worker but most likely not to the extent some other apps could use it. You have outlined the problem yourself: your website depends on the server so it's not possible to make it offline or so. Some other websites could be made offline or could be made mostly offline showing some content without network connection and giving the full experience when connectivity comes back, but that doesn't sound like to be the case for your website.
Based on the description you've given, there's still something you could easily use Service Worker for, however. You've understand correctly that SW is very good at storing (caching) static assets and serving them from the device's cache without any network connectivity. You could use this feature and make your site faster. You could use a SW to proactively cache all the static assets of your site and have the SW return them from the local cache without requesting anything from the network. This would make your site a bit or much faster, depending on the user's connectivity (if the user has a slow 3G connection, then the SW would make the site super fast; if the user has a steady fiber or whatnot, then the difference wouldn't be that huge).
You could also make your site available offline without any internet connectivity. In that situation you would of course show the user a message saying "Hey, it seems like you're offline! Shoot! You need connectivity to use the app. We'll continue as soon as we get the bits flowing!" since this would probably make the user experience nicer.
So, in conclusion: you can leverage SW to make the initial loading of the site faster but you most likely won't get as much out of a SW configuration as some other site would get.
If you have any other questions or would like to have some clarifications, just comment :)
Sure you can benefit from having a Service Worker, it is universal enough to have an application for all kinds of applications and I don't agree it is only good for static assets.
It all depends on the actual requirements for you application, obviously. But technically there is no limitation that would prevent you from caching your users response in the Service Worker.
Remember that "offline" is a condition that happens in multiple circumstances - not only being far from the network coverage, but also outages, interferences, lie-fi or going through a tunnel. So it can as well happen intermittently during your app operation and it might make sense to prepare for it.
You can for example store your messages for offline in IndexedDB and for messages sent during that time, register a Background Sync event to send it to the server when the connectivity is back. This way users might still be able to use the app in the limited fashion (read the previously exchanged messages and post their own messages to be sent out later).
I'm studying React Native right now, and I'm trying to figure out how to enable the reception of Push Notifications even when the app is closed, just as Facebook does.
I'm a web developer, so I'm not used to mobile apps' "Manifest" logic. Where should I start from?
Thank you!
It seems that since you are a web developer, mobile app is not yet familiar with you. Actually, setting up push notification will require a few more official steps (differently on iOS and Android), and after everything is set, the push notification will happen between Apple server (or Google server) and smartphone's OS (which is iOS or Android), so the push notifications will come to the phone no matter what (without knowing/caring your app is opened or closed ^^)
In the programming code of our app, we can do our logics when the notifications come based on 2 cases: users is using the app or app is not running (not running means users are not using your app, and it is either staying awake in the background or users have exited it completely - e.g. pressing Home button twice on iPhone, and swiping the app away)
Actually, If you want your app to stay awake in the background, you can add some settings to the "manifest"-like files (of course differently on iOS & Android). However, my experiences taught me that keeping the app awake will encourage the users to complain and delete our app (my previous app's user once complained about his iPhone's battery was consumed greatly because of my app ^^)
If you really want to keep your app awake, you can set it in the settings, then in the push notifications' data, you can include extra parameters, and finally in the function of receiving push-notifications in your app, you can do anything with those parameters!
In short, you may just need to config push-notification properly for your app, and Apple/Google will do the rest, either your app is running in background or totally closed, it will receive the notifications. Hope you can find a good solution based on my explanation. If there's still something unclear, feel free to post here some more details on your needs, thanks!
This is the library I'm using with my previous react-native project: (they also have tutorial there ^^)
https://github.com/zo0r/react-native-push-notification
ADDED EXPLANATION: (based on author's needs):
The goal is: the user will register/login in the app, and will subscribe to some future events.
=> whenever users open the app, data will be sent to Apple/Google server to get a token, and you will use this token together with user's subscribe data to send all to your own push-server (you can use PHP or node.js server or whatever)
When an event gets updated a notif. should be sent to all the users who are going to that event. So a notif. aimed to certain users only.
=> like the above answer, data will be sent every time users open app (or change settings, you can do it in your logic of the app, because data will be kept your own push-server, which means on that server, you can even see user list, and can aim to certain users - it depends on what data will be sent to the users from the smartphone, but users may refuse inputting too much information like name, age or email, but it's up to your service's need ^^)
By clicking on it, the app will open and a certain page of the app (pre-existing) will be shown.
=> by default, when an notif. is clicked, the app will be opened for sure, and here once again, you can add extra parameters to the notifications (which is the landing page you need, then in the function of you app, just go there - but it may get extra logics for this. Besides, when to push notification, and which data should be pushed etc. will be controlled by your own server)
It seems like the most complicated part will be the "sending to certain users" one!
=> I explained this already, but you're right, actually it's complicated, because you need to create your own server with lots of API and logics based on your needs, and it need a few more steps (complicated one because you need to register many things with Apple & Google, then adding their Certificates into your own server etc.)
Hopefully you will achieve it, I suggest you play around and truly understand how push-notifications work first (for both sides - your own server and your application) - Good luck, though ^^
We've got a program that runs on our network (it's published to our app-server and run from there as well) and I'd like to show an Alert window (by DevExpress) to all users who are running the app, whenever a new item is entered. Obviously the code would go in the Save event but when I put it in there, it only works for me, meaning I'm the only user who sees the alert, no one else. The same can be said for other users...they only see the alert when they enter it, not when someone else enters it.
Any ideas as to how this can be accomplished?
You can use straight MSMQ to put on a message and have clients listen on that queue. You can also use NServiceBus (which does use MSMQ) that has a publish subscribe framework built in. This way your clients can subscribe to all clients or certain clients.
Since WinXP, Vista and Win7 have MSMQ it just maybe a matter of installation and configuration (which NServiceBus will do 'automatically' for you)
You could try with Comet if you want true push mechanism. Otherwise you could use periodical pull using setInterval and ajax calls. However, both techniques have some performance repercussions.
Can anyone think of a good way to allow the server to notify the client based upon server processing? For example, consider the following events:
A user requests a deletion of data, however, due to it's long-running time, we kick it off to a queue.
The client receives a "Yes we completed your transaction successfully".
The server deletes the item and now wants to update any local structures any clients may be using (I'd also like to notify the user).
I know this can be done by client-side polling. Is there a event bus type way to do this? Any suggestions are welcome, but please keep in mind I am using GWT with App Engine.
The standard AJAX interaction is that the client sends requests to the server and expects some sort of response back fairly quickly.
In order for the server to initiate a request to the client, you will need to use WebSockets, and experimental HTML5 feature currently only supported by Chrome.
Or, to simulate this kind of interaction, you can use Comet (long-polling), made available in GWT by the rocket-gwt project.
You want server events for GWT? Have a look at GwtEventService (they couldn't have chosen a better name): http://code.google.com/p/gwteventservice/wiki/StartPage
Of course, it uses a Comet implementation, but you can't do any different when using HTTP, the client always initiates the communication. Request, response.