I have a public API (Asp.Net WebAPI), where all calls start with the the url: /api/callName.
I have a second website that is the actual public MVC website.
I would like both of the above to be hosted on separate servers.
http://mywebsite:80/main/page1 should open my actual website, hosted on server 1.
http://mywebsite:80/api/call1 should open my API website, hosted on server 2.
Is this possible????
Try to play around with IIS Web Farm and load distribution algorithms. So, one of the solutions: set up web farm, use load distribution in a manner when server1's weight is 100 for http://mywebsite:80/main/page1 , while server2's weight is 0 for the same request and vice versa for http://mywebsite:80/api/call1
Related
I am new to backend world, currently I am very confused with these concept relationships and really need some help here.
So currently I already have an iOS app and backend server(using python, hosting at AWS) ready. Now I need to register a new domain name and build a basic website to explain and promote my app.
Let's assume I am using goDaddy to register a domain name as "hello.com", now I have my basic website ready as well, I guess I need to upload html files to goDaddy hosting server then the website should be able to run, but then how can I link it to our python server?
For example, in the iOS code when I am sending a http request, I will need to send it to "https://hello.com/api/xxx", correct? Please correct me if I am wrong.
You should use subdomains for the different servers:
www.hello.com = your static website hosted on Godaddy or wherever
api.hello.com = your Python api server
etc...
To make this work you would just edit your DNS zone on Godaddy (or wherever you have your domain hosted) and create a record for "www" that points to your website server and a record for "api" that points to your API server.
With our company, we sell a service to our customers,
this is a website which let customers enter some parameters and informations, and then, they can query a web service to get
the previous informations computed. These web sites are hosted on our servers.
We would have on our servers one database per client (dbo.Client1, dbo.Client2...) with the same schema.
And we would like to provide a different url for each client :
expl :
www.client1.service.com www.client1.ws.com/compute
www.client2.service.com www.client2.ws.com/compute
But i'm wondering how to deploy easily the web services and the web site?
Do i have to deploy one web service and one website per client (with different web config)?
And maybe create multiple deployment scripts ?
Or is it possible to imagine one instance of each (web service and web site), listening on several addresses, and creating different
connection string according to the entry point of the request (is it even possible with MVC or WCF ?)
Any other idea ?
I don't know what is the best practice here.
Thank you.
if anybody read that question one day, i solve my problem using multi-tenant solution, which allow me to deploy only one instance of the site.
The site handle the webrequest, and according to the host, connect to different database.
I have a webapp running as an Azure website on http://www.example.com
I have controllers for www.example.com/signup and www.example.com/signin - all other stuff is put on subdomains, like username.example.com.
My question: is it possible to have another (azure) website running on http://www.example.com? E.g. with all the marketing pages etc.
Ideally I would like to give access to that second website to an external webdeveloper so that I don't have to worry that the webdeveloper have access to my main app.
Additional question: would that second website have to be asp.net? Could it be PHP? (e.g. a Wordpress site)
You can develop child projects within Azure Websites check here : A single web project hosting both the web pages and API
One web project for the web pages, and another for the API, deployed to different websites on different servers
One web project for the web pages, and another for the API that is deployed to the same servers as an IIS application (/Services). http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx, not sure if it can use another platform.
I'm working on a project that involves two web portals hosted on the same IIS 7.5 server:
(A) MVC4 web application for administration
(B) Mobile MVC4 web application with jQuery Mobile
Both are retrieving the data from the Web API based services hosted on other IIS server.
Now I'm about to add manipulation of images that are managed on Admin portal (A) and displayed to clients within Mobile app (B). Images will be added/changed dynamically with higher frequency.
I had two solutions in my mind:
Store all images in database on the server that hosts Web API as byte arrays, and send them on demand as base64 strings - render them on mobile app pages as base64 strings:
Can set any kind of security restrictions and integrate them well with MVC
Pages would be rendered in one request
Transferring from Web API to Mobile app
What happens to caching?
Store all images on the server that hosts both (A) and (B) in some shared folder, include them in rendered pages as regular tags.
No transfer between WebAPI and Web server
Caching of images
Several requests for each image on the page
Thing that I have to take in consideration as well is that there will be native iPhone app that will do the same role as mobile web app, meaning it should have access to same set of images.
Any thoughts would be appreciated on this, I'm looking for best practices solution, a guide, hints, or anything that I could use.
Also, if option 2. is suggested, what is the best place to store images to be shared between two portals?
Thanks!
I would recommend you going with option 2 and store the images on some shared folder. The best would be to have a specific application that will act as CDN hosting all your static resources. According to YSlow best practices this CDN should be hosted on a different top level domain than the clients, thus allowing cookieless access to those lowering the bandwidth consumption.
We have a few 'classic asp' client facing websites feeding off a central asp.net mvc site which acts as a webservice ie we query the MVC controllers directly from the ASP sites with extensive use of jquery ajax. This MVC site in turn queries sql server running on a seperate box. We have a custom session profile which requires a call to the database on every page view.
At the moment the client facing websites sit on the same box as the mvc site. We now want to use Windows 2008 network load balancing service to both contain high bursts of traffic and maintain availabilty. Within a currently limited budget...
What is the best policy: 2x2 - client sites on 2 NLBed boxes & MVC on seperate pair of NLBed boxes- or both on a single group of 3 NLBed boxes?
I would go with the 2x2 solution just to help keep those MVC sites away from the Web. If you do not need the MVCs kept away from the web then go with 2 or 3 NLB'd boxes.
Be aware that NLB is a IP to IP load-balancing solution so if you are funneled through a single connection it will end up always going to the same server and you really just get Fail over.