I have an MVC web app that uses a jquery web request to generate the users notifications in a perceived async way. The notifications are built on request by each user on the site.
However I have been asked to make the notifications readily available as the happen.
This I would traditionally do using a windows service that called the same web method over http. I was thinking that this might be a good candidate functionality for using node.js
Is the any example code to call a http method in a loop and would that scale well ?
found this package and seems to do what i needed
https://npmjs.org/package/node-cron-jobs
I also came across "forever" to run node as a child process that can be re-spawned if there are errors
If you're already running on ASP.NET MVC take a look at SignalR. This was written by Microsoft, is supported by them and provides functionality similar to the Socket.IO, node.js stack.
Related
In my job we are building Web Apps that rely on a common Enterprise class. This class has a method that sends a request to our server every time the app_start or app_end event triggers so we can monitor the status remotely. But we are now requiring that at least once a day the web app reports its status, a bit like telemetry. I don't know how to accomplish this, so far I have found some options, but some have limitations:
Use hangfire. I don't like this since it requires to setup a Database or add more tables and install a new Nuget package on each project, but could be my last option.
Use a Windows Service that reads databases. This could be less work but it can't access the Web App web.config code
Use a Javascript tasks that sends an AJAX request. This requires to have an open web browser and is a big risk.
I'm looking for a server side approach that could allow to set to trigger an event or function at 1am.
I would got with Hangifire.
It is dead easy to setup and very reliable.
You don't need to setup the database, you might want to check memory storage:
https://github.com/perrich/Hangfire.MemoryStorage
Also check:
What is the equivalent to CRON jobs in ASP.NET? - C#
You can use FluentScheduler instead of Hangfire (it is more lightweight).
Instead of a Javascript task that sends an AJAX request you can use a WebJob or an Azure Function.
I am working on an ASP.NET MVC 5 application (based on nopCommerce). I want to use MassTransit to communicate with another application that is used for inventory management, billing, etc. It would be easier if I could add receive endpoints directly into the web application and not have to create a Windows service for that. But the MassTransit documentation says it is not recommended and there is no explanation as to why that is.
MassTransit in a web application
Configuring a bus in a web site is typically done to publish events,
send commands, as well as engage in request/response conversations.
Hosting receive endpoints and persistent consumers is not recommended
(use a service as shown above).
Does anyone know the reasoning behind it? Is it not safe to add receive endpoints in a web application? Will they not work properly?
Hosting endpoints in a web application is not recommended because web applications often restart for various reasons. These reasons are typically outside the control of the application itself.
While using a standalone Windows service is highly recommended, as long as the bus is properly started and stopped using the Application_Start and Application_End methods, it can be okay if you have no other options available.
I am working on a chat service with some unique features in it, and thinking about a server to dispatch messages and do all the IM-related stuff. First-priority client is going to be for iOS, built with Swift.
Is it feasible to create server, based on NodeJS Express, or may be Loopback? I have had a look at multiple choices, including ready solutions, like QuickBlox, Parse.
As for creating it from scratch, I think about NodeJS or Erlang.
At what stage should I make a decision so that not to waste too much time on reconfiguring everything for scaling and rapidity and convenience of development?
With technologies like Socket.io, Node.js, and Express, you could make a chat application fairly quickly.
Sockets are typically the best solution and the most common route to implementing a chat system, as they provide two way communication between the client and the server.
You could use practically any backend for a socket server, but it may end up being quicker to use Node.js and socket.io depending on your comfortability level with JavaScript.
All you would need is a socket compatible server and a client side library that connects to a socket server - there are plenty of JavaScript libs out there, including a socket.io-client.
Check out socket.io's chat demo on their site for a quick look at how it works:
http://socket.io/demos/chat/
They even provide a first party iOS Swift client:
https://github.com/socketio/socket.io-client-swift
Personally I recommend you to checkout SailsJS, a great framework for building API & chat server at the same time. It adopts socket.io internally so every route in a Sails app is compatible with socket.io (in other words, you can decide to call an API request via Socket anytime you wish!)
I've built a complete, working iOS App having chat feature. Its backend was completely developed using SailsJS. It saved me hundreds of hours. Sails documentation also mentions about scaling for production. Please have a look at http://sailsjs.org
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.
I have some delphi code which, given a list of items, calculates the total price taking into account any special deals that might apply.
This code is non-trivial to rewrite in another language.
How should I set it up to communicate with a website running on the same server? The website will need to ask it for a price every time the user updates their shopping cart. It's possible that there will be multiple concurrent requests.
The delphi code needs to maintain an in-memory list of special deals, periodically refreshed from a database. So it cannot simply be executed every time or anything as simple as that.
I don't know what the website is written in, or even which http server it runs under, so I'm just looking for ideas or standard methods.
It sounds like the win32 app is already running as a Windows Service on the box. So, if you can't modify that service, you are going to have to deal with whatever way it wants to accept and respond to requests. This could be through sockets or some higher level communication protocol like web services.
You could do a couple of things. Write an assembly that knows how to communicate with the service and have your web site use that assembly. Or you could build a shim service that knows how to communicate with the legacy service, but exposes communication over higher level protocols such as web services. Either way will have the benefit of hiding the concurrency, threading and communications issue behind an easy to call interface, but the latter will make communicating with the service easier for everyone going forward.
If you can modify the delphi app to take an XML request and respond with an XML answer over a TCP socket (ideally using the HTTP protocol), you will be able to make it interoperate with most web server frameworks relatively easily. But the exact details of how to make that integration happen will depend on the language/framework it was written in.
If the web server is on windows you can compile your delphi app as a DLL that can return XML or HTML, taking parameters as part of the URL or a POST operation. Some details on making a Delphi DLL for web servers are here.
It doesn't matter what web server or OS the existing system is running under. What matters is what you want YOUR code to run under. If it is windows then the easiest solution would be to use WebBroker and write a custom ISAPI application, or use SOAP to expose web services. The first method could be used if you wanted to write a rest like API for instance, the second if your web application has the ability to consume web services.
Another option, if you are running both on the same box under IIS, is to create a COM/Automation object which you then invoke via server side scripting (ASP). If the application is an ASP.NET application, then I would use PRISM to port your code into an assembly.
I have done this with a quite complicated workers compensation calculator. I created a windows service using RemObjects Sdk. The calculations are exposed as a soap method so it can be accessed by nearly anything.
It's not necessary to use RemObjects in the service but it makes it much easier to do as it handles a lot of the underlying plumbing. The clients don't need RemObjects, they just need to be able to call soap methods. Nearly any programming langugae can do that.
You could also create an isapi dll for IIS that exposes a soap interface. This would be useful if other websites on different servers needed access to the methods. However I have handled this in my case by opening a port in the firewall to access my windows service.
There is a lot of examples on the web. A couple of places to start reading are About.Com and Dr Bob.
Torn this app into Windows Service. Write Web Service that will communicate with your windows service. You should spend some time designing your Web Service, because this Web Service is going to be your consistent interface, shielding old Delphi app. So in the future whenever you will want to write web app, mobile app, or whatever you will imagine, you will have one consistent interface – XML Web Service.
A popular way to integrate a web application with background services is a message broker.
The message flow would be:
the web application sends a "calculation request" message to a message destination on the message broker, which contains all needed parameters and also a correlation id to match the calculation request with the response from the Delphi service
one (or, in a high availability / load balanced environment more) Delphi services handle the messages: pull the next incoming message, process it by feeding the parameters to the calculation engine, and send a "calculation result message" back to the web server
the web server can either synchronously wait for the response (and discard responses which have no matching correlation ide) and build the result HTML document, or continue with other tasks and asynchronously receive the calculation result in a separate thread, for example in a Ajax based web application
See for an introduction this slideshow about the Dopplr image service:
http://de.slideshare.net/carsonified/dopplr-its-made-of-messages-matt-biddulph-presentation
If you can make it a service (but not a library), you have to do inter-process communication somehow - there are a few ways to do this on Windows:
Sockets directly which is hardest since you have to do marshalling/auth yourself
Shared Memory (yuck!)
RPC which works great but isn't trivial
DCOM which is easier but a pain to configure
WCF - but can you call it from your Windows Service written in Delphi?