Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.
Related
I am currently looking at using Microsoft Web Chat to interact with my existing Node Js application built on MS Bot Framework Core but uses DialogFlow as NLU.
Current implementation: Web Page -> Custom UI Widget -> Connects to Node.js app built on MS Botframework Core -> Queries DialogFlow NLU to identify Intent -> Node.js app constructs the Dialog -> Gives response to user.
Looking at the Web Chat component, I cannot find references using any other NLU except Azure Bot Service. Is it mandatory to use Azure Bot Service/LUIS NLU to integrate with Web Chat?
I have also looked at offline-directline npm module but the last dev on the module is more than 3 years ago.
Firstly, responding with a quick message about using offline-directline, you should feel reasonably comfortable with it. It is a few years old, but seems to stand the test of time with continued use and little in the way of issues that I have heard.
Another option would be to use a 'browser bot'. In this scenario, the bot is contained within the hosting page's html/scripts. So, there is no reliance on using Direct Line. I don't know your whole setup, so this may or may not align with your overall needs and architecture.
As for using Web Chat with something other than the Azure Bot Service, this would be an uphill battle. In theory, this is probably achievable to some degree. The issue is that Web Chat is heavily integrated with the BotFramework-DirectLineJS library. You might be able to cherry pick specific components from Web Chat, replace the Direct Line library with a make of your own, and modify the remaining code to work with your 'service'. But, I'm not certain the effort is worth it. That is something you would have to decide for yourself.
If you do go this direction, you will likely need to configure your 'service' to send messages that conform to the BotFramework schemas when communicating with Web Chat. Even without the dependency on Direct Line for connecting to the service, much of Web Chat is still oriented towards what an incoming message looks like (i.e. a BotFramework Activity) and handling it according to the properties it contains.
To start, here are a few areas you should review in order to correctly configure you service to handle inbound and outbound messages going to and coming from Web Chat:
BotFramework Activity schema
BotFramework Card schema
BotFramework Transcript schema
Web Chat's Activity, Card, Attachments, etc. Types - at present, these are loosely defined. I would expect that to change at some point in the future which may prove to be a changing break in your specific scenario.
This is not exhaustive and would require greater research as there are likely other considerations than the few I've listed above. But, again, this may not be necessary if you decide to utilize offline-directline.
So far I've been developing applications where I included services for both web and mobile applications in the single spring boot application where I've used different packages for different clients. But here The problems I faced are like, Since both clients are pointing to the same app in same server, Maintenance became difficult for me for e.g. When I update any service in Mobile part, whole code has deployed and things like this.
I do know it's more generic question.
But here the point in my question is, Is it really a good practice to provide APIs for both web and mobile client from the single application in the Server? Suggest me some good references
TL;DR is, as usual, "it depends" - on size, complexity, team structure and other factors.
Keep going with everything in a single project until a compelling reason to do otherwise emerges.
I'm contemplating to use Parse as a platform for my app, as I'm trying to avoid creating and managing the cloud infrastructure myself.
For the sake of simplicity let's say that my app will hook into an Exchange Server and will need to leverage some hosted Machine Learning service to categorize my e-mail and report on insights found.
I'm assuming that Parse would store my core data, while the hosted ML will store the "Big Data" associated with processing for insights.
I'm also expecting my app to receive push notifications generated by the hosted ML service.
Does this sound like a plausible way to go about it and leverage Parse, or am I better off developing the backend myself?
I think parse.com is the right place for you requirements, because they have everything you need like storage of core data, push notifications, cloud module which can be integrated with heroku, social integration, user management functionalities.
They also have large set of client libraries for desktop and mobile apps (node,java,.net etc...) also they have libraries of embedded devices.
The biggest advantage is that everything is setup, and you are focused on software development not on infrastructure things. This is my opinion.
I've been experimenting with the above stack and so far was really impressed. Seems like a viable path forward. The Cloud Code capability of Parse is very solid, and easy to work with. If you want to run services outside of Parse code this us also possible : just issue REST calls.
Summary: My task is to decide how the user authentication should be implemented for the cloud-based project that should be evolved from the older WebForms application. I am at the beginning of the decision process, but I have to decide soon; so, I will appreciate your experience.
Why WebForms? The application is based on the older WebForms code, this way it should start from the WebForms code. The problem is that the application should be ready rather quickly, so the code must be reused as much as possible. Also, we do not have developers that have working knowledge with MVC. Some trade-offs are necessary. However, the log-in process will be new, and it can be implemented using the MVC approach.
What is new: The older code was built to run on the intranet web server, the users signed-in using simple login names. Security things were not that complex. The application uses the pre-ASP.NET Identity -- really old, and that part of the application should be replaced. There will be more groups of users that should work in the separate workspace (think of companies).
New acount -- authentication: The user should use valid e-mail address to ask for registration. For the new user, the e-mail should be validated as existing, and then it should be approved by the administrator dedicated for the group.
Authorization: A user will be allowed to work only with some data. Think in terms of using a single database where the user of one group should be allowed to access only the part dedicated to the group. However, there may be power users that may have more rights.
Should I focus on using ASP.NET Identity? If yes, (not being dependent on the older versions) should I start with ASP.NET Identity 3 that is currently in 3.0.0-beta7 (see https://github.com/aspnet/Identity.git), or should I stick with version 2?
ASP.NET Identity is Microsoft's main thrust for identity and membership and their newest identity library. If you are concerned about continued support then this is the library for you.
The ASP.NET Identity library supports your need for claims based authorization (in your case using roles/groups) and recording email addresses confirmation. This is available out of the box.
I would not recommend using ASP.NET Identity 3 however, as this is designed with ASP.NET vNext in mind, not something you want to do with your legacy system.
Stick with ASP.NET Identity v2.x
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck