I am looking to create some sort of a function that would send Laravel notifications to C# application. The idea is that whenever a user purchases someone, an administrator is then notified by receiving a notification through a C# application that they would run on their PC. However, at the moment the only way I can think of is by creating a listening server in C# and then just send the data via sockets through PHP. Is there anything else that would be considered a better approach?
Kind Regards,
George
You can build an event-driven system. Your Laravel application will be producer which responsible for send events, and C# application will be consumer. There are lots of options to do it.
I would like to recommend AWS SQS. Also, you can easily create a Lambda, then you can add your newest queue as a trigger. When you do this, you will have a serverless architecture, and you won't worry about the scaling part, AWS handles these stuffs. Also, you can check this. It can be a good start point to meet serverless architecture.
Related
I have an Azure Function App which sends emails and sms messages based on data received from an endpoint. Recently I've been asked to include phone calling for high priority issues. I haven't been able to find any resources or hints on how to handle this with using Azure resources.
Is this even possible with Azure resources? If not, can somebody point me in the right direction for how to accomplish this?
To my knowledge, it not possible with azure functions but you might want to look into azure communication services https://learn.microsoft.com/en-us/azure/communication-services/quickstarts/telephony/pstn-call?pivots=platform-web :]
As i wrote in comments you can use Twilio or Plivo. I am using both, one as backup, as in my case I am using it for sms mainly, and if messages was not delivered with one carrier i will retry with other. Both works with Azure function.
As for twilio you can even have a look into AF binding but its only for sms.
Also other way of doing would using logic app. You could publish message to queue and then using connectors to do some stuff.
For instance plivo connector supports calls but twilio only sms
This is more of a design/architectural question
I know the question sounds vague but let me explain my applications need.
So I have a windows form which collects certain data from the local machine and sends it to an azure queue regularly. I also have a Web app which pulls data from the queue simultaneously and displays the data. All is well and good here as the web application works fine . But the web app only pulls data from the queue when I 'launch' it. Is there a way to run this task of processing the data every time ? (like as and when the data is available).
This is a requirement because along with displaying the data, the web app also monitors contents of this data for threshold limit and sends notifications too.
Right now, only if the web app is launched/opened on a client browser, it can send notifications.
you should take a look at SignalR. It is a library which is used for real time communication, there are a lot of strategy for making this real-time communication happen and SignalR implements for you.
It can be used easily with ASP.NET you should just take a look for some codes to know how to implement in your case but this is your game.
From the couple of suggestions, I found Azure WebJobs ideal for my task. A little more research shows Azure Worker Role to be useful too, but setting it up looks more difficult.
I want to create a cross platform chat app with backend in c#
I searched for an approach to do so and found that I can do so with http requests to handlers on my server and use the response accordingly.
So till now I made the handlers which can add users, login, send and receive messages using database for storage.
Now I am making android client for that and to get messages for user I need to do http requests at a specific interval (3 seconds).
I feel it is not a good approach to do this. I am making this app for a target audience of nearly 30000. They would be able to chat one on one at a single session.
I just want to know if I am going in right direction or There is far more better ways to make chat apps using backend.
I have heard about wcf but I am not clear with what approach should I take. Please guide me about approaches for chat application.
Edit
An example of little working of any famous chat app like whats app, facebook messenger would be a great help.
Thanks.
You could do it with HTTP, but I'd suggest using TCP instead. There's a very solid base for a C# based TCP server on codereview right here which will outline how to deal with Socket objects how to handle connections properly.
The main perk of going about it this way is that you can connect your client to the server, and the client can be virtually any language, it doesn't have to be C# - as long as the language supports sockets, you'll be fine.
On top of that you can have the client listen to the server, which removes the need of polling the server for new messages every couple of seconds; the client socket will receive data when the server sends it, and you can handle it right away, nearly in real-time, whereas if you'd poll the server for new messages over HTTP every - say 3 seconds - you'll always end up with a delay in your chat service, which is something I think you will want to avoid.
See the code sample on CodeReview I linked above, and read up on how Sockets work in C#, how TCP works in terms of guarantees (TCP guarantees that whatever is sent over it will end up on the other side in the same order, but not necessarily in one packet, etc) and I'm pretty confident you'll be able to make a excellent chat app if you put it all to good use.
Edit: I just noticed the WCF tag on your post. I'd personally steer clear of it for this specific project since you want to achieve cross-platform support; try going as low-level as you possibly can for that.
I have the following architecture for a project I'm working on.
My question is how to begin implementing the TCP/IP responder part.
It's function, in case the diagram is hard to read, is to wait for a connection from the Order Viewing client, and subsequently notify said client of incoming orders.
I was thinking a queue, but unfortunately I don't know where something like this would fit in the VS2008 hierarchy of things.
If it's part of the ASP.NET web page, should I use the application start event to start the TCP IP responder?
It's not a web service, because those respond to http requests...
If I had to implement your "TCP responder" I'd probably implement it as a windows service and have both the ASP.NET app and the Winform client contact it (e.g. to avoid the problem of recycling of the ASP.NET etc.)
That said, I can think of gazillion easier ways to get the effect you want to achieve (getting the winform client to know about new orders) such as
Using Queues as you mentioned. Windows comes with MSMQ (you need to enable it in add windows features). Using MSMQ from C# is fairly easy. You can also use WCF if you like
exposing an http endpoint on the client and have the client notify the ASP.NET server where it is listening by calling one of its pages
write the orders to the DB and poll it from the client/use System.Data.SqlClient.SqlDependency to know when there's a change
Heck even writing the orders to a file on a shared folder with a FileSystemWatcher would work (though I'd probably wouldn't recommend that)
Why don't you use http? You already have the http server so you don't need any TCP responder - just do http polling at the client.
And if you don't want polling or have too many clients then you can use something like SignalR for notifications.
I've inherited an ASP.NET website written in c# using an mssql 2k8 database that is sending emails based on an insert into a message table via a trigger using database mail :| One of any failures and too many things rollback, aren't logged and no email is sent...
What a mess. I've written a few email subsystems in the past and I thought I'd ask for input before starting a rewrite here. What are the best practices for queuing/sending email in a Microsoft environment? Should I be pushing emails to a queue, from there pulling, sending, logging? DB Email seems like a fail. Is the queue managed in SQL server? Does SQL Server call a C# app? If an email send fails, what's a good approach for recovery?
Thanks for any insight!
I think you are correct to completely separate the use of system functions: use SQL for data, and push email on to a completely different 'service provider'; I assume you have some sort of business logic tier that will orchestrate this?
I can't talk in terms of 'best practice' from experience (for email specifically), but abstracting out the email service (just like you'd abstract out data-access) is definitely on the right path, and that's probably the critical decision you need to make right now. You could then have different implementations of the email (including SQL, if you really wanted to).
Depending on volumes - do you look at an asynchronous call or synchronous call? WCF seems like a good candidate to handle comms - this would allow you to fire data (for emails) into an end-point that had a queue built into it, or you could call (via WCF) a web service that acted synchronously.
You can send mail via sql-server. For more refer this
The architecture of it is here
Another implementation of sending mail via c# is this as they have developed an email factory for implementation... hope this helps
sp_send_dbmail places the mail request into a queue in msdb. After the transaction that sent the mail commits, the queue activates an external process that handles the SMTP delivery, including retries, logging and all that. Overall system is quite resilient, scalable and performant.
Perhaps you're using the old, deprecated xp_sendmail based system?