Subdomain Routing

[abbychau]

I wish to have a routing function supporting sub-domains. like kohana and laravel

[Conver]

+1

[karneaud]

+2

[Hexodus]

+4

[e-verdillon]

+5

[ichuot]

+6

[kouts]

+7

[joaomariowd]

Something like:

Flight::domain('@subdomain.domain.com'){ Flight::route ... }

That would be awesome!

I have a project that uses Flight, and in index.php I set a variable for the subdomain.

So, depending on the subdomain, or abscense of it, we choose the routes file. Works pretty well.

[niconerd-zz]

+8

[husmen73]

+9

[pwFoo]

Would be multisite support possible?

/core/flight/*
/site1/*
/example.com/*
index.php

Different sites / domains organized in different directory like done with typo3 or drupal? Tried flight.base_url to that sub directory, but got a 500 error.

[n0nag0n]

@all Maybe I'm naive, but I've never heard of something like this before.

So you would use the same index.php file to assign routes and attach them to specific subdomains?

Why wouldn't you either just look at the incoming Host header to determine the subdomain and assign routes based on that?

I guess my initial reaction is that adding this feature would be asking one index.php file/project to "do too much" almost like violating the Single Responsibility Principle of SOLID programming. If one subdomain is serving an API and one subdomain is serving the front end, why wouldn't you want those to be in the very least separate public directories of the same project to separate out the concerns?

[krmu]

@all Maybe I'm naive, but I've never heard of something like this before.

So you would use the same index.php file to assign routes and attach them to specific subdomains?

Why wouldn't you either just look at the incoming Host header to determine the subdomain and assign routes based on that?

I guess my initial reaction is that adding this feature would be asking one index.php file/project to "do too much" almost like violating the Single Responsibility Principle of SOLID programming. If one subdomain is serving an API and one subdomain is serving the front end, why wouldn't you want those to be in the very least separate public directories of the same project to separate out the concerns?

Django(Python) has such thing. You route all subdomains with single file. Questions stays open, is it safe.

[n0nag0n]

Feels like this might be easier to do something like a:

Flight::subdomain('something', function($Engine) {
    $Engine->route('/something', function() {});
});

[magikstm]

Seems like something that can be done with a different subfolder and/or a class object providing functions to FlightPHP.

Ref: https://github.com/flightphp/core#routing

It feels out of scope to me if FlightPHP is meant to be relatively simple.

[n0nag0n]

It is meant to be simple, but it's also meant to cover 90% of what it was supposed to be designed for. If it was meant to cover RESTful API's and if a good chunk of people need subdomain coverage, then I can see a case for that. I would never use it that way, but it seems to go along with the routing grouping I want to do anyway.

[starfishpatkhoo]

I see the appeal - one index file, and you can see the routing for both the front-end and the back-end. If this is the purpose, could this be solved through documentation?

Currently though, I just have different copies of index.php in different folders, but all include the same composer autoload (in some totally different common path). In my experience, different services in different folders (or subdomains) also needs different settings, authentication, etc etc etc.. So it is not just about routing...

Perhaps there is a way to load a list of routes as an array/json/whatever from an external file. And then have FlightPHP initialise only certain routes in that array. In this way, you can have one common file detailing the routes for all subdirectories/sudomains/etc etc, but different index.php using only certain parts of that file..

But yeah, one index.php for different subdomains? I know this is taught in many old-school hello-world examples for CGI - one PHP file serves both the front-end and the back-end. But in real world practice, especially in the API age, I don't know, seems a problem from a security stand point - a bug in front end code could potentially result in a problem in back-end service simply because they sit in the same physical file.

[n0nag0n]

I'd be curious to see the use cases of people doing this and how they share the various code pieces. Not that this is a microservices first arch but it would just seem to me that if you have api.domain.com and www.domain.com and admin.domain.com, the likelihood of all those things really sharing the same code is slim. Maybe api and admin if admin refers to API.

I'd just be more curious to see if something more like what @starfishpatkhoo mentioned is the way to go. You could just do something like this:

<?php

// includes and stuff

if($_SERVER['HTTP_HOST'] === 'api.domain.com') {
    require('api_routes.php');
} else {
    require('admin_routes.php');
}

// api_routes.php
Flight::post('/api-route', function() {});

// admin_routes.php
Flight::get('/admin-route', function() {});
// etc

[starfishpatkhoo]

Ah, I usually do it the other way around...

<?php

require("common_stuff.php");

Flight::post('/api-route', function() {});

// common_stuff.php
require("Common_Objects.php");

Because as you say, each part does have different things/config/functionalities/etc. But in this way, I even have CLI files (that have no routes) that can include Flight and all related common code as needed...

Add example - cron job run CLI to use Flight + friends to generate a HTML that is sent via email as a status update. Don't rebuild the wheel.. 🤣

[eydun]

Subdomain-routes is a "nice-to-have"-feature.

Personally I think we should be careful to add complexity to the framework, to solve edge-cases.

[n0nag0n]

Subdomain-routes is a "nice-to-have"-feature.

Personally I think we should be careful to add complexity to the framework, to solve edge-cases.

I agree with this. If this is still relevant in 2024, we can revisit it if the need is great. I personally haven't had a need like this in the years I've been coding.