OK great, but PHP? Seriously?

In many ways PHP's bad reputation is unfair, because it has been the language of choice for lots of poorly written projects. In many of those cases, the creators were to blame more than the tool. Like nearly every other technology PHP has a purpose and serves a specific niche as the right tool for the job.

The RAP stack is largely a counter-response to the ever-changing web development landscape. New tools and frameworks are constantly being released, with each making lofty claims that they'll help teams build software better, faster, and more reliably than before. While occassionally this is true, often it isn't. In the worst case scenarios new technologies can become counterproductive nightmares; decreasing team velocity, adding unnecessary restrictions, binding a project to vendor-lockin, creating dependencies that are difficult to upgrade, or simply requiring a paradigm-shift in thinking to produce similar results.

This stack provides fundamentally skilled developers a flexible pattern to build quality software systems with the propensity to choose proven technologies.

Over the years, my routine might have changed some but my philosophy never did. If something has worked for other greats before, and if something is working for you, why change it up and embrace some new fad? Stick with what works, even if it's unpopular.

- Kobe Bryant, The Mamba Mentality: How I Play

3-Tier Approach

Presentation Layer

PHP THIN-CLIENT

Interacts with REST API for all input/output
Contains no business logic or direct database connectivity
Built by Designers, Usability Experts, & Front-end Developers who have a mastery in hand-crafting quality, maintainable, HTML/CSS

Application Layer / Business Logic

REST API

Contains all business logic
Responsible for database connectivity
Testable and verifiable with or without the need of a UI
Built by Engineers with a mastery of Software Development principles

Can be built using the tools of your team's preference:

C# & WebApi
Python & Flask
Java & Spring
etc

Database Layer

PERSISTENT STORAGE

PHP presentation-layer has no knowledge of the underlying database(s) since all communication goes through the REST APIs.

Can be built using the tools of your team's preference:

PostgreSQL
MariaDB / MySQL
Mongo
Cassandra
etc

Philosophies, Principles, & Motivations

The user-interface is not the application, but rather a small module within a larger system.
Systems can (and in many cases should) have more than one interface. For example: mobile, admin panel, tech support, heads up display, and a test harness to name a few.
The user-interface should be more of a Web Design Project rather than a Software Engineering Project.
Less is more when it comes to business logic existing in presentation layers.
PHP still has a purpose, and there are lots of talented web designers ready and able to contribute.
Newer isn't always better. Just because the eleventy-billionth Javascript framework that was just released claims to help you build apps faster, easier, and more reliably doesn't necessarily mean it will work as well as it sounds.
Artists who learn to code are always better designers than Programmers who learn to design.
The end product is infinitely more important than the tools used to build it.

Problems This Pattern Attempts to Avoid

Open-source vendor lock-in
Deceptively easy one-line terminal commands that start a project quickly, but add bloat, unwanted dependencies and restrictions