Skip to main content


Friendica codebase restructure


!Friendica Developers

Based on the PR https://github.com/friendica/friendica/pull/12075

@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 :)

Friendica Developers reshared this.

in reply to Philipp Holzer

Thank you for the write-up. I am not familiar with the Emitter pattern, would you mind explaining it more?

Secondly, what is the ultimate structure of the src folder? Is the Library folder transitional or final? In the latter case, what other folders would be at the same level?

Friendica Developers reshared this.

in reply to Philipp Holzer

The Emitter isn'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 the Page code.

And yes, I think the Friendica\Library is 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 Friendica
  • Console ... All Console classes (= the CLI)
  • Core ... All Core Friendica classes, which are always necessary :-)
  • Database ... The core Database Namespace (maybe inside Friendica\Core at 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 logic
  • Worker ... 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, Util

And now tbh I'm a little bit struggling where to put a Middleware folder *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 Factory and Repository and Entity thingy, which will persist :-(

But for example the Mastodon API calls are now bundled inside Friendica\Library\Api instead of floating around at Friendica\Factory, Friendica\Object and Friendica\Collection

Friendica Developers reshared this.

in reply to Philipp Holzer

Thank you, I have trouble understanding the difference between "Library" and "Core" ?

Friendica Developers reshared this.

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.

Unknown parent

Philipp Holzer
Good point .. but at least merging the current namespaces at src into only a few will help us with little effort. The Middleware thingy is just another playground, yes I must confess. I fell into it because I tried to make BasicAuth and OAuth dynamic, to make some of the skipped tests testable :-) ..

Friendica Developers reshared this.

Unknown parent

Philipp Holzer
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.

in reply to Philipp Holzer

I'm with Michael here, before we start tackling the testability of modules (which I am interested in), I would like them to be all moved from the mod/ folder. This doesn't interfere with your proposed restructuration where they wouldn't be moved again.

Friendica Developers reshared this.

in reply to Hypolite Petovan

So do you agree with the restructuring or shall I postpone it after mod/ is restructured? I think first, but I'm not sure :-D

Friendica Developers reshared this.