I want to develop an application where a number of clients should be able to see a list of elements. The elements in the list can be occupied by other users, so the users should be able to see when a given element is available/occupied.
The clients will fetch data via a REST API on GAE, and when they have fetched the list of elements, I imagined that I would create a socket connection for continuously updating the element list when the available/occupied status changed.
Reading the socket documentation for GAE lead me to the Channel API, which lead me to firebase https://cloud.google.com/solutions/using-firebase-real-time-events-app-engine
My question is: for an application as the above, should I use sockets (I cannot determine from the documentation whether I would be able to create sockets to clients?) or Firebase?
If I should use Firebase, how will this work seen from the client side - e.g. android/ios apps - they are supposed to use the SDK's to access the Firebase datastore?
I want the clients to contain as little logic as possible.
-Lull
With Firebase, you don't have to worry about sockets and connections if you use any of the provided client SDKs. It handles all the connection logic. You just indicate the location of the data you want to observe, and it will call your listener whenever there is a change.
Related
I am developing an app with c# client and Go server. Now I would like to implement real-time update functionalities, such as when I am inside a user's profile, to obtain their data in real time, so that if said user changes them, it is updated without the need to reload manually.
According to what I have been researching for this type of app, redis is usually used with a publisher and subscriber pattern, but I have not found anything on how to implement this in an app that maintains the connection with the server through sockets...
By directly having a bidirectional connection, could this functionality be developed in real time in some other way?
If anyone knows anything about it I would appreciate any information.
Creating a user, adding some record to collection in the DB, updating some stuff, etc..
All of these we regularly do with HTTP requests against REST api.
Think about making Event bus as server instead of REST api.
In that method, create user will be an event name: "CreateUser" instead of REST api endpoint: POST /users.
In reflect to any action done in the event bus, it will re-emit a following event telling to any body needed to know about, that the event was done.
If for example someone viewing the vehicles collection and another user just edit one of the columns or add a new vehicle instance, it will be reflected immediately to who views it online.
My question is if there attitudes like I mentioned above, if there some formally names for it, if it a good practice, if you know someone who regularly uses it, a framework or something etc. Does the socket.io server can handle and behave like http server in high workloads?
You can use websockets for this; they provide a bidirectional channel between client and server to send messages across. You will have to catch and parse the messages on each end yourself, as there is no additional protocol on top of them.
They don't hold state, so there is no knowledge of who is looking at what, or who got what. You could send the same update message to all connected clients and leave it to the client to use it or not.
You would have to reprogram your client code and the API endpoints, because it's a different way of doing things, and it can also do server push.
I have no idea about frameworks though, as I always use them without one. Websockets are fast, but server behaviour at high workloads depends on implementation, and I only have experience with the websocket server I wrote myself. I suppose the performance of the socket.io can easily be googled.
I'm a PHP developer with a lack of experience on other sever side langages.
I’d like you to give me leads, advice, keywords or whatever that could help me refine my research better.
What I want to do is basically to create a one to one mobile app chat that will scale.
There will be channels of 3 users: User A, User B and the "computer" pushing some messages according to some channels informations like the last time a message has been sent, etc.
User A should know if User B is online, writing, etc.
Every conversation should be stored in a database and would be analyzed by some algorithms. Those algorithms would also analyzed stuffs on user Facebook open graph.
The application should be able to send notification on IOS and Android.
A web administration should allow admin to set some stuff that will define what kind of message would be sent by the "computer".
I'v read lot of posts about websocket, xmpp, node.js, socket.io, etc but I don't have enough knowledge in those areas to decide what architecture should I build to make everything works together. Or maybe there is some cloud base solutions that would fit my needs...
Thanks
As you've stated there are many ways to implement that kind of structure but I am going to write about node.js + socket.io part;
1) It is scalable. You can use cluster, nginx, haproxy. etc. to apply load balancing to your socket.io application (see here) Of course you've to use redis or mongo or some kind of store for socket.io that different servers and processes can communicate each other. (see here)
2) socket.io have rooms. That means clients and any computer bots can join that room to share events with each other. So, in your scenario User A, User B and a computer bot should join to same room and events sent to that room will be broadcasted to every room member. (events can vary as online, typing, new message, anything) (see here)
3) node.js can send push notifications both for iOS and Android.
4) You can write every message to database of your choice on new message event.
5) You can create a REST api with Express framework for your Administration page. And you can use passport for authentication and authorization purposes. You can consume the rest api with Jquery or some other frontend framework like React etc.
Meteor is very well suited for something like this and gives you everything you need. There are also open sourced chat systems built with meteor already to get an idea of where you need to go. The more custom route would be to do what #cdagli said.
I am looking for advice/guidance on how to achieve the following:
I have a circuit mounted and connected to an Arduino and I am able to easily retrieve data from it, using Python and the pySerial module. It allows me to determine the value of an analog input over time.
At the moment I am storing that data to a file, with a time stamp and the correspondent value and I would love to hear opinions and thoughts on how I could 'share' this data to a web server and 'play' it live.
Is it possible to 'stream' the values into the dump file and retrieve data from it at the same time through an AJAX request or should I look into event-driven web servers like 'Tornado', 'Twisted'...
I am a bit lost here. Just for the record, I am comfortable with PHP and JavaScript for the final output, I just don't have a clue on how to constantly 'stream' the data I need.
Thanks in advance.
If you don't plan to update the Ardunio device too much then it would make sense to have the Python component continue to collect the data over the serial port and publish it in a way that can easily be consumed by a service which can distribute the information in a more efficient, and probably flexible, manner.
e.g.
read the data from the serial port and publish messages onto a message queue. The message queue can then be read by any other component and the data can then be distributed to other applications/clients.
Make a web call to a server that can process each update and distribute to other applications/clients.
You could use something like Pusher (who I work for) and make a call to the REST API to deliver each message to any connected clients. Whilst this is a good way of distributing your data you will be publishing your data even if no clients are listening so I think you are best to get the data to a component like a web server first.
Assuming you go with 1 or 2, you can then use realtime web solution to distribute the data to any number of clients. You could use Pusher here or you could use a self hosted solution.
So, the data flow as I see it would be:
Ardunio -> small Python app -> Queue (or HTTP request to Web server) -> Realtime Web Technology -> Many clients
I'm trying to design an application based on the OpenSocial API, and I'm uncertain of how the pubsub apparatus will work. This appears to be analogous to a Unix pipe, or perhaps an RSS feed.
Is a channel persistent across browsers / computers? That is, can I subscribe to channel "x" on browser A and publish to "x" on browser B, and have this data be read in browser A? If not, is there a convenient opensocial method of accomplishing the same thing?
Also: if one gadget subscribes to a channel after data is published, can that data still be read?
Pubsub is an API feature that allows different OpenSocial gadgets to talk to one another while being on the same page in an OpenSocial container.
That means the connection is not persistent, but if for example you have a map gadget, and a gadget with a list of restaurants which both appear in a page, this mechanism can enable the list to stay relevant to the currently shown area of the map.
This would require the two gadgets to agree on a message format and channel ahead of time.