I follow the laravel document to implement the mailgun service to send emails.
It is working quite well, but when my project starts growing large, I am considering some performance improvement.
When I look into the laravel queues, and its example is about using it for sending emails.
And here comes to my question,
When I use mailgun http api to send emails, is it going to improve server performance if I also put the request on queues?
Related
I want to use Server Sent events in Laravel and not websockets. How can I hook server sent events up to Laravels event broadcasting functionality? I would like to maintain a similar experience to using websockets in Laravel if possible. Would it be possible to keep using Pusher channels as well?
The benefit of websockets is that it allows you to relay real-time updates from the backend to the front-end and make client-side events appear in real time. Therefore I would say that you need websockets. From my own exprience, Pusher is excellent for this.
I am curious to know why Direct mail doesn't support the incoming emails to the same email address used to trigger the notifications. Why do we need to receive on another email?
Is there any architectural limitation to this in terms of security/functionality etc..
Providing email services that includes receiving emails is a different level of service then sending emails and far more complicated internally. DirectMail is a message sending service, not an email server. Alibaba does offer a full email service for its customers in China.
Hosting and receiving emails is far more complex. If you were to provide a service to send and receive emails you have to have an api waiting for an email to arrive, another to retrieve emails from the storage when the user requests, and another to send out the emails.
On the other hand DirectMail just has one service send out either predefined emails that get set up ahead of time or emails that are sent from Function Compute. This way there is no waiting/server overhead, just send and done.
if we have a project based on Two servers one for the front end (React / Vuejs) and one for the backend (laravel application).
The front-end only talks with the server using api service. Now i know how to broadcast a message or notification on the same server using pusher , and laravel-echo.
But what if we have this kind of scenario. I have my mind blank on this what to do. Even i dont know that can we broadcast something accross different domains
Take a look at websockets.
You can create a websocket and have your frontend app subscribe to it.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
Situation
Am trying to build a real-time chat toy app using the following technology stack
RethinkDB
Laravel 5
Ratchet
What I perceive to be the conceptual situation
The green arrows represent the real-time exchange of data.
The black arrows represent other non real-time requests and exchange of data.
My question
I was wondering if my understanding of the implementation of chat using the technology stack is correct based on the diagram?
if there are inaccuracies, what would they be?
Your interpretation seems correct, although I would not suggest using the websocket to send data to but only to distribute live data to all subscribers of a channel.
To do this, get an API(preferably) going to receive new posts/chats/users.
And use a push server to send the data received to the socket.
A push server is just an in between of the app and websocket that allows php(laravel) to access the socket easily.
Edit: to elaborate
To retry explaining this to you.
All clients listen to the WebScoket Server. This is a connection which is passive and they will only receive messages from the socket according to what topics/subscriptions they have.
When someone wants to send a message(in case of a chat application) they send it to an API to check if the right user sent it, maybe even use apikeys or other means of security.
Once the message is received in the API then the API wants to distribite it to all listening clients for that chat room/topic/subscription.
So the message is forwarded to the pushserver which is an in between of the backend (API, controllers) and the WebSocket (subscriptions, topics).
The pushserver forwards the message to the WebSocket afterwards and then the WebSocket distibutes the message to the correct listeners.
Advantages of using an API:
Security
Scalability
I have a Java application which I make available via RESTful web services. I want to create a mechanism so clients can register for notifications of events. The rub is that there is no guarantee that the client programs will be Java programs and hence I won't be able to use JMS for this (i.e. if every client was a Java app then we could allow the clients to subscribe to a JMS topic and listen there for notification messages).
The use case is roughly as follows:
A client registers itself with my server application, via a RESTful web service call, indicating that it is interested in getting a notification message anytime a specific object is updated.
When the object of interest is updated then my server application needs to put out a notification to all clients who are interested in being notified of this event.
As I mentioned above I know how I would do this if all clients were Java apps -- set up a topic that clients can listen to for notification messages. However I can't use that approach since it's likely that many clients will not be able to listen to a JMS topic for notification messages.
Can anyone here enlighten me as to how this problem is typically solved? What mechanism can I provide using a RESTful API?
I can think of four approaches:
A Twitter approach: You register the Client and then it calls back periodically with a GET to retrieve any notifications.
The Client describes how it wants to receive the notification when it makes the registration request. That way you could allow JMS for those that can handle it and fall back to email or similar for those that can't.
Take a URL during the registration request and POST back to each Client individually when you have a notification. Hardly Pub/Sub but the effect would be similar. Of course you'd be assuming that the Client was listening for these notifications and had implemented their Client according to your specs.
Buy IBM WebSphere MQ (MQSeries). Best IBM product ever. Not REST but it's great at multi-platform integration like this.
We have this problem and need low-latency asynchronous updates to relatively few listeners. Our two alternative solutions have been:
Polling: Hammer the list of resources you need with GET requests
Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.
In the response to the RESTful request, you could supply an individualized RESTful URL that the client can monitor for updates.
That is, you have one URL (/Signup.htm, say), that accepts the client's information (id if appropriate, id of object to monitor) and returns a customized url (/Monitor/XYZPDQ), where XYZPDQ is a UUID created for that particular client. The client can poll that customized URL at some interval, and it will receive a notification if the update occurs.
If you don't care about who the client is (and don't want to create so many UUIDs) you could just have separate RESTful URLs for each object that might want to be monitored, and the "signup" URL would just return the correct one.
As John Saunders says, you can't really do a more straightforward publish/subscribe via HTTP.
If polling is not acceptable I would consider using web-sockets (e.g. see here). Though to be honest I like the idea suggested by user189423 of multipart content-type or chunked transfer-encoding as well.