Multiple domains for one website with multiple languages - laravel

I have 3 domains in 3 different languages and I want to point them to one website.
I want to ask hosting provider to point all domains to one application (code - same place/folder on hosting/server). Is this a right solution for this case, or should I proceed differently?
domain.tech - english
domain.sk - slovak
domain.es - spanish
I think it doesn't affect SEO since for every domain there would be different content (same content but different language).
I want .sk and .es domain to be geographically oriented.
I want .tech to be international domain with CDN service.
I want to approach same database and use same local assets (images).
Are there any negatives in option I am considering? Or is there any better solution?

Related

How to host sites on a single server?

I have five websites that I designed and now manage on a month-to-month basis. Currently, each website is hosted individually via HostGator. I am realizing this is the improper (and costly) way to manage multiple websites and am curious into how I could transfer the websites to a single server, and some hosts you guys find reliable.
Below is a snap of one of the sites usages, these are all static sites that are quite small. How much space would I need on my new, single server to accommodate 20 of these websites?
Current site usage:
http://imgur.com/18BvsC2
Your image shows you are using 6.7 megabytes of data for one website. If that is similar space usage for all 20 of your anticipated domains, you need virtually very little hosting space as far as storage goes these days. Most entry level virtual hosting plans come with more than enough to meet your 20 domain expectations of like usage.
You want virtual hosting regardless. Most web hosting providers have plans that allow you to host many domains, including hostgator. Here is a link to compare their plans. http://www.hostgator.com/shared-compare
I've used DreamHost and HostMonster in the past, with nothing bad to say about them.
Perhaps you should brush up more on the pros, cons and hows of web hosting. Here is a link I just googled that might get you started. http://www.webhostingsecretrevealed.net/web-hosting-beginner-guide/

Organizing large Web API solution

Good day,
I will begin developing a Web API solution for a multi-company organization. I'm hoping to make available all useful data to any company across the organization.
Given that I expect there to be a lot of growth with this solution, I want to ensure that it's organized properly from the start.
I want to organize various services by company, and then again by application or function.
So, with regards to the URL, should I target a structure like:
/company1/application1/serviceOperation1
or is there some way to leverage namespaces:
/company2.billing/serviceOperation2
Is it possible to create a separate Web API project in my solution for each company? Is there any value in doing so?
Hope we're not getting too subjective, but the examples I have seen have a smaller scope, and I really see my solution eventually exposing a lot of Web API services.
Thanks,
Chris
Before writing a line of code I would be looking at how the information is to be secured and deployed, versioned and culture of the company.
Will the same security mechanisms (protocols, certificates, modes, etc.) be shared across all companies and divisions?
If they are shared then there is a case for keeping them in the same solution
Will the services cause differing amounts of load and be deployed onto multiple servers with different patching schedules?
If the services are going onto different servers then they should probably be split to match
Will the deployment and subsequent versioning schedule be independent for each service or are all services always deployed together?
If they are versioned independently then you would probably split the solution accordingly
How often does the company restructure and keep their applications?
If the company is constantly restructuring without you would probably want to split the services by application. If the company is somewhat stable and focused on changing the application capabilities then you would probably want to split the services by division function (accounts, legal, human resources, etc.)
As for the URL to access this should naturally flow from the answers above. Hope this helps.

MVC3:Are Areas intended for this?

I have to code a web portal that offers multiple and varied features such as: notification and resolution of user problems, purchasing requests, requests for supplies, facilities management ...
I thought I should create an MVC application and divide it by creating an area for common things and a separate area for each of the other features, but do not know whether the concept of area is suitable for my needs or is intended for other needs.
Thanks for your answers.
Areas will separate parts of your site into directories where each area/folder has their related views and controllers.
Areas also help separate your application in the URL structure.
I don't think there is a hard rule of when to use Areas and when not to, most commonly though I would say it depends on the size of your application. A site with only a few pages would not realy need any areas, that might be overkill in design.

Advantages of having css,js and media subdomains

