I see that there were some plans in 2018 to add support, but it doesn't seem to have gone anywhere, and I cannot find any documentation for WebSockets with Foxx. I'm just wondering if there's any current support for WebSocket services.
Related
Is there service discovery (eureka), circuit breaker pattern (Hystrix), client side load-balancing (ribbon) and api gateway (Zuul) implementation available on NodeJS? I see nice integration of these components in Spring framework for Java but is anything such that available in NodeJS?
Netflix has provided an alternative way for non JVM languages through Prana (https://github.com/Netflix/Prana) but it is not actively supported. Is there any alternative suite of production ready components available for NodeJS? Ideally one of the benefit of micro services is each service can be developed in different language. Are there any good option available or should I implement myself?
I was about to use Strongloop for restructuring a Node.JS project when I saw that they are integrating Strongloop into IBM API Connect. The official page even points there.
However from a brief look at features, I saw that the IBM API gateway in contrast to Strongloop Arc (actually Strong Process manager) does not offer free clustering capabilities when deploying the program as PM did. It is mentioned as a paid feature...
I believe this is quite a setback, integrating a good product and limiting its open sourced services...
The API Gateway is different / separate from StrongPM and Arc in general. Some of the features previously available in Arc are now also part of API Connect's API Designer.
If you build an app on top of the LoopBack framework (which still is and should remain OSS), you can deploy that in whatever manner you wish with full clustering.
For example, you could deploy to Bluemix as a Node.js application and run multiple instances of your app for clustering / high-availability.
Or, you could deploy your application using StrongPM on your own hardware and get clustering that way.
If that doesn't answer your question, please clarify and I'll do what I can to provide updates.
Am I correct in the assumption that without access to the MongoDB server, there is not much point developing with Meteor?
Meteor is a great framework for building, packaging and deploy apps and sites. From a development POV, the templating and responsive DB work make prototyping so much easier than most MVC's.
I understand that underneath the hood, websockets and DDP provide the realtime sync'ing magic which means that you need access to the MongoDB server, something you don't have with PaaS solutions like GoogleAppEngine, Parse or Kinvey.
So, for the backend developer, they don't derive much benefit from Meteor since they need to maintain the server stack and scalability issues.
Is there a path to create and deploy products with Meteor without having to build and maintain the backend infrastructure? Heroku is still pretty close to the bone when it comes to managing infrastructure.
Wondering if there's a way to have CRUD operations through a REST driver that maps out to whatever PaaS you want and have the PaaS post log changes to a server that strictly handles websocket connections. Basically, pass the CRUD operation to a PaaS and maintain your own websocket server/s.
MeteorPedia has a page on deploying to PaaS: http://www.meteorpedia.com/read/Category:PaaS_providers
Recently, Google AppEngine has added support for custom VMs.
You can also use MongoHQ or similar for the database.
I got a server running SignalR and another server runing Node.js. I would like these two servers to communicate using SignalR. Is this possible?
I'm thinking I can use the SignalR client javascript library to connect to the SignalR server from Node:js but I can't find any good examples of how to do this.
Well the answer to can you do this is ultimately "yes" because there is nothing proprietary about SignalR communication. It's just variations of HTTP or WebSockets with a custom handshake/message framing protocol for Hubs on top of that.
So the how is the question we'd need to answer. Out of the box SignalR provides a client side JavaScript library based on the jQuery plug-in architecture, but that won't help Node.js. Someone has started a Node.js implementation here on GitHub, but according to the ReadMe it only supports HTTP long polling today. I'm unaware of any other implementations at this time, but obviously you start with that one and fork it to add support for the other transports if you wanted.
For a notification project, would like to push event notifications out. These are things like login, change in profile, etc., and to be displayed to the appropriate client. I would like to discuss some ideas on putting it together, and get some advice on the best approach.
I noticed here that changes made to a CouchDB can be detected with a _changes stream, picked up by Node, and a process kicks off. I would like to implement something like this (I'm using SQL Server, but an entry point at this level may not be the best solution).
Instead of following the CouchDB example (detecting database-based events, I think this just complicates things, since we're interested in client events), I was thinking that when an event occurs, such as a user login, then a message is sent to the Node server with some event details (RESTful request?). This message is then processed and broadcast to all connected clients; the appropriate client displays notification.
Proposed ecosystem:
.Net 4.0
IIS
IISNode
Socket.IO
Node.JS
SQL Server 2008
This will be built on top of an existing project using the .Net framework (IIS, etc.). Many of the clients' browsers do not support web sockets, so using Socket.IO is a good option (fallback support). However, from what I can see, Socket.IO only still only supports long polling through IISNode (which isn't really a problem).
An option would be to expose the Socket.IO/Node endpoint to all clients, so that client-based notifications can be sent through JS to the Node server, which broadcasts the message. (follows the basic chat-server /client/server examples).
Alternately, an IIS endpoint could be used, but could only support long polling (through Socket.IO). This would offer some additional .Net back-end processing, but may be over-complicating the architecture.
Is there SQL Server-based event notification available for Node?
What would be the best approach?
If I didn't get the terminology ecosystem configuration right, please clarify.
Thanks.
I would recommend you check out SignalR first before considering adding iisnode/node.js to the mix of technologies of your pre-existing ASP.NET application.
Regarding websockets, regardless if you use ASP.NET or node.js (socket.io), you can only use HTTP long polling for low latency notifications, as websockets are not supported by HTTP.SYS/IIS until Windows 8. iisnode does not currently support websockets (even on Windows 8), but such support could be added later.
I did some research lately regarding MSSQL access from node.js. There are a few OSS projects out there, some of them use native, platform-specific extensions, some attempt implementing TDS protocol purely in JavaScript. I am not aware of any that would enable you to access the SQL Notifications functionality. However, the MSSQL team itself is investing in a first class MSSQL driver for node.js, so this is something to keep an eye on going forward (https://github.com/tjanczuk/iisnode/issues/139).
If you plan to use SQL Notifications to support low latency notifications, I would strongly recommend starting with performance benchmarks that simulate the desired level of traffic at the SQL server level. SQL Notifications were meant primarily as a mechanism to help maintain in memory cache consistent with the content of the database, so it may or may not meet the requirements of your notification scenario. At the very minimum these measurements would help you start with a better design.
I would highly recommend using Pusher. That is what we use and it makes it easy to implement as it is a hosted solution. So plugging it and making it work is really easy. It doesn't cost much unless you are going to push a crazy amount of messages through it on a massive scale.