I know this will be closed question but I can't find what I want so I need to ask pros over here.
What is the best option for real time content in laravel app like messages, notifications and even loading new post as example.
Besides using pusher or other services.
Something like nodejs and socketio but
what are the best
options for laravel apps?
If you are wanting to take advantage of Laravel's Broadcasting functionality then going with a supported driver is likely best to get you started.
Which means that if you don't want to use Pusher then it is a combination of Redis and Socket.io.
Our small team doesn't have a dedicated dev-ops team, so we went with Pusher and have had a good experience with minimal server config. We do also use Redis for pubsub communication between a couple of microservices, some api throttling management, and of course queues. It might be worth noting that if you are a Laravel Forge user it provisions Redis out of the box for you too.
You have to think of your software needs.
Pusher comes with a Free Tier, and its easier to implement than Socket.io
Setting up Socket.io will come with some learning curve, you may want to expend your time on other functionality of your project. But hey its free right? unless you consider time more valuable, which is almost always the case when it comes to programming.
With Pusher, you can quickly start your project, focus on other less trivial requirements.
Socket.io may save you money, but only once is running.
If your project doesn't consume the free tier completely, it's a no brainer.
Related
i am just new into this concepts about sockets and i am so confused.Firstly i found that i can use pusher for realtime messages but it limits concurrent connections 100 and number of messages to send..then what about socket.io, does it have some kind of limitations? From what i have researched i assume it has no such limitations as pusher but i want to be sure.can anyone explain me how socket.io can do this, i mean if socket.io have no such limitations why would pusher be even used with payment plans?
You do not get the same limitations with socket.io however it can be a little daunting to set it up, I found this introduction on laracasts really useful when I was looking into it - https://laracasts.com/series/real-time-laravel-with-socket-io/episodes/1
I've been reading about websockets and SaaS like Pusher and Socket.io recently, while working on my Laravel chat practice application. What I don't understand is, why do we need external software to establish a websocket connection? Can't the server code like Laravel just directly establish the connection with the front-end like Vue.js? Why does it have to go through the middleman like Pusher and Socket.io? Sorry for the noob question.
It doesn't have to.
Those pieces of software just happen to make it trivial to work with the Websocket protocol.
Remember, Laravel is an opinionated framework. This means that it will pick and choose its own libraries to abstract away these kinds of concepts for you so that you don't have to worry so much about what's going on under the hood.
Basically, there are two components that you need in order to be able to work with Websockets:
A Websocket Server
A Websocket Client
The reason Laravel doesn't communicate directly with the front-end using Websockets is because Laravel itself isn't a Websocket server. At least, not really. And while PHP does have support for working with the Websocket protocol - and even some libraries to leverage it a little more nicely - it just isn't used to handle long-lived processes as often as other languages.
Instead, Laravel uses the Pub/Sub functionality that Redis provides to listen to events that occur through Redis and the Predis library. The reason why it does this is because Laravel is better-suited as a middle-man for the websocket server, and all connected clients.
In this way, Laravel can both pass information up through to the Websocket server using Broadcasting Events, as well as receive event information from the Websocket server and determine if users have the ability or authorization to receive them.
If you don't want to use Pusher, there is a library that will allow you to run your own Websocket Server specifically for Laravel called Laravel Echo Server.
Under the hood, this library still uses Socket.io and Redis in order for all moving parts to communicate with each other seamlessly in a Laravel web application. The benefit here is that you won't need to worry about the number of messages being sent by the server.
The downside is that you now have to know how to manage and maintain this process on your server so that the Websocket Server will know to turn on every time you restart your server, or if a failure happens, etc.
Check out PM2 to learn more about running and maintaining server daemons.
If you don't agree with Laravel's opinions on how to handle Websockets, then you could theoretically use any other server-side language to handle the websocket protocol. It will just require a greater working knowledge of the protocol itself; and if Laravel needs to work with it, you'll have to know how to write the appropriate Service and Provider classes to be able to handle it.
Short answer? You don't have to use them. Knock yourself out writing your own server and client side websocket implementation.
Longer answer.
Why use Laravel? I can do all that with straight up PHP.
Why use Vue? I can do all that with vanilla javascript.
We use libraries and frameworks because they abstract away the details of implementation and make it easier to build products. They handle edge cases you don't think of or things you don't even know that you don't know about because they are used by thousands or millions of developers and all the knowledge and bugs they have encountered and fixed are baked into the implementation.
This is one of the hallmarks of software engineering, code reuse. Don't repeat yourself and don't write any software you don't have to. It allows you to focus on building a solution for your particular requirements, and not focus on building a bunch of infrastructure before you can even build your solution.
I've never used Pusher, but it looks like, yes, it is a SaaS product. But Socket.io is open source.
Recently, I found myself wanting to develop a web application using real-time technologies. As far as I see, I have two ideal solutions.
Use WebSockets. (in my case Socket.io)
use a real-time database like RethinkDB (I guess stuff like Pusher and PubNub also fall into this category too)
I am lost, however. What are the technical differences between these two solutions? When should I prefer one over the other?
They actually work really well together. Using RethinkDB changefeeds to watch for changes in the database and then using socket.io to pass those changes to the client(s) is a good way to use them in tandem. I'd recommend taking a look at Jorge Silva's answer to this similar question.
socket.io vs RethinkDB changefeed
I was only familiar with this because of a tutorial I did with an interesting tech stack of React, Redux, RethinkDB, Express, & Socket.io. I'm not sure what you're using for your front-end/view layer but this might be helpful for learning how to integrate RethinkDB+Socket.io
http://webapplog.com/reactive-web-stack/
Good Luck!
We are going to develop rest server for our application (and all logic is on client javascript).
So we thought to use Phalcon php, but we also need to create realtime chat system, which is much more easy to do using node.js. This made us think about using node.js instead of phalcon
Unfortunatly, we are not good expirienced in node.js, we love phalcon for its performance and internal beauty.
The quiestion is, did anybody compare phalcon and node.js performance? May be it's better to use node.js only for long polling chat requests, but i dont like when project is connected with so different tools.
You are trying to compare two different things IMO.
node.js has a lot of power and flexibility but so does Phalcon. If you want to create a chat application with Phalcon, then you will need to implement some sort of polling mechanism in your browser that would refresh the chat window every X seconds. Getting/Inserting the data from the database will be Phalcon's job. Javascript will be used to do the polling i.e. refresh the chat page every X seconds.
The problem with this approach is that you might be hitting your web server every X seconds from every client that has the chat application open - and thus refreshing the chat contents, even when there are no messages. This can become very intensive very quickly.
node.js has the ability to send messages to the subscribed clients instantly. Web sockets can do the same thing I believe.
Check this video out, which will give you an idea of how this can be achieved easily:
https://www.youtube.com/watch?v=lW1vsKMUaKg
The idea is to use technologies that will not burden your hardware, rather collaborate with it. Having a "subscription" notification system (such as sockets or node.js) reduces the load on your application since only the subscribed clients receive the new messages and no full refresh is needed from the chat clients.
Phalcon is great for the back end with its speed and it can be used to construct the message which in turn will be passed to the transport layer and sent to the client. Depending on how you want to implement this, there are plenty of options around and you can easily mix and match technologies :)
as #Nikolaos Dimopoulos said, you're trying to compare two different things.
But here is my advice, while you're experienced with PhalconPHP framework, and you want to benefit from Phalcon speed and performance, you can implement the web app in Phalcon FW, and the chatting system in Node.JS as a service.
If your web application "The Phalcon app" needs to push messages from the backend, you can use http://elephant.io/ library for that, I have done this before with Yii framework and Node, and it's working perfectly.
My advice is to use what you already know, experimenting with nodejs just for the chat application.
Mainly because you said you do not have experience with it, so, because the chat app is something a lot of people made you'll find plenty of examples.
By doing so you will learn a lot from node and might even think about migrating from Phalcon if it suits your needs, using the features offered by expressjs for example.
I would not choose one over the other based on performance.
I am looking for a realtime hosted push/socket service (paid is fine) which will handle many connections/channels from many clients (JS) and server api which can subscribe/publish to those channels from a PHP script.
Here is an example:
The client UI has a fleet of 100 trucks rendered, when a truck is modified its data is pushed to channel (eg. /updates/truck/34) to server (PHP subscriber), DB is updated and receipt/data is sent back to the single truck channel.
We have a prototype working in Firebase.io but we don't need the firebase database, we just need the realtime transmission. One of the great features of firebase.io is that its light and we can subscribe to many small channels at once. This helps reduce payload as only that object data that has changed is transmitted.
Correct me if I am wrong but I think pusher and pubnub will allow me to create 100 truck pub/subs (in this example) for each client that opens the site?
Can anyone offer a recommendation?
I can confirm that you can use Pusher to achieve this - I work for Pusher.
PubNub previously counted each channel as a connection, but they now seem to have introduced multiplexing. This FAQ states you can support 100 channels over the multiplexed connection.
So, both of these services will be able to achieve what you are looking for. There will also be more options available via this Realtime Web Tech guide which I maintain.
[I work for Firebase]
Firebase should continue to work well for you even if you don't need the persistence features. We're not aware of any case where our persistence actually makes things harder, and in many cases it actually makes your life a lot easier. For example, you probably want to be able to ask "what is the current position of a truck" without needing to wait for the next time an update is sent.
If you've encountered a situation where persistence is actually a negative for you, we'd love to hear about it. That certainly isn't our intention.
Also - we're not Firebase.io -- we're just Firebase (though we do own the firebase.io domain name).