I currently have a ASP.NET MVC 2 web application and would like to enhance the architecture to support a SAAS model. I plan on eventually building a number of web applications so would like to design the system accordingly.
The goal would be that when a client would hit the following url clientxyz.domain.com they would see an image of all their subscribed applications. This would essentially be a web page with a bunch of application icons. Once a client would click on a icon it would navigate to that actual web app at the following example url clientxyz.domain.com/application_name.
We currently use GoDaddy to host our domain and plan on using a Cloud based iLand server to host our application. We only plan on a few new clients a year due to the nature of our software.
I have a number of questions:
Is it possible to programmatically create subdomains on the fly using a .Net api. I'm pretty sure GoDaddy does not let you do it. So is there another provider that would let me create subdomains via C#. This may be the wrong approach and may not even need to physically create client subdomains. Instead I may be able to accomplish this using url rewriting in IIS/MVC?? If I use rewriting, it would have to satisfy the url requirements mentioned above. Any suggestions/links/examples?
Should I create a separate IIS website for each tenant/client? Or should I use URL rewriting and simply have a single website / application pool? Looks like you can programmatically spin up IIS websites (example: http://www.eggheadcafe.com/tutorials/csharp/d4bba585-b517-4834-8476-ff05b085d86e/iis--create-app-pools-virtual-directories-and-web-sites-c-net.aspx)
Since we are using a Virtual Server on iLand do I simply have to point GoDaddy to the nameserver at iLand.
I would like to automate the entire new client process if possible. To accomplish this, I would have to created the database (probably going to have single db per tenant), populate the global client/tenant table, create admin user account and subscription details in newly created database and create subdomain depending on approach. Am I missing anything?
thanks in advance.
Related
I have an existing web application that's developed with Ruby on Rails and PostgreSQL. I need to create a mobile application (and possibly a separate web application) using the data from that web application, so I'm looking to create an API server. Is it possible to do this without altering the source code from the original Rails/Postgres web application?
Any ideas on the best way to do this? Or can someone point me in the right direction on what to research?
To connect a new application hosted on Heroku to a PostgreSQL database hosted on Heroku just push your new application to Heroku as normal.
Then, under Settings on your new application dashboard, go into Config Variables and add a new config for DATABASE_URL. Put the value of the url for your existing database.
Your new application will need to be under the same account as your existing application. Heroku doesn't allow you to connect across accounts.
You probably want to take a look at this question for additional details.
Sounds like essentially you want to have two applications connecting to the same database offering the same methods, but respond in different formats (html vs, for example, json). One way of doing that relatively easily might be pushing another api only Rails app to heroku that connects to the same Postgres database (which was mentioned in the comments), but you would have to figure out how to handle authentication differently for your API end points. This depends on whether you are exposing these end points to the public or to something like a mobile front-end. You may want to switch to token-based authentication if you were formerly using sessions on the web-app. Once you implement secure authenticatoin for your api routes, all you have to do is make sure your methods, instead of rendering erb or haml templates, are returning raw data consumable by your intended client.
A project I am working on was once an internal intranet application, but now it is being ported over to a multi-tenant internet application. Usually, when deploying any web applications, we would use the format http://webapp.company.com which has existed long before I joined.
Since the project is now a multi tenant application, I am trying to decide between different architectures.
1) Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
2) Include the tenant as part of the routing and the tenant name will be included as a routing parameter
http://webapp.company.com/{tenant}/my/route/url/{param}
This approach, in my opinion, is 'messy' and I feel it is not the most-correct solution.
3) Keep the existing url of http://webapp.company.com and add specific bindings in IIS to point the requested url to the host location.
When the user enters the url http://tenant.company.com they will be served the application that resides at http://webapp.company.com The problem with this approach is that we may deploy additional applications and this is not scalable.
I am leaning towards approach number 1 as I have experience implementing it (without the extra domain). Is the 4th level domain ideal? Any ideas as to what approach is better than the other? Possibly a new approach? Any input is appreciated.
Using the client/tenant as part of the main host url
http://tenant.webapp.company.com
This approach requires additional ssl certificates and iis settings
Actually, you might be able to use a wildcard certificate for *.webapp.company.com, which would mean you can extend this scheme without additional IIS configuration.
In addition, this approach is the most elegant when it comes to routing. There is even a MVC-Subdomain-Routing project on GitHub that you can use for some direction (or as is if your requirements are met by the project).
Also see this question and this answer for some other approaches.
I've a web site developed using MVC 4 ASP.net application. I'm new to .net platform & I want to add web service which would return me operating system name of users device based on certain input.
Assuming I've logic to capture OS information using inputted data, how do I go forward in building this web service?
Do I need to have a complete separate solution file which will have a web service or in existing MVC 4 asp.net application itself, should I create a new project which would be of type "WCF Service Application"? Again I don't know much about WCF service either, if I use it, how would the URL be accessible, etc?
Can anyone give me some insights?
Note: I've also a separate REST web service which is a completely separate solution with separate projects but deployed on same IIS.
Thanks in Advance!
You don't need to create a WebAPI project just for what you described (i'm assuming one or a few end points).
Simply use MVC controllers that return JSON for example, this way you deal with a single framework.
Reasons to move to Web API is if you need support for CORS, need content negotiation for results etc. From what you are describing it's completely fine to stay with MVC.
I'm working on a SAAS product. It's hosted on Windows Azure.
I need to give our customers to option to have CName records.
Our app URL looks like this: login.appname.com
When a customer is created they get their own address created for them that looks like this: login.appname.com/CustomerCompanyName
What I want to do is have our customers URL's look like : login.CustomerCompanyName.com/
What is the best way to go about this.
It's a webapp building in ASP.NET 4/ MVC4 hosted on Microsoft Azure.
Any tips would be greatly appreciated.
Thanks,
Noel
You need to understand the technical limitation with your requirement.
Your application is running at login.appname.com
Customer is created and you provide specific site as login.appname.com/customercompanyname
Note: At this time customercompanyname.com is not even a registered domain or if it is registered it may belong to someone else. (or do you register the customercompanyname.com domain first and then create the new customer in Azure App?
What you want to do is very complex to achieve. It is not impossible however every time you will do that, you will have to modify your Azure app to handle the host header. I personally believe a very ugly work.
So if you want to know what is needed, here is just what I think (others may be different or better solution):
Register a domain name for your customer (customerAcompanyB.com)
Create a custom folder in your Windows Azure Application during development
Modify your your Azure application to handle customerAcompanyB.com hostheader so you can route the request to appname.com/folder_name
In your customerAcompanyB.com domain registrar setup CNAME to route your appname.com
I think there is a wide consent that is a good practice to separate your REST API from your main website. The main reason is that you can scale your API and website independently of each other.
Additionally, Rails has a lot of middleware that is not required for stateless services (e.g. sessions, cookies, view rendering, etc...). Jeff Dean has a good write up on how to remove all of this middleware (http://pivotallabs.com/users/jdean/blog/articles/1419-building-a-fast-lightweight-rest-service-with-rails-3-).
At the moment, I am simply using the new Rails 3 responder (respond_with) in one single application, both for the website and the API. The website is used mainly for administration purposes.
How would you separate the API from the website?
I think an option would be to pack all models in a gem, then have two different applications, one lightweight REST service, and the administration website. They would be hosted on different Heroku instances, but access the same MongoHQ database.
You have 2 choice
extract your Model ans use it in all of your 2 application
made you API and your application on same application. But you deploy 2 server. One using only your application par and other with your API part. So if you need more API. add more on your API server.
You don't really need extract API. You just need separate it.