It seems strange to place modules such as db in /modules.
Shouldn't it belong to /engine?
Shouldn't the /modules folder be the user's own module?
It seems strange to place modules such as db in/modules.
3 months ago
3 months ago
#1
3 months ago
#2
★ Winning Post! ★
The thread creator has indicated that this post solved the problem or provided the best insight.
Members who post winning responses earn points for our leaderboard.
Points mean prizes!
So what changed?
The real question is this: what is the “engine” responsible for?
If the engine’s job is to bootstrap the application, route requests, and provide the minimal runtime necessary for the framework to function, then anything beyond that is arguably a feature.
Database interaction is a feature.
Yes, most PHP applications use a database. But “common” is not the same as “foundational”. A framework can run without a database. It cannot run without routing, bootstrapping, and core lifecycle handling.
Perhaps the simplest way to think about it is this:
The “engine” folder is responsible for making the framework load.
The “modules” folder is for features.
Viewed through that lens, database interaction sits quite naturally in /modules.
I hope this was useful. If anybody else would like to have a go at answering the question, please do. I need all the help I can get!
DC
3 months ago
#3
Mate, I reckon this feels weird at first only because most of us grew up with frameworks where “database” automatically equals “core”. But that’s more habit than good architecture.
Alright, now gloves off.
This whole “DB should be in the engine” thing is exactly the kind of thinking that leads to framework obesity. You start by saying “it’s common”, then before you know it, you’ve recreated Laravel’s bloat where half the universe is considered “core” because someone might use it.
Trongate deliberately doesn’t play that game.
The engine exists to do one thing: start the app and handle the request lifecycle. That’s it. No kitchen sink, no “while we’re here let’s just add…”, no creeping scope. Discipline is the whole point.
Database access is not foundational. It’s just popular. Big difference.
If you can remove something and the framework still runs, it’s not engine material. Full stop. You can absolutely run apps without a database. You cannot run anything without bootstrapping and routing. That’s the litmus test, and DB fails it.
Putting `db` in modules isn’t strange; it’s an intentional design that avoids the exact trap most frameworks fall into: confusing convenience with necessity.
Laravel went down the path of “everything is core because developers expect it”, and now look at it. Massive surface area, endless magic, and a dependency tree that reads like a grocery receipt. Powerful, sure, but lean it is not.
Trongate’s approach is the opposite philosophy. Keep the engine razor thin. Treat everything else as a feature. That’s not just cleaner, it’s more honest architecture.
If seeing DB in modules feels weird, it’s probably because you’re used to frameworks that quietly trained you to accept core creep as normal. Once you look at it through a separation-of-concerns lens, it makes perfect sense.
Engine is the runtime. Modules are capabilities. Database is a capability.
Not controversial. Just disciplined.
Si
Alright, now gloves off.
This whole “DB should be in the engine” thing is exactly the kind of thinking that leads to framework obesity. You start by saying “it’s common”, then before you know it, you’ve recreated Laravel’s bloat where half the universe is considered “core” because someone might use it.
Trongate deliberately doesn’t play that game.
The engine exists to do one thing: start the app and handle the request lifecycle. That’s it. No kitchen sink, no “while we’re here let’s just add…”, no creeping scope. Discipline is the whole point.
Database access is not foundational. It’s just popular. Big difference.
If you can remove something and the framework still runs, it’s not engine material. Full stop. You can absolutely run apps without a database. You cannot run anything without bootstrapping and routing. That’s the litmus test, and DB fails it.
Putting `db` in modules isn’t strange; it’s an intentional design that avoids the exact trap most frameworks fall into: confusing convenience with necessity.
Laravel went down the path of “everything is core because developers expect it”, and now look at it. Massive surface area, endless magic, and a dependency tree that reads like a grocery receipt. Powerful, sure, but lean it is not.
Trongate’s approach is the opposite philosophy. Keep the engine razor thin. Treat everything else as a feature. That’s not just cleaner, it’s more honest architecture.
If seeing DB in modules feels weird, it’s probably because you’re used to frameworks that quietly trained you to accept core creep as normal. Once you look at it through a separation-of-concerns lens, it makes perfect sense.
Engine is the runtime. Modules are capabilities. Database is a capability.
Not controversial. Just disciplined.
Si
3 months ago
#4
DC and DaFa, you guys answered the question flawlessly. I can't add much more to the logical arguments already presented, but I'll leave the questioner with an analogy to illustrate the philosophy here:
Most modern cars come with air conditioning and infotainment systems built-in. These make the ride more comfortable, but also add weight, drag on the engine/battery, and introduce more points of failure.
Trongate v2 is a race car. It's stripped down to the bare essentials to shed weight and deliver maximum performance. The "engine" is magnitudes faster than what you'll find in other frameworks. If you need proof, please see the most recent benchmark results: https://trongate.io/benchmarks
You can still add those "comfort" features if you need them, but in the Trongate world, those conveniences live in the modules folder rather than being hard-coded into the core engine. You only carry the weight you actually need for the track.
I hope this helps clarify the vision!
Most modern cars come with air conditioning and infotainment systems built-in. These make the ride more comfortable, but also add weight, drag on the engine/battery, and introduce more points of failure.
Trongate v2 is a race car. It's stripped down to the bare essentials to shed weight and deliver maximum performance. The "engine" is magnitudes faster than what you'll find in other frameworks. If you need proof, please see the most recent benchmark results: https://trongate.io/benchmarks
You can still add those "comfort" features if you need them, but in the Trongate world, those conveniences live in the modules folder rather than being hard-coded into the core engine. You only carry the weight you actually need for the track.
I hope this helps clarify the vision!
3 months ago
#5
Am I the only one to be pleasantly amused by the subtle wording of the question itself?
Why on earth would a db module be placed in a modules folder?
Why on earth would a db module be placed in a modules folder?
3 months ago
#6
Trongate V2 is the kernel of my web application, whether I choose to use a database or not. It is secure, fast, easy, and modular.
What I may touch on is the Modules directory. It would be nice to have a directory named trongate_modules for all core Trongate modules like (db, trongate_administration, trongate_security, etc.). I get messy sometimes.
What I may touch on is the Modules directory. It would be nice to have a directory named trongate_modules for all core Trongate modules like (db, trongate_administration, trongate_security, etc.). I get messy sometimes.
3 months ago
#7
Hello,
Personally to me, Trongate v2 and the directory layout, engine modules and so on is suberb. The challenge now for us is to adapt to a new framework designed for speed. It is exciting to see what the benchmarks are saying on how fast Trongate v2 is. What I see and wonder about is how does this relate to actual website page load speed in terms of distance. Example would be from New York To Los Angeles. or L.A. to London.
As for the Modules directory, It's perfect. As this is new, It is a new way of thinking, speed and stability and simplicity, over over-engineering.
Dan
Personally to me, Trongate v2 and the directory layout, engine modules and so on is suberb. The challenge now for us is to adapt to a new framework designed for speed. It is exciting to see what the benchmarks are saying on how fast Trongate v2 is. What I see and wonder about is how does this relate to actual website page load speed in terms of distance. Example would be from New York To Los Angeles. or L.A. to London.
As for the Modules directory, It's perfect. As this is new, It is a new way of thinking, speed and stability and simplicity, over over-engineering.
Dan
3 months ago
#8
Mental model, directory architecture, files grouping, you name it. Doesn't matter for me as long as it works, and in its simplest, purest form. Efficient. Nothing else really matters.
On my setup, I moved the tg_helper folder into the modules directory. It was simple enough, cheers to the devs!
Loved the word "kernel for my web apps", I even agree with Evans. I'm still building my own Trongate V2 boilerplate, a base for all my future projects. And, I don't have any idea on how to separate between the trongate framework orginal modules/db/helper/ versus the project-related modules.
But for now, I think, lets just let them all folders rest in that modules directory. ha ha ha.
Salut!
On my setup, I moved the tg_helper folder into the modules directory. It was simple enough, cheers to the devs!
Loved the word "kernel for my web apps", I even agree with Evans. I'm still building my own Trongate V2 boilerplate, a base for all my future projects. And, I don't have any idea on how to separate between the trongate framework orginal modules/db/helper/ versus the project-related modules.
But for now, I think, lets just let them all folders rest in that modules directory. ha ha ha.
Salut!
3 months ago
#9
@koolmees Because the content is translated from Chinese to English ╮(╯_╰)╭
Chinese is a very interesting language. Please see Chinese 1 to 10：(￫ܫ￩)
一、二、三、四、五、六、七、八、九、十。
Chinese is a very interesting language. Please see Chinese 1 to 10：(￫ܫ￩)
一、二、三、四、五、六、七、八、九、十。