What is the benefits of seperating css,js and media folders under subdomains like
css.domain-name.com
js.domain-name.com
media.domain-name.com
I know that scalibilty begin from static/media files but does serving them from subdomain has any advantage ?
If so, in which degree should I do that ? For example, if I allowed to photo uploads, should I put my "uploads" folder under media subdomain ?
Thanks
I'd separate uploads from static files used in the generic layout (e.g. logos, icons, etc.) so its a lot easier to clear the existing files to upload a new design without having to care for the uploads to not be deleted/overwritten.
As for the domain names, I wouldn't split the files that way. One sub domain for static files, one for uploads - fine. But I wouldn't go as far as adding one for scripts or stylesheets.
Using sub domains can have advantages though, depending on the web server you can configure the whole virtual host to adhere to specific rules, e.g. not providing directory listings or not allowing access to any files other than images - or refusing to deliver hotlinked files (without having to worry about specific sub directories). It can as well make it easier to move the files to another host later on, e.g. for media files or downloads to a cloud hosting service.
Considering your example I'd use the following sub domains:
www.domain-name.com (basic web presence)
static.domain-name.com or media.domain-name.com (serving support files like js, css, images, etc. - stuff that doesn't change and can be cached for a long time)
uploads.domani-name.com (serving uploaded files)
Don't overcomplicate it as you're not gaining any additional performance that way (unless utilizing different servers and you're expecting heavy load). In fact page load might be slower (due to additional DNS lookups) and you might encounter security limitations, e.g. regarding cookie validity/accessibility or cross domain scripting.
There are mainly two reasons for doing this
Scaling - static content and dynamic content has other scaling parameters. The more you may differ between webservers serving dynamic and static contents. Based on this you may scale different based on your websites requirements. E.g if you host a photo site you will end up having 10times more static servers than dynamic sites. Static servers are usually much more lightweight than full featured application servers.
Cookies - Cookies are always sent to the domain they are assigned to. So cookies will be sent to e.g. www.xyz.com and not to sub.xyz.com
Probably it makes no sense to go more into detail than static[1-n].xyz.com. But that really depends on what you want to do.
To you "upload" folder question. Preferable the images uploaded to your main domain will be served by a static server (serving contents on your subdomain).
For JS, this seems like a bad idea. There are security restrictions to what you can do using JS when dealing with a different domain, which would be the case here.
For media files and downloads, basically BLOB storage, the story is a bit different. For high-traffic sites, it may be required to separate this in order to create a good load-balancing structure and to avoid putting unnecessary load on the web application servers (the media subdomain can point to different servers, thus reducing the load on the app servers while allowing to create massive load balancing for just the binary data serving).

Building a website backend with Code Igniter

What is the best (or most appropriate in a general situation) structure for building a website administration section with Code Igniter?
I have heard of several structure ideas, but they all stem from the two basic structures.
Have two applications, administration and application
Have one application which encompasses both sections.
What are the pro's and con's of each method?
Are there any other structures that you can suggest?
When examining these idea's one must take into account the possibility of a shared resources.
E.g. shared log in accounts, shared database, shared designs etc.
Single Application:
Pros:
Shared Authentication
Shared Configuration
Shared Model Code
View Level Integration ([Edit This] links in main application)
Cons:
Low Site Seperation (Can run into issues with setting your site to maintenance mode or bugs causing admin to blow up or visa versa)
Shared Authentication (Both a pro&con, if your auth is compromised, invader has access to admin).
Multiple Application
Pros:
Site Separation, No taint from admin in live site (visa versa)
Clearly defined application roles & can be optimized for their tasks.
For example, you can optimize a db for reads and set your front end on that, and then set up a different db the backend works on and sync to it. (Only really makes a difference in high load websites, but still a conisdderation).
You can host the admin site # a seperate domain for extra security or subdomain with a seperate SSL Certificate, etc...
Cons:
Code Duplication
Configuration Duplication
No tie-ins to main site (or limited).
Overview
It really depends on what you're doing. I'd say for any high trafficked site or any site with sensitive customer data (like credit card details etc) that the site separation of separate applications is invaluable. It allows for a great deal of security considerations above & beyond your average site. Also this allows you to greater optimize each application for their purpose for raw speed.
On medium / low traffic sites, I'd say the simplest approach is always the best (KISS). It'll help you keep your site up to date & moving forward faster. This is essential for sites building up & starting out. Less development time is always a great thing.
That's just a personal opinion though, it's really up to you, it comes down to what's most important to you & your business.

Resources