I think the way forward for my future projects is Meteor\Anguar2 but prefer to stay with dotnet server as i already have alot of logic and some of the functionaility that dotnet provides can not be replaced. eg Windows Workflow,DevExpress Reporting etc
Is Meteor\Anguar2 frontend and dotnet server possible?
That depends on what you’re trying to achieve. Do you want your meteor app to serve up data from your dotnet backend? In that case you’ll likely have to write custom integration between what you have and Meteor.
The most straightforward way of exposing data to Meteor would be through the DDP protocol (see here).
Also, look into the Node.js utilities in Visual Studio. I haven’t done .NET for about 6 years now, but I hear that Visual Studio supports Node nowadays. Presumably, it’s possible to have the .NET libraries and V8 engine both running on your Window’s server. Also, if you can find a Mongo driver to connect to Windows Workflow, DevExpress, etc… that could be a winner.
Yes it is possible. Have your Meteor app use Meteor Methods to call .NET api end points. .NET then saves data to MongoDB.
Meteor will automatically sniff out changes using the Oplog and update the UI for you.
Keep in mind you lose one of Meteor’s benefits: optimistic UI.
We have a project we wish to migrate to Meteor but the server has business logic we cannot easily remove and how would we do this in javascript anyway.
Yeah, so if your .NET server logic can do it’s thing and write to MongoDB you’re golden. Meteor will pickup data changes for you, automatically.
wow…monodb looks awesome, i have only ever used sql server but my mind is starting to wonder if i should be using it…
it’s possible, but the question is, is it a good idea?
I’d say no. You can use Angular2 with .NET and that’s 80% of what you want
You can then use SignalR ( http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr ) to do the reactive bit.
Not quite as elegant as full Meteor, but this scenario is not going to be elegant.
Your other option is to use Mongo as a bridge between your systems. That can work nicely, but you really need to question whether its worth it.
Also if you are coming from SQL to Mongo for the first time, it’s going to take a while to grok mongo. There’s some things that become really easy, but at the same time, some things become quite hard ( perhaps not ‘hard’ but you need some experience to understand how to design certain things that are easy to do in a relational world )