Friendica codebase restructure
Based on the PR github.com/friendica/friendicaโฆ
@Hypolite Petovan is right, I should have started this conversation first, but it made fun to restructure our code, so it is what it is *gg*
What's the issue/my pain:
I'm thinking about introducing the PSR-7 Request/Response interfaces and create an Emitter, so there's no way out anymore directly inside the code, everything is done by the emitter. With this pattern, we could add all the authentication stuff inside a "Middleware" and get rid of the different auth-places (App, Security\Authentication, Module\BaseApi)
So, now I tried to think where to start. We would need a Middleware directory for all the auth/base-load things, but we already do have a mix of domain-based directories (TowFactorAuth), functionallity based directories (Model/Object/Factory/Collection/Capabilities) and and core directories (Core, App, Console, Worker)...
And I try to start to "really" encapsulate the domain-based directories inside Friendica\Library, so we get rid of some mixings, having all domain based classes inside one directory.
In the end, I think we should have some core directories at src, directing everyone to the right place.
I hope I didn't loose you at least, I just wrote down my path to this PR :)
PS: there're "just" ~200 code changes, the rest is because of the messages.po recreation don't worry :)
Restructure Friendica Base by nupplaphil ยท Pull Request #12075 ยท friendica/friendica
I always struggle with our codebase about where to find what content .. Because we moved from pattern to pattern, we left a lot of leftovers in our codebase. This PR should restructure our codebase...GitHub
Friendica Developers reshared this.
Hypolite Petovan
in reply to Philipp Holzer • • •Thank you for the write-up. I am not familiar with the
Emitterpattern, would you mind explaining it more?Secondly, what is the ultimate structure of the
srcfolder? Is theLibraryfolder transitional or final? In the latter case, what other folders would be at the same level?Friendica Developers reshared this.
Philipp Holzer
in reply to Philipp Holzer • •The
Emitterisn't really a pattern, it's the "final" class, where we pass the whole Response of our Modules or Exits and which prints header, body and HTTP Codes. It's the ending of my start with the `Response` class and it should moveout some of thePagecode.And yes, I think the
Friendica\Libraryis the final place for the domain classes.I think about the following folder structure (which btw. maybe help @Michael Vogel reducing his headache with the structure):
App... All base-classes, which are necessary for the Request/Response behavior of FriendicaConsole... All Console classes (= the CLI)Core... All Core Friendica classes, which are always necessaryDatabase... The core Database Namespace (maybe insideFriendica\Coreat least ?)Library... The whole business logic, domains, Content, (refactored) Models, ...Module... The "Glue" between Routes and the business logic (=Library) ... as it is currently :)Protocol... Federation specific logicWorker... All Worker classes (= the cron)I believe the rest is "legacy" and should be moved inside one of the namespaces above:
Content,Model,Network,Object,Security,UtilAnd now tbh I'm a little bit struggling where to put a
Middlewarefolder *gg*.Addressing @Michael Vogel "more complex" .. At least I hope it's getting better with the whole structuring and introducing of
Middleware, bringing more focus onto our code..Still, I believe your main concern is this
FactoryandRepositoryandEntitythingy, which will persistBut for example the Mastodon API calls are now bundled inside
Friendica\Library\Apiinstead of floating around atFriendica\Factory,Friendica\ObjectandFriendica\CollectionHypolite Petovan likes this.
Friendica Developers reshared this.
Hypolite Petovan
in reply to Philipp Holzer • • •Friendica Developers reshared this.
Philipp Holzer
in reply to Philipp Holzer • •Core... Config, Lock, Logging, Network(?), Database(?), ...Library... PermissionSet, TwoFactor, Community, API-specific logic, Messages, ...I think, inside of library are classes, which are only used for a specific purpose, a specific use case. Core is used almost everywhere
Friendica Developers reshared this.
Philipp Holzer
Unknown parent • •srcinto only a few will help us with little effort. TheMiddlewarethingy is just another playground, yes I must confess. I fell into it because I tried to makeBasicAuthandOAuthdynamic, to make some of the skipped tests testableFriendica Developers reshared this.
Philipp Holzer
Unknown parent • •sounds logic, but of course thank you for the hint!
Currently, for me it looks like a giant hill to make them testable, that's why I started to refactor them step by step (and therefore first step is to make a base-structure for it
)
But you're right, the Addons are really old and when I added the S3 Addon, I saw that there's no possibility to automatically test anything of it because of the current structure ... Maybe that's a better place to focus
Friendica Developers reshared this.
Hypolite Petovan
in reply to Philipp Holzer • • •mod/folder. This doesn't interfere with your proposed restructuration where they wouldn't be moved again.Philipp Holzer likes this.
Friendica Developers reshared this.
Philipp Holzer
in reply to Hypolite Petovan • •Friendica Developers reshared this.
Hypolite Petovan
in reply to Philipp Holzer • • •Philipp Holzer likes this.
Friendica Developers reshared this.