I am developing a prototype app/website as a 'spike' for a project feasibility study. We need both a website and an app.
I have come from a web forms/c# background with fair amount of sql experience.. and have been up a steep learning curve to get to grips with MVC, Entity framework etc.
I have developed an MVC app first which has OAuth and uses Asp.Identity (and roles - just couldn't stay away im afraid:).
This uses an Azure Website and Webjobs to handle other tasks.. I really like the idea of not having to manage the whole server.
Following what seems the logical step for a mobile app, I have also added Web Api to it.. and have done some successful checks that it is there and working using fiddler etc.
I now need to 'Spike' the mobile element of this and quite favour the Cordova approach since there are no real performance requirements and it looks like AngularJS etc can yield good gains. So I have added the Cordova tools to my dev environment and done a couple of the tutorials and successfully have an app on my android phone.. so far so good.
So looking at Azure Mobile services, this seems to offer some nice facilities for our app.. however, and I realise it is still new, but it does seem geared to wards a Node-JS 'server side' application if using Cordova.. is this fixed or am I OK using C#?
But also I feel I may have circumvented the need for the Mobile services part by adding WebApi..
On the surface it looks like the mobile services is a great 'cloud as service' model for simple app only requirements. Or am I wrong .. and should I be using it IN ADDITION to my website..
The APP and Website are going to use the same database, authentication etc. Which brings me on to the database.. This is not really an 'existing database' (which is where all the tutorials for Mobile Services seem to head).. I can start again if needed.. but of course it is built with code first EF models.
Should I divert energies to using mobile services or, as I am suspecting, carry on developing my own RESTful apis added on to my website.?
I guess I am looking for some best practice guidance here.
the .NET backend for Mobile Services is actually WebAPI based and is actually geared towards dev's who want to take advantage of their existing .NET/WebAPI skills in writing the backend services as compared to the Portal-based JS backend (you can also write more complex code the JS backend).
A key thing to note about Mobile Services is that it's a collection services, not just a backend to your data store.
You have authentication, push notifications, offline support, hybrid connect, etc... on the backend and corresponding client libraries for most mobile platforms (note, since it's REST based, there's not stopping you from consuming the same services from non-mobile platforms such as WPF, ASP.NET MVC, etc..)
So the question is, how much of the other features do you actually need and how much effort is it for you to write them yourself vs simply consuming/configuring them in Mobile Services.
I will answer your overly complex question with a overly simple answer: Mobile Services were designed for mobile devs with no or little experience developing a backend to use a backend with services for their mobile apps. If you're an experienced backend developer, you can do the same from scratch.
Related
There is a project I am working on using asp.netcore 3.1. d app is a web API and will b consumed by multiple clients(web browser, android and Windows forms). How can I build the OAuth2 server in c# to protect my API.
Most companies don't build their own Authorization Server, since it is a job for security experts. Instead they use a cloud provider, and these are often very low cost or free.
In the early days this is a good learning guide and will save you a lot of time. You can then focus on OAuth integration into your UIs and APIs.
As long as you keep security in your UI and API standards based you will then be able to easily swap between providers later - or use an open source one perhaps.
Here are a couple of resources of mine that you might find useful. My early code is in NodeJS, but based on OAuth messages, so easily translatable to .Net Core:
Setting up an Authorization Server
Initial Tutorial
OAuth Messages - see Step 16 for API Integration
I've got a stand alone WCF service providing REST services. As time goes on, I'm feeling like MS is going to reduce support for WCF and REST services, and I've already had to code in a bunch of hacks to get somethings working like CORS. Additionally, implementing https is another hack since it requires using OS functionality. (i.e. you have to install the certificate using an external application, which doesnt' make the service very self contained)
In anycase, I'm considering either a move to ASP.NET REST API and OWIN, or Java/Spring. I wanted to first see what it would take to move to ASP.NET REST, since I figured that should take the smallest amount of work, but I haven't found any good examples.
There's a pretty straightforward example on the asp.net site.
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
setup a self-contained project i.e console app or windows service
initialise and setup you routes
create your Controller / API stubs
deploy
Regarding SSL, whether it's IIS or Apache you will have to configure it on the web server regardless.
I am hoping someone can clear up how these things can work together.
I want to be my own identity provider, so in my web api I have an OAuth token provider. I want users to register with me and then be authenticated using my token provider. The idea in the future is that more of my mobile apps and web apps will be accessible using the OAuth login sharing the user's identity.
So, if I use azure mobile services how do I implement the normal asp.net identity stuff?
And, how would a normal web app be able to use the data stored in azure mobile services? Would I have two dbcontexts one for mobile and one for web?
I've been reading and watching a lot of stuff on azure but nothing seems to show how I can do this. Most of it has to do with using external providers like facebook, ms, twitter, etc. I want to be one of those external providers, just not sure how to do it and allow my websites to still use the .net identity data.
If you could point me to or post some example / tutorial / blogs that would be great.
This is a supported scenario, although it isn't documented very well at the moment.
The Mobile Services .NET runtime is built on the ASP.NET Katana authentication middleware. The mobile service abstracts these middleware using the LoginProvider base class. The authentication model was recently made extensible for situations such as yours. In order to have Mobile Services recognize and use your identity provider, you would have to create your own LoginProvider.
There are currently two examples of this:
Adding a Katana middleware as an identity provider - part of this post.
Creating a custom username/password setup - tutorial here.
You could certainly use these techniques to wrap the standard ASP.NET identity functionality.
As to your question about accessing the data, there are a variety of approaches. Your web app could treat Mobile Services as a backend and pass through requests. This is basically treating the web app as an additional client platform, peer to your mobile apps. Another option is to, as you said, create multiple DBContexts. While you might get slightly better performance, this comes with a code maintainability tradeoff. It also wouldn't scale well if you build multiple web apps on the same data backend.
I am developing an android application to accommodate some desktop software that I created. I would like for the user of the mobile app to have to verify their identity through authentication. Basically the web service will have to act as a central hub to both authenticate and hold information that the android app will need. The way I think it should work is to
-Set up a central web service
-Allow user to create account from desktop client using email/password
-The desktop client will send the information to the webservice that the android app will need.
-when android app is authenticated it will then retrieve the data it needs that was posted from the client.
So basically the service will need to be able to send and receive data.
I will only be using .net (either C# or vb.net ) for the service, so this leads me to a couple of questions:
Should I be using WCF for this? If so should I create a WCF Service library or WCF Service application?
Should I be using the Sign Sign on service approach?
The web service doesn't need to be fancy it just needs to get the job done. Is their any boilerplate project templates or projects out their I could use to help build a foundation?
I recently discovered SudzC.com which generates classes and methods for Objective-C from the wsdl data of a .net web service, and I'm fairly sure it also does Android.
I have a huge catalog of fairly 'old' web services which pre-date WCF and they are currently working perfectly.
I should point out though that the SudzC service only shows you what it can do for you for free - to get the code you have to pay ~£20 for a one year pass.
We had something similar where I worked. We had to put together an Android app for the company. If you are on .net 4.0 or newer, you can take advantage of theWebApi. It can return json or xml. So, that means any platform can utilize it (desktiop, android, etc...). I found it extremely easy to use, with very little overhead.
I'm just starting a project where I would like to use Kendo UI (based on jquery) with C#. A few weeks ago I was successful in handling requests using Web Services (asmx), was pleased with the results and performance, and was able to create forms quickly.
Since this is a new project, I thought I could look into different concepts such as MVC and WebApi. I found MVC to be the most complicaded so I went for WebApi and started playing with controllers and requests. So far what I'm finding (don't judge me, I'm new to these new concepts), is that Web Service seems to be simpler and more flexible.
So I guess what I'm looking for is... what are the main advantages of using MVC vs WebApi and even vs Web Services. Are there any downsides to Web Services? Would it be a bad practice to have my data layer controlled by Entity Framework, all models defined, and my requests handled by Web Services?
Any clarifications are welcome. Thank you.
In a broader sense, Web API is used to create Web Services ! It uses HTTP as its standard for creating services (instead of SOAP like in asmx) as its more open and any type of client like a mobile app, desktop app, web app etc will understand HTTP protocol. Another advantage is that u can easily use JavaScript/jQuery to communicate with your Web API. With SOAP web services, its a nightmare!
Kendo UI and Web API is a great combination. We have recently created a mobile iPad app using this combination and it worked like a charm. We also used Entity Framework with oracle as back end DB and it never gave any issues.
Webservices are nice if you have the need for it. A need as in needing that logic/data in more than one different type of application (such as web, and a mobile app, and a desktop app). (Or if you want to sell the service you're providing)
Using a webservice for ONLY a website which you don't except to expand to other things is complete overkill.
Furthermore, the MVC framework and the Web Api framework are pretty similar except web api is used exclusively for webservices. Coding in both of them will be the difference between white bread and wheat bread.