I am completely new to the concept of servers, web APIs and web applications. I have a project where I need to design a Web API that allows clients to modify a database (hidden from the clients through the API).
And there is also a web application which has some functionalities. The web application also has to interact with the database.
So my question is, should I develop the Web API (Server) and the web application in the same project or two different projects?
I chose to implement the system using Mean stack for learning purposes. Mean stands for MongoDB, ExpressJS, Angular and NodeJS. As the Mean stack contains technologies to develop both the API and the Web app, am I supposed to develop all the code within one project and deploy it in my server or separate the Web API and the web application into two projects?
If it depends on the scenario, then to which kind of scenarios should I choose each and what are their pros and cons?
If shortly, Web API, it's backend, it's service, which you use in web application, and, web application, it's frontend, it's web site, which you see in your browser.
You can create one repo at github but server-side and client-side projects are separated.
You can choose the structure of your server-side and client-side projects depending on the purpose of your project. If you are going to create web application and then to develop mobile application (with ionic, for example) you should create web API separately. If you are going to create only the web application and to deploy your web application and web API to the same service (like heroku) you can make the same structure as in the heroku example (https://devcenter.heroku.com/articles/mean-apps-restful-api , also check the repo of this example https://github.com/chrisckchang/mean-contactlist-angular2 ).
Related
When I have an ASP.NET web app with some API controllers that has a route /api for example, I can publish the app to Azure Web App and use the api by accessing someproject.azurewebsites.net/api/controller.
However, when I separate a web API part from the web app project, I have to publish the web API project to new domain like someapiproject.azurewebsites.net. I want to integrate the web API project to the web app just as I did with one combined project.
Is this possible?
If you want to combine multiple APIs, you should take a look at Azure API Management.
I doubt that you can publish multiple APIs into a single Web API since both requires a startup where you configure the host.
What you can do to cleanup your code is to outsource the controller into different assemblies and configure them in the middleware. Here is an example.
Martin Brandl's answer is spot on. But if you want to go the poor man's route, you can create a reverse proxy from your ASP.NET Web App and map app traffic from someproject.azurewebsites.net/apiV2 to someapiproject.azurewebsites.net. This is not a HTTP 30x redirect - the URL will not change for users hitting your /apiV2. I've personally used this approach because the Azure API Management service can get a little pricey. If you don't need the sexy features like throttling, this can be a good way to go.
I'm currently in the planning process for a mobile app I'd like to build, with a companion web app. The Mobile app and the Web app will share common data (for example, users can take a questionnaire in the mobile app or take the same questionnaire on the web app).
I've used Azure a couple of years ago to create and host a web app, but this is my first venture in mobile development. I'm trying to wrap my head around the architecture in Azure for hosting the API.
I've searched high and low, but either can't find a definitive answer to my question, or am not quite understanding what I am reading on the subject.
Basically: Where would my API live in Azure? Would I create a Mobile App in my App Service, which hosts the shared web API? Then create a Web App in the app service, and use something like RESTSharp to access the API from the web app?
AFAIK, Web Apps and Mobile Apps are just different types of Azure App Service Apps which use to host the relevant applications (e.g. WebApps host website,webapi and MobileApps serve as the mobile backend service). Basically, they are the same and the difference between them is the app type and the Quickstart tutorial for them.
For mobile development, you could leverage the relevant SDKs (server-side and client-side) provided by Mobile Apps. You could also deploy your mobile backend application to Azure Web Apps to get the Mobile Functionality.
For Web Apps, you could follow here to build your web application and deploy to web app. For Mobile Apps, you could follow here to build your mobile backend and the tutorials for building your mobile client project.
Basically: Where would my API live in Azure? Would I create a Mobile App in my App Service, which hosts the shared web API? Then create a Web App in the app service, and use something like RESTSharp to access the API from the web app?
AFAIK, for Azure Mobile Apps backend, you could choose Node.js or C#. The relevant server SDKs provide out-of-the-box CRUD operations against the table. I would use the Mobile Apps SDKs to build my backend project and provide the ability to do operations on the specific table and the custom Web API to handle other operations. For your web app, you could use RESTSharp or just leverage the client SDKs provided by Azure Mobile Apps to communicate with your mobile backend endpoint (hosting on a web app or a mobile app).
For C# mobile app backend and mobile client side tutorials, you could follow adrian hall's book here.
For Node.js related mobile backend development, you could follow 30 DAYS OF AZURE MOBILE APPS.
I am relatively new at configuring IIS and am wondering if the following scenario is possible.
My application consists of 2 Web apps. 1 is an ASP.NET Core App that hosts a Javascript SPA. I have a second MVC App that is a combined Authorization Server using OpenIddict and the main API that the SPA talks to.
On my dev machine these 2 apps run on different ports.
These 2 apps go together to make our solution for any given customer. I can get this all working on IIS treating each app as it's own website with it's own port.
But I would like to be able to bundle these 2 apps under 1 website. Ultimately we will have several customer websites and each "website" really consists of these 2 apps bundled together.
I understand that I can create a single website and then convert my 2 existing sites to a web application. So 2 web apps sit under the main web site. But these all will run under the same port.
I would really like my API and Authserver to run on a different port. Is there a way to each this type of scenario?
What is the recommended best practice for what I am describing?
I do not want the API / Auth Server project to be shared by all the customer sites. I want each customer site to have it's own instance of the Authorization server and API.
It would be great if you could create 2 websites and then sort of group them into a parent website container (if that makes any sense).
You can create two applications within your website on IIS. Then each application would be accessed as http://customerwebsite/app1 and http://customerwebsite/app2
I am in the process of building a Web based client for a Server application which is running as a Windows Service. The server application currently has a Windows Form based Client Application written in C# and the idea is to obsolete it and provide a new Web based Client Application. The Server application will be exposing REST based APIs and the Client Application would be using the REST APIs to communicate with the Server Application. (Currently the Server App exposes SOAP based endpoints which are consumed by the Windows Form Based App)
The Browser based client application would be written using Angular JS. The Client Application would be used by at max 10 concurrent users. The App is targeted for system administrators and would be used inside the enterprise environment.
Another requirement is to integrate Active Directory Authentication for the Client Application. So given the performance requirement and authentication requirements, I am wondering whether I should use IIS for hosting the Web Application. Or should I just use the existing Server to self host the web pages.
If at all I go with Self Hosting option, would Katana Self host be a good option? Or should i use WCF Rest kit to serve the pages?
What are the performance implications of using a Self Hosted mechanism for hosing the Web Application compared to IIS?
Any suggestion would be greatly appreciated.
WCF REST Starter kit is still in second preview 2 version from 2009 so I'd be pushed to recommend using it.
The question of IIS or self host depends, do you need the features that IIS has out of the box like logging, restart after failure, etc?
My suggestion would be to use ASP.NET Web API (or Nancy, which is an excellent choice too) but keep your hosting layer separate from your application layer so you have the flexibility to decide how you host your service later on.
The second suggestion is performance test early on, pick a hosting mechanism and measure how the service copes under load - you may find out that you're worrying about something that you don't need to.
I'm fooling around with a WebAPI application I've developed in two solutions: one solution is the WebAPI / serverside solution with db access using SQL server, the other is a durandalJS client application. I have the WebAPI bits hosted in an Azure Website right now, but I'm not sure where to put the client solution.
Should I throw it in its own website and just have it make requests within azure across to the other website? I want to avoid putting them in the same solution because I would eventually like to practice load balancing the front-ends when I have more dough to play with.
Idea of cloud like Azure is pay as you go. If you do not have the volume currently to load-balance, why create two websites and pay for them both regardless of the usage? You can have just one web site and host both the web application and web API. In the future, if you want to separate out API piece and load balance web app, you can do that when you have the volume. For this approach to work, structure the solution like this. The Web API piece will be just an assembly which you can reference in the Web application itself and host it in the same web site as the web application. In future, if you want to separate out, create a new empty ASP.NET Web application and host the Web API referencing your Web API core assembly.