Skip to main content

Friendica codebase restructure

!Friendica Developers

Based on the PR

@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.

Like always this is far above my head, I guess :-) I still struggle massively when I am forced to have a look at one of the newer classes like the ones for notifications, introductions, the logging or the curl classes. Mostly I don't even find the code, but only a bunch of abstractions that seem to lead to nowhere. The Mastodon API classes are currently the maximum of what I comprehend, I guess.

Can this "Middleware" thingy be made in a way that is not more complex than that?

Friendica Developers reshared this.

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.

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.

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

Friendica Developers reshared this.

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.

Btw: Before refurbishing the refurbished code that had been refurbished before, I really would like to finally get rid of the really old code in the mod folder. And we should finally find a good way for the addons as well. This is still really ancient stuff that hasn't been touched for years and desperately needs some love.

Friendica Developers reshared this.

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.

Concerning the auth stuff for security reasons we should ensure that the api frontend can only be executed when authenticated via the api and that the web frontend can only be executed via the web authentication. Please take that into account.

Friendica Developers reshared this.

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.

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.

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.

I think both, even if they sound unrelated.

Friendica Developers reshared this.