I have a SAAS in production and I want to give the customer the option of having a custom domain.
The application is in PHP without any javascript framework.
I would like to know the best ways to set up so that it is practical in terms of scale and implementation.
The operation should be as follows:
MAIN APPLICATION
myapp.com/company/product/clothes
The client will be able to navigate through the page through his domain as well, but everything being consumed from the main application without code duplication.
Customer domain example
companyapp.com/product/clothes
I currently use a shared hosting that contains WHM/CPANEL.
Related
I have a few PHP Laravel projects (restful API, admin app, client app). There is only one database which is used by API. The project is some kind of app which can be used by some companies. They have access to admin panel, client web page, they can use own API, they can make own users, permissions and so on. There is no problem if this project will be used by one client, but I'm going to sell this app to many people. I will be responsible for updates, hosting, configurations etc. I wonder how to make it the best way and I have a few ideas.
I thought about cloning the app on the server each time someone buys it from me. This requires setting up a new subdomain on the server and a lot of disk space. Not sure about it.
Or maybe cloning the app and sharing some files with symlinks like vendor, node_modules etc.
Another idea is to make it as a one project with many databases for different clients, but how to make it in Laravel in the best way? I will need some dynamic way to change the database connections (I want each client to have separate database), I'm not sure about conflicts with sessions, cache etc.
Maybe separate databases is a wrong idea, and it's better to have one database and make it as a one project and sell the access to project? But then I need to keep data of my client in one database.
What do you think?
Create this application as SaaS (software as a service). You can give them some default templates of front end or even client app (website and admin part), but keep all backend at your servers. Make REST endpoints, authenticate clients and give them functionality that they bought.
For example:
Client A bought calculator services from you. It authenticates, and makes GET call to /api/calculate/subtract/5/1. You give them response what your calculator does, for example 5-1 = 4. They can use your prepared templates for this data preview or create their own.
Client B bought calculator and storage services from you. You calculate same value, give it back, but also store it in your own database. So client B also can make call GET /api/storage/last_calculation and you give them 4, because client data stored in your database, he bought storage service too so he do not need to setup database for himself.
It is very simple example, but you should get the point.
For example simple scheme with separate database for each client:
I am working on a SaaS application. We take Shopify / Magento Go etc as reference.
I used CodeIgniter PHP framework.
SaaS Methodology - Multiple database, single code-base
Our SaaS architecture is as follows:
when a customer signup a database is build with his name and contain his specific databases.
when a customer signup he get a sub-domain (Ex: test1.example.com)
The customer can add his own domain that points to the system defined sub-domain. (Ex: test1.example.com to www.mydomain.com )
How to achieve this functionality?
For this you have to go through few configuration options.
Configure DNS: Create sub-domain with *. (ask you host)
You have to configure apache or .htaccess to point all requests coming to your domain point to same directory.
Database Setting: Try to learn how to use multiple database in codeigniter.
That's all. Enjoy!
I think that you should look for the term: " codeigniter multi Tennant app " and as said before, managing too many database isn't a solution!
You can achive proposed SAAS application this way,
There will be 1 database for application itself, and another N number of databases for clients, each new client will have new database.
Allow signup to your clients by asking basic details + subdomain to choose like blogspot do, subdomains taken by existing clients wont be allowed to reuse
When client signup successfully, one separate DB will be created and they will landed to their dashboard. Here one DB server will be fine but should have enough space and other parameter set to handle multiple databases.
Now dahsboard onwards, user will able to see list of functionality to use along with some predefined set of content that will be shared between user and loaded from "app DB". Whatever they do add will goes to their own independent DB
Here codebase will be deployed at one code server and main domain will be mapped to that so login/singup etc will be happen here and user's identification will happen at login level.
App DB: This DB will be responsible to store app level master data, i.e. Client's profile + login details, other admin related stuff which they meant to share to their clients. In case of shopify kind of app, themes, layout, templates can be master stuff that will store into this DB.
User DB: Only user's created, added content and its sub content should be stored. Whatever we can call user's ownership should be stored here.
Note: If its paid service, then you can use good payment gateway like stripe or chargebee to manage all your plans, subscriptions, email notification, dunning, payments log, payment success/failure, payment invoices.
WRT to subdomain and custom domain concept, you can do this using virtual hosting mechanism, you can do with apache as well as nginx server.
- Subdomain: Create config files as per server, put on proper place and any created subdomain will bind to particular pysical virtual directory
- Customdomain: Can create physical directory same as subdomain along with config files but in this case, you will need to ask your client to do DNS binding with our IP addess
In both this case when request comes to our server, server will check if config file and physical directory available tp hit then it will redirect user to destiny forlder.
I'm developing the online presence of a new sporting league. The web presence will consist of the organisation's information site (think the NFL website) and then individual team sites.
My idea to achieve this was to pick a framework like Zend Framework, and then have two applications (main site and team sites application). When a visitor accesses the organisation's domain the request is handled by the organisation's application code, and when an attempt to access any of the teams' domains (they could be dozens) the request is sent to the team sites application code, and the skin is switched depending on the domain accessed via.
The reason I want all team sites to run from the same application code is, if I added a section (for example, roster) then I'll want that on all team sites. There's seldom going to be an occasion where a team is going to need an individual page, but I'll handle that when I come to develop the CMS.
What I need is just a helping hand on how the above scenario would work with Zend Framework. I have one Zend Framework library that I'd like to use for both applications (which is in my include_path) so would just like to know how the requests would be routed and the framework would be set up to handle this situation?
Thanks in advance.
EDIT: I should also mention that I'd like the share the models between the two applications. For example, the individual teams sites may feature profiles of players for that particular team, but the organisation site may offer profiles of every player.
Putting the ZF libs into the include path is basically all you need to do to share ZF between applications. You can share any models the same way. By putting them on the include path.
What you describe above doesnt sound like it needs multiple applications though. If all that varies is the site theme, then you can serve that all from the main application. Add a custom route that can detect when its a team site. For instance, when team sites are available at their own domain, map the domain name to the theme folder and apply any necessary filters to limit the player profiles.
An alternative would be to make the main application a consumable webservice. The other applications could then use the main application's API to fetch the appropriate player profiles.
I'm currently building a simple web application in PHP that other company's can use as one of their services. I want to host the application myself and not install it on one of their servers, but i do want the accessibility that that would offer. Example:
www.mywebapp.com is where i would host the web application.
www.company.com would be the domain name of the client.
webapp.company.com should redirect to www.mywebapp.com/?c=company. Upon navigation, webapp.company.com/view.php?v=test would also be redirected to www.mywebapp.com/view.php?c=company&v=test and so on upon further using the web app.
Can someone explain how i can achieve this and if this is the best option considering my requirements?
I recommend that you switch to implementing an API. That's how this problem is solved by many corporations. They simply have an API key that will let your server know what client they are and therefore what to serve them.
Resources on API's:
Google Tech Talk: http://www.youtube.com/watch?v=aAb7hSCtvGw [1:00:19 long]
http://blog.programmableweb.com/2011/01/06/from-the-trenches-web-api-design-best-practices/
Directory of some existing API's: http://www.programmableweb.com/apis/directory
I think your idea IS possible if both servers are set up correctly, but doesn't it feel wrong to you?
You would need to have an 'a' record for both domains pointing to the same server
http://corz.org/serv/tricks/htaccess2.php?page=all#section-rewrite_sub-domains
I would like to know the best way to enable custom domains when creating web applications. For instance, if you look at something like Base Camp, when you sign up for that you create your own 'sub domain' to which you use to login to your basecamp with.
Also, if you look at this like hosted ecommerce sites, you can use your own custom domain instead of using a sub domain of theirs.
Personally I can't see these web applications 'parking' each custom domain on the web apps hosting account or adding the DNS if it uses a sub domain like Base Camp does.
Therefore, the only way I can think about doing something dynamically like this is to maybe use mod_rewrite to redirect everything to a certain script that does the 'routing' based on the url. Then for the customer domains, the customer would just need to add a CNAME for their domain to something like custom.webappname.com which then in turn gets picked up by mod_rewrite and the php routing file.
If this is the best way forward, are there any performance issues with routing all incoming requests via this 'routing file'?
Sorry if im not clear, tried to explain the best I can.
Yes, your solution would be the best way. That is how other sites do it. Rerouting all requests through a central file using rewrite rules incurs a small performance penalty but it is well worth it.
In fact, in most applications you are already paying that penalty anyway. Any framework that uses the FrontController pattern already does exactly this. This includes pretty much all frameworks like Zend, Symfony 1 and 2, CakePHP, CodeIgniter an many others.
It really depends on the web app your working with.
For example we have a hosted CMS, using the cPanel API we do create an actual hosting account for each customer and install about 50KB of files on account creation including a default template, initial set-up script (handles DB install, initial population of data and basic settings amongst other things) and a few basic front end control scripts such as the contact form, in saying this we don't provide access to the hosting account, all interaction is via our web app. In our case this is regardless if a sub-domain or fully qualified domain. Our customers have the option of self-hosting their domain or we will host it, because we have complete cPanel hosting infrastructure it makes no difference to us where DNS is but if the customer has it away from us it is entirely their responsibility.
The reason we have this hosting set up is so customers can upload their own templates, for disk storage management (we aren't interested in being a file server but customers need some space for PDFs, images, etc) and to make sure the content of 1 customer doesn't get mixed in with the content of another. As a premium paid-for service our lawyers recommended a minimum of separate identifiable folders on the server for file storage.
Another example is blogger/blogspot, it is well known they use mod_rewrite for their sub-domains. This is appropriate for them to do it this way otherwise they would have to create a separate DNS zone for each blog at a minimum and this is a pain (hence why we use cPanel), plus you have all your other virtual hosting set-ups.
With mod_rewrite as you will be aware it will use a single wild-card zone to control the sub-domains and the mod_rewrite rule is easy to apply. From there it is simply creating a folder and redirecting requests for the sub-domain to it or directing to the script to control your app depending on what you're doing.
The truth is for an automated system using sub-domains I would use mod_rewrite but for something a bit more complex like a fully blown premium CMS requiring full legal conformity, quota management, suspend, terminate and file removal functions then I would recommend looking at a hosting control panel such as cPanel as a possible solution.
You've got the right idea. You keep a single codebase, running (for the sake of argument) on a single IP. You don't need to worry about virtual hosts, or even mod_rewrite (aside from whatever your application needs).
You web app simply handles any and all requests to that IP (on port 80 or 443, or whatever).
When your application bootstraps in response to a request, it peeks at $_SERVER['HTTP_HOST'], and configures itself for the client associated with that domain name. If not found, it 404s, or whatever makes the most sense.