I want my chrome addon to connect to redis server. One of the option explored is chrome native messaging since addon/browser cannot directly connect to redis. Browser/addon can only communicate through http/websocket.
chrome native messaging seemed to be deprecated and I couldn't find chrome.runtime.connectNative or chrome.runtime.sendNativeMessage mentioned in the current version of browser. I am currently running a web server which can accept http calls from addon and communicate through redis but looking for a faster way.
What can be fastest way for addon to connect to redis?
Edit: I dont intend to publish this addon. I will be only user running this addon but I run this addon on multiple computers running on cloud.
As #Christopher rightly pointed out, native messaging is not deprecated. In fact, it is supported by pretty much all modern browsers
There is no alternative to native messaging, but I'm not sure that you would necessarily want your users to have to download, install, and configure Redis (which would be required for this to work).
Even though your question doesn't include details about how you are using Redis, I think the Chrome Storage APIs could be helpful, especially since they are just key/value pair storage. You can also use the sync storage if you want data preserved across devices.
If the Storage APIs don't fully cover your needs and you still need Redis, you could also use Chrome Storage as a caching layer between the extension and Redis. In this scenario, your background process would GET and POST data to Redis (via your web server) in the background while the extension only directly utilizes the local storage. This would sacrifice a bit of accuracy (maybe things changed between cached requests) and add a bit of complexity but would speed things up.
Side note: Redis really should not be a performance bottleneck - perhaps you need to scale up your web server or move Redis to a dedicated server/cluster?
Related
I have a vue.js/Cordova app in which I want data coming from Rest web services to be available in offline mode, the trivial solution first coming to my mind is using local storage API by indexing each w.s response and make my frontend service return data from local storage in offline mode or in case of a slow internet connection. But I think doing this directly using local storage API is very tricky, and I thought maybe using service workers and pwa concept can do the task properly.
Now, my question is: in my use case, can service workers do the job? second, are service workers available in a Cordova android/iOS app ? Finally, what are probably the compatibility issues/usage risks when running on mobile devices ?
Unfortunately, if you are using Cordova to serve up files from either file urls or http urls, as you probably will do unless serving from a website, it will not work on Android, due to the fact that service workers only work in secure contexts. See https://www.w3.org/TR/service-workers-1/#secure-context.
However, on iOS there is a plugin that allows you to use service workers, even on older versions that have no native support.
Even without the lack of support in android, service workers won't be present in enough platforms to be useful as a core part of your app.
In your case, as you are already using Vue, I recommend using Vuex, Vue’s Application Data Store.
You also get some other benefits.
I am working on a chrome extension which has to store data of its user. For that I am using a hosted server which is running a mysql database. But currently any addition or change in data fires a request to the hosted server.
Chrome extension provides chrome.storage.local API which is suitable to store data upto 5mb. I want to take advantage of this storage API to reduce number of requests to my hosted server by using it as a temporary storage.
I am planning to use chrome.storage.onChanged.addListener and chrome.storage.local.getBytesInUse to check if data stored crosses a certain threshold value and then only fire an ajax request to the remote server to save the data. Upon successful response, the old data in chrome.storage will be flushed off.
But there are chances of losing some new data which is created during the process of request/response cycle from the server.
How can I prevent any loss of data? Is there any alternative solution to this optimization problem of reducing number of requests to the remote server from the extension?
Thanks.
This isn't really a question about chrome extensions. It's more about persistent databases that work offline and synchronize intelligently. Which happens to be a very hard problem to do right.
The easiest solution is to use chrome.storage.sync. That buys you persistence for free with the caveat of limited storage. You should definitely see if this is feasible before trying other options.
Otherwise, I recommend looking into 3rd party options before rolling your own solution. You might have heard of progressive web apps, which work offline, and sync when internet is available.
An article about the advantages of progressive web apps
Google Tutorial
PouchDB, a well regarded web database that works offline and syncs to other databases
Look into those. It'll be well worth the trouble. otherwise you'll just end up building hacks on top of hacks trying to get syncing to work.
... one last thing... make sure to add your remote database's URL to your manifest's permissions.
I want to connect a bunch of weather sensors to a Raspberry PI. Writing the daemon that reads the sensors and writes the data to a database will be the easy part since I'm a systems programmer. I also want a simple cross platform UI for this device so I'd like to set my Raspberry Pi up as a WIFI hotspot that people can connect to and then just entering a URL like 'weather.local' into a browser which would take them to a web page where the weather sensor data is continually updated. I.e. I want the sensor daemon to 'push' updates to the web page.
The problem is that I'm no web developer. The solutions I can think of off the top of my head are:
Flash, which is out because I want this to work on mobile browsers.
Using Java script and hanging HTTP requests to a web service.
HTML5 socket.io which is presumably the same as WebSocket.
If I go with option (2) even if it's a kind of polling, I'll have to incorporate some form of HTTP server into my sensor daemon and I have a fair idea of how to code that. My question, however, regards the HTML5 socket IO. Can I use this to connect directly to a TCP/IP binary socket or do I need a server side WebSocket library? Also how widely is HTML5 socket.io/WebSocket implemented on mobile browsers?
WebSocket always begins with an upgrade handshake over HTTP, so you do need to have basic HTTP capability. It's simple enough that you can hand-code it.
WebSockets is basically supported by all modern browsers. It is not used that widely because it's a pain to set up on traditional HTTP servers and messes up with many proxies, but that's not a problem for you. As long as the client is a recent version of anything, it'll work.
A note about option 2: browsers have a native implementation of it — that means you don't need so much JavaScript on the client. You just create the EventSource object and listen to its events.
We have an application which consumes a large amount of data. Currently a desktop app, but we would like to deliver it via the browser.
It doesn't make sense to me to create a web app where we need to transfer a ll the data used for the visualizations.
We're looking at RDP and some products out there that provide RDP access via a fully javascript client. They seem to work well with our app, but I've been thinking about what it would take to move off Windows.
Switching the front end so that it could run under Linux would not be trivial, but not impossible, so the main stumbling block would be delivery.
I was wondering if there are any X11 javascript servers out there, but have not found any leads.
Use xpra's builtin html5 client, it supports any application you can run on an X11 desktop.
You can use an HTML5 VNC viewer like https://github.com/kanaka/noVNC coupled with a VNC server like RealVNC
AFAIK, recent GTK has been ported to HTML5+Javascript in Gtk Broadway
And you could make your application a web application, for instance by using Wt, or by making it an HTTP server thru specialized HTTP server libraries like libonion, libmicrohttpd etc.
By using AJAX techniques (e.g. thru jquery) your application won't transmit all the display data to the browser at once (but only incrementally and only the actually shown data).
You might also consider fastcgi as a way to connect your application to some web server.
I know two, both at very infancy:
https://github.com/GothAck/javascript-x-server
and
https://github.com/ttaubert/x-server-js
Both need simple tcp-to-websockets proxy in front, but all X11 logic happen inside web page and all x11 objects exist and interact within browser (so it's not just remote framebuffer but real server)
You can ever run full Linux distribution in Web Browser, but that's require to run x86/ARM emulator and GNU/Linux inside it. It provides X server with possible web connection too.
For very simple applications you can use libgreattao toolkit and tao-network-client to connect to it. I'm the author of both project. The API isn't yet frozen, but it rather behaves stable. You can read about it here:
https://nintyfan.wordpress.com/2015/04/30/server-buildin-into-libgreattao-and-tao-network-client/
It can provide some problems with applications with a lot of data, because all elements must be send to client, when it were created, but instead we don't send full graphics(only icons is send) and user interface could be changed quickly. It also don't support mouse enter/leave/move events.
I must tell: do not download tarbar, but download version from svn.
Sounds like the easiest approach for you is to get xrdp, which is an RDP-server for X. Then you would use your RDP client to connect to it. I think Nomachine NX supports html directly now, but I'm not sure. There was talk of an html X2go-client, but I don't know anything about that either.
I have an external application that is automating some tasks on a website. My goal is to implement a system which allows for the program and Chrome to synchronize cookies. While it is possible to query Chrome's cookie DB to read cookies, it is not possible to update the DB since Chrome maintains an I/O lock on the file, thus preventing easy synchronization.
The next logical step to me was to attempt to create an extension which will update cookies as necessary (through Chrome's cookie API). However, after about two days of research I have been unable to find an effective means to communicating cookie data between the browser and my application (which is written in Python.)
Sockets are out because it's for desktop based applications only. Websockets are out because as far as I can see it's impossible to setup a Websocket server using the HTML5 API (which is what I need since the browser needs to be the server and the program would be a connecting client). I'm really not sure what I am left with at this point. Is there something really obvious that I'm missing here? Any help is appreciated, cheers.
This feels like a very weird way to do whatever you're trying to do. Why are you doing this again?
Anyway, the most obvious solution is this:
You obviously have to secure communication between the app/plugin and the server. Again, this feels like a very weird way of doing stuff. But the solution will work. In this case both the app and the plugin are WS clients and your server is the arbiter.