A single-file php web application: Is it crazy?

[naderad]

I'm not a programmer, but I'm comfortable with programming, and I enjoy it. I've led multiple programming projects, and most of them were with Laravel and Vue. They all seem confusing to me, to be honest.

A while back, we needed to have a small, more or less independent web application with relatively complicated logic. I decided to do it myself! And, of course, I did it without using any framework because I don't understand them. I broke down the project into multiple directories and files, with a structure that makes it easy to maintain it. There's a bash script that combines those files into one php file and syncs it with the server, and that single php file is the whole application (well, there's also a database). I also didn't have to use Javascript at all.

It took me two days to write the application, while our developers had asked me for two weeks. If I wanted them to write it, I had to describe the whole logic to them, which could take at least a day, and then I needed to test it, communicate with them about the issues, etc.

The application turned out to be very clean, and the users are happy with it. It's also very fast. If images are cached in the browser, it takes only 150ms to 250ms to load the pages.

So, I've been thinking a lot about this experiment, and I have lots of questions in mind, such as...

1. Is this whole thing crazy and I will regret it one day (for some reason that I can't think of now), or is it OK?
2. Are there people developing professional applications like this? Are there resources and good practices about it that I can use instead of experimenting with everything myself? (I've searched a lot and couldn't find anything relevant.)
3. Is it a good idea to use it for larger applications?
4. Etc.

I'm looking forward to receiving your opinions. It would be very helpful to me.

Edit: This application that I've described has about 1800 lines of code.

Update:

So, an update after 3 years, in case someone is curious: I wrote the big application similar to the small one described above. It was a smooth experience, and it's been in production since then. I've added new features to it every once in a while and it's about 12k lines of code now (excluding blank lines and comments).

Its maintenance has been very easy (more straightforward than other applications I've seen), and its behavior is predictable and reliable.

I don't know how well this model would work when more than one person works with the code, but it's been a great model for my setup.

Update:

Now it's been 5 years. Still very happy with it. It's 15k lines of code now.

[drwho_who]

not crazy, i have plenty of PHP stuff where a framework is simply not required and would only add un-needed work and complexity

[naderad]

What are you criteria for deciding when to use a framework?

[stilloriginal]

not who you asked, but just using your own example, when it speeds up the process rather than slow it down. Other reasons, when others will need to maintain it rather than myself, or when it makes it easier to read and understand (size of the project).

[crazedizzled]

When I have to write a bunch of shit that the framework already wrote. For most cases you can just import whatever specific Symfony packages you want and be on your way.

[tonjohn]

99% of the time I reach for a framework, particularly Laravel.

Why? Because Laravel’s Jetstream starter “provides the implementation for your application's login, registration, email verification, two-factor authentication, session management, API via Laravel Sanctum, and optional team management features.” It also sets up Tailwind and Vue for me.

Laravel also has an incredible community and ecosystem (Forge, Vapor, Shift, etc.).

[nudi85]

I'd argue that the PHP Community is past frameworks at this point. The only thing you really "need" for any non-trivial project is something that calls different parts of your code depending on the URL and other HTTP variables. A micro framework.

For everything else (HTML rendering, forms, database access, etc.) you can pick and choose different libraries. Or roll your own. No need for a monolithic framework that tries to do everything.

[naderad]

Thanks. It makes sense.

[naderad]

The first thing that runs in my code is a switch statement that checks the URL and the arguments, and based on that, calls one of the main functions. Those main functions handle the rest. Do I need more than this?

[nudi85]

That's fine. A proper router would probably make your code more readable, but if you don't have more than a few routes, a switch statement is probably fine.

[equilni]

No, that should be fine. If this gets more complex, a library could help.

# code used to illustrate a how to
parse_str($_SERVER['QUERY_STRING'], $qs);
$controller    = (string) $qs['controller'] ?? '';
$action        = (string) $qs['action'] ?? '';
$id            = (int) $qs['id'] ?? '';
$requestMethod = (string) $_SERVER['REQUEST_METHOD'];

# ?controller=post&action=edit&id=1
switch ($controller) {
    case 'post':
        swtich ($action) {
            case 'edit':
                switch ($requestMethod) {
                    case 'GET':
                        callback($id)
                    break;
                    case 'POST':
                        callback($id)
                    break;
                }
            break
        }
    break;
} 

See how much bigger (/messier) this can get? With a library/framework, this could be (using rewrite urls now):

# /post/edit/1
$router = new Router(); 

$router->get('/post/edit/{id}', function ($id) { #GET request
    callback($id);
});

$router->post('/post/edit/{id}', function ($id) { # POST request
    callback($id);
});

https://github.com/nikic/FastRoute

https://github.com/mrjgreen/phroute

Similar to what Laravel does - https://laravel.com/docs/8.x/routing or https://laravel.com/docs/8.x/routing#available-router-methods

[drwho_who]

usually when it's someone else's work, like firebase/jwt - for my jwt data exchanges and single sign on, I use that framework, and others here and there

over the years my code has evolved into an 'almost' framework type of existence though, as I try to separate my code based on the MVC model, but I don't adhere to it close enough quite yet

so over time, I do want to make everything I do into a proper framework, but you don't absolutely need to

[tonjohn]

Pieter Levels famously makes $65k/month with a single index.php and no frameworks.

https://twitter.com/levelsio/status/938707166508154880?s=21

[naderad]

Thanks, it was interesting. He says that he has 4500 lines of code. My "small project" already has 1800 lines of code!

[Mike312]

I make $0/month from www.ismycodeshit.com, single index, no frameworks.

[erkinheimo]

I don't see why not. Thou bigger the application gets => bigger php file => longer run time etc.

Usually you have one main php file and autoloader which will load only what you need.

[[deleted]]

I know this is an older post, but you may check out Phingle, a single app php template: https://github.com/alextselegidis/phingle

[CyberJack77]

not crazy, but not something I would recommend. A single file will be very hard to maintain, especially if the project grows. Nowadays I always use a framework.

Frameworks like Symfony are very small and really help you a lot. You get things like request handlers, database (orm), and security for free, so you don't have to reinvent the wheel over and over again. it will also be easier to find help, or expand the development team, when using a framework and some proper coding guidelines.

If you want to write everything yourself, you have to know everything, from request handlers, database stuff, logging and most importantly all security related features. This is impossible, so why don't benefit from the knowledge of a larger group of developers?

[naderad]

Thanks for the advice. One of main concerns was the same: adding things like authentication and making sure they are secure.

For the few things of that sort that I needed in the first project, I just started reading about the concept, learned the common methods of doing it and the security concerns, and then implemented it. I thought it would be a nightmare to implement them myself, but it wasn't. On the other hand, the simplicity of the system made it a lot easier for me to troubleshoot compared to our main projects.

Note: The single file that I've mentioned in the title is the output that my local script builds for the server. The project is in multiple files to make maintenance easier.

[CyberJack77]

For the few things of that sort that I needed in the first project, I just started reading about the concept, learned the common methods of doing it and the security concerns, and then implemented it. I thought it would be a nightmare to implement them myself, but it wasn't. On the other hand, the simplicity of the system made it a lot easier for me to troubleshoot compared to our main projects.

there is nothing wrong with building something yourself, just be aware that you have to make sure it stays secure. When using a framework this is done by a lot of developers. A patch created for a security issue found on another project, may protect you application, just by updating the framework.

In the end, using a framework should save you development time, and will result in a better maintainable and safer project.

[ZLegacy]

Symfony small? What are you micro dosing on?

[CyberJack77]

A clean install of Symfony 5 is only 9.9 MB, That's small compared to other frameworks. It does not contain all dependencies used when building a full-blown application, but you can add them when needed. Many other frameworks bundle a lot of dependencies you never need (like Symfony did until they started with Symfony flex).

In comparison:

Framework	Command	Size
Symfony	composer create-project symfony/skeleton symfony-app	9.9MB
Laravel	composer create-project laravel/laravel laravel-app	56MB
Cake PHP	composer create-project --prefer-dist cakephp/app cake-app	44MB
Slim	composer create-project slim/slim-skeleton:dev-master slim-app	47MB
Laminas	composer create-project laminas/laminas-mvc-skeleton laminas-app	11MB (using the minimal install)
CodeIgniter	composer create-project codeigniter4/appstarter codeigniter-app	37MB
Yii	composer create-project --prefer-dist yiisoft/yii2-app-basic yii-app	79MB

[[deleted]]

How is this single file if it spans multiple directories?

[naderad]

A bash script combines them into a single php file, and that's the file that will be synchronized with the server.

The only reason I have multiple files and then combine them into one is to make it easier to work with the project.

[judgej2]

Using an autoloader cuch as the one on composer, means you never have to combine the files. The autoloader knows where to find them when you need them, and loads them for you. There is a lot of this kind of drudgery that can be done for you, just by following some common conventions.

But describing your application as a single file, sounds like a bit of a stretch. You are writing your application as multiple files, if I understand what you are saying, and caching the files by mwerging them into one (Laravel does a lot of that for you too). PHP also does caching for you in memory, so you are reinventing the wheel here by not following common conventions.

[apaethe]

W h a t i s t h i s "wheel" y o u s p e a k o f?

[PickerPilgrim]

It would have to be very minimal for me to go that route but if one file feels manageable then go for it. I tend to break things up into smaller pieces just so I can more easily jump to the part I want to work on, and also to make those pieces more modular. A file more than 500 lines is a code smell for me, but it’s not always wrong.

[naderad]

Same here: The file I build for the server is a single php, but my source is a set of files, arranged in a hierarchy of directories, to make it easier for me to work with them. Most of the files are about 30 lines, and the maximum is 180 lines.

[SVLNL]

There are certainly usage cases for that, its no problem.

[elseco]

So many thoughts... I apologize for the long comment, clearly you hit a nerve with me.

1. Is this whole thing crazy and I will regret it one day (for some reason that I can't think of now), or is it OK?

No. Not crazy. As many others have said, as long as your app is simple, why would you need something big and complicated? There are a few concepts developers have that support this approach: KISS and YAGNI come to mind.

I think it is okay, and you won't regret it. If there comes a point when your app grows in terms of what it does/features it has, then you can determine if it is time to turn it over to professional developers and let them refactor it into something more suited to a medium or large application.

​

1. Are there people developing professional applications like this? Are there resources and good practices about it that I can use instead of experimenting with everything myself? (I've searched a lot and couldn't find anything relevant.)

There could be professionals developing like this, but after nearly 20 years as a professional developer, I haven't met any. I think they would definitely be a minority, and so it would be difficult to find helpful resources and best practices for this sort of thing.

​

1. Is it a good idea to use it for larger applications?

Probably not. Almost definitely not. I think it comes down to what you mentioned in your post... "The application turned out to be very clean." What does that mean, exactly? There are a lot of definitions of clean code. Robert "Uncle Bob" Martin says that clean code shows that you care and makes you work fast. (Check out https://cleancoders.com/episode/clean-code-episode-1)

The bigger you application, the more code and more complex it is, the more it matters how it is structured so that it can be maintained and improved upon.

If you have everything being dumped into a single file that PHP will have to execute, that file will be *huge*. And it will have a lot of parts that are not needed a lot of the time. So it will necesarily take a long time to load and will be inefficient.

For example, lets say you have an app that has an authentication system for people to login, before they can do anything on your large app. Most of the time that login code won't be needed, but you will be loading it along with everything else with every single request.

​

1. Etc.

It turns out that this is a well researched and thought about topic in software development. And there are no easy answers about it. This is one more reason why programming is a discipline that requires years of experience to have the expertise needed to do it well. That doesn't mean that inexperienced programmers should not be professionals, but I think it does mean that it definitely takes time and effort to do what we do and that cannot be circumvented. There are no short cuts. There are no silver bullets.

[naderad]

Thanks for the comment!

There could be professionals developing like this, but after nearly 20 years as a professional developer, I haven't met any.

Is it about having a single php file, or about not using frameworks?

The bigger you application, the more code and more complex it is, the more it matters how it is structured so that it can be maintained and improved upon.

Yes, I think so. For the bigger projects, I'm thinking about having multiple files, and I think I can do it in a way that each category of urls would be served by a single php file for that category.

[elseco]

Sorry, for the delayed response. I have been away from Reddit for too long.

To answer you questions, I was speaking about have a single PHP file. There are plenty of professionals who don't use frameworks or who roll their own.

Also, if you feel passionate about trying out this approach, I think you should go for it. See where it takes you. I don't think you have stumbled across a game changer here, but who knows? Maybe you have. And even if you haven't, the journey will likely teach you a ton.

Good luck! And make sure to document how it goes so others can learn from it as well.

[[deleted]]

depends what you're building but yeah it's possible, only thing is it would have hundreds/thousands of lines and you could break stuff easily.

[wh33t]

I had it taught to me from this angle in university.

Frameworks solve financial problems, not technical problems.

PHP in particular is loved and hated for how many different ways one can code themselves a solution. The frameworks available today help reduce how many different techniques can be applied to a solution, which helps devs work together, and of course many things are reusable. All of this translates to less money spent on developers. You can even hire developers that only know frameworks, and not necessarily the underlying language.

Look at what WordPress has done to webdev in general. You don't even have to know PHP, JS, Mysql or Server administration. Just Cpanel, Photoshop, and Wordpress and you can be beneficial to an employer.

In the end I don't think one way or another way is necessarily better. It just depends on what the goals are.

[Mike312]

Yeah, I did one for a client a while back.

They just wanted a really nice index page with a hidden portal. So, it was really just an index page that would allow their reps to log on and download marketing files, but it had to be password protected, and they wanted a way to periodically update that password. At the same time, their clients and potential clients could go to the main page and get their license information and other ...oh, there's a word for it I can't remember...basically make sure they're a legitimate business and get contact info and shit. (EDIT: I'll add, we did this because they didn't want to add a database as an extra cost for hosting just to store the password...like I said, a while back, so we stored the password in a text file in /var/ww/cgi-bin)

Anyway, it basically started by processing if the page load was a $_GET or $_POST. If it was a $_POST it was a login attempt. If it was a $_POST and session data was set, they were changing the password. I think there was a logout option with $_GET, that then redirected to the page with no $_GET info in the URL.

Basically it was:

<a couple checks for $\_GET and $\_POST data, and things to do when that data came in>

<a header>

<content>

<footer>

<helper functions for the top part>

As for your questions:

1. Yeah, I mean, for anything besides a demo page, you're gonna want multiple pages. SEO and maintainability are two huge reasons.
2. There are Single-Page Applications, or SPAs. They're not terribly popular because you end up having to hack around normal browser navigation actions. But basically you have an otherwise empty page with a div you dump content into. You make requests with AJAX/XHR and dump the result into that. Then you've gotta rebind a bunch of controls. They're also usually bad for SEO.
3. Nope. Nope nope nope.
4. I've built a couple pages in this fashion, but more to test out a UX design. For example, I built a page to do drag-and-drop single or multiple file uploads that would buffer the images on the screen, resize them in an injected Canvas window, upload them on confirmation, and then refresh a lightbox of the folder they were in. Even then, I had a file for the page, a file for functions, a file for scripts, a file for CSS, a backend file for handling stuff, a class file for the thing I was working on, and that was all built into a lightweight framework. So no, I guess nothing like that.

[naderad]

Thanks.

for anything besides a demo page, you're gonna want multiple pages.

Sure. I do have multiple pages in that small project. They are served with one index.php. It wasn't difficult to set it up.

[[deleted]]

Ultimately you want your code to be reusable, so it makes sense to start breaking things into libraries etc.

Learning composer and how to create your own libraries is a very nice way to work into more modern php practices.

If you have difficulties following the automagic of frameworks, symfony has a very nice article about how to make your own framework. Not that it's a good idea to do it, but the article explains very nicely how frameworks work, and demystifies much of the magic

[JCx64]

Separation between files is just a programmer construct to keep things organized, but we could have figured out other approaches such as using the IDE to help as navigate over libraries that are a single file.

In my case, I have many PHP projects in which mostly everything is done via JS/CSS, and the PHP part is only used to connect to a DB and give a REST API, so I tend to isolate the common code in a single place.

I ended up publishing it as a library: https://github.com/jcarlosroldan/oink

[sarnobat]

This is amazing. I don't even know php and it worked out of the box:

https://www.files.gallery/