RAPH.md

.
├── api
|   ├── module_name
|   │   ├── handler   // router, facade object
|   │   ├── action    // controller
|   │   ├── resource  // db, api interaction
|   │   ├── processor // data transformation
|   │   └── tests
│   └── routes        // unifies all handlers
├── assets
|   └── views
└── server.js

The RAPH architecture promotes modular thinking, reducing code dependency. How is this different from RAPHT? We're splitting off views into their own folder rather than intertwining them with the backend code; this enables easy production of single page apps with front-end frameworks.

And not only that, if you want to keep your sanity you'll be forced to properly architect your URL structure since a central point of reference is only partially available.

By grouping tests with their targets you enable easy sharding of your project into multiple repositories, making code sharing easier and having a better seperation of content.

routes functions as a manifest for your modules, exposing them to the server.

resources

RAPHT by Daniel Waterworth

Maybe routes could function as a manifest. Preferably it shouldn't include any manual registering of new modules, but on the other hand that does enable you to try out stuff easily. If opting to do that it should be moved to /api since /config should remain as static as possible, its only purpose is to configure the server through middleware.