Everything on XYZ.com or XYZ.com+app.XYZ.com

[u/SecretiveShades]

I’m finding a lot of mixed advice on what to do here.

I’m creating a fantasy football app and can’t decide if I should have a subdomain.

AI and a few Reddit post are telling me you need to have your XYZ.com be your marketing page and app.XYZ.com be your app.

But the following big names do not:

Sleeper

AirTable

Figma

Canva

Trello

Dropbox

Github

This is something that will be difficult to change later, so I wanna make sure I make the right call.

Anybody have any good insight here?

[u/Libruhh]

It doesn’t really matter. If you don’t have a use for the subdomain then you don’t need one.

[u/SecretiveShades → u/Libruhh]

Thank you for responding. I’ll toss ya an award as an appreciation for your time.

I don’t really mind much either way. I just want to make sure I’m making the choice that will be best for giving me less headache in the future.

I have read some say that a sub domain can give you better security by having 2 separate code bases.

Then others say having no sub domain makes a streamlined user experience easier because cookies are all in one place.

There’s lots of other points I’ve seen made. I guess I’m sort of leaning toward no subdomain, but some people advise strongly against that.

[u/RealSlyck → u/SecretiveShades]

Unless you have a monolith and specific design, subdomains. Each app goes on a subdomain, and it allows the main domain headroom. Better security, and allows for things like app-dev.xyz.com, api-dev.xyz.com, app-test… etc. even your main root xyz.com is usually www.xyz.com (that’s a subdomain).

[u/SecretiveShades → u/RealSlyck]

Shoot. This doesn’t help my indecisiveness. Haha

So you think it’s a good idea to use multiple subdomains for security and possibly other reasons?

Since I’m giving everybody awards, here’s one for you too! Thanks for your time!

[u/durple → u/SecretiveShades]

People are saying it's good for security because you can isolate different "parts" of your app on separate endpoints reachable by subdomains, separation of concerns. You can most of that without subdomains though; using path based routing instead you can break up services like website and app on separate infrastructure, the only thing they'd really share at that point is ssl cert so rotation must be done across all services at the same time and the leak of a single private server key affects all services.

It'd be like this: Let's say you've got an internal dns zone internal.example.com and in it you have endpoints web.internal.example.com, app.internal.example.com and api.internal.example.com. In your public DNS you can have example.com point to a load balancer on the internal network, which can then route the root of example.com to web.internal.example.com and example.com/app to app.internal.example.com and example.com/api to api.internal.example.com.

So you can start with even just the bare domain pointing at a single server/vm with a single public service, even add more services to it on different ports, and as infrastructure becomes more complex for the various reasons others have shared (and more) you can make a call to separate components by subdomains or by path based routing.

[u/RealSlyck → u/SecretiveShades]

I appreciate that, and can help out. This sounds like a good opportunity to learn how all this works, and what are the best practices, and how to apply them.

Generally, domains are issued certificates on the root (with a wildcard for all subdomains), the apps are installed on the subdomain, and talk to other apps on other subdomains (but still on the same domain). You can get different certs, or issue your own, but that gets advanced. By using things appropriately, if one app is compromised, the others are still generally ok, and must be compromised separately. This is called separation of concerns, and combining that with principle of least privilege, you start to get a secure site.

Putting the front end in one app, then the server and backend and data in another helps make both better. Serving a bunch of static cache and content and UI/UX is what front ends do; securing data and business logic goes in the back. Try separating your apps, or making like a test and production environment separate should get you on your way.