@Hypolite Petovan
why don't separate the api for Twitter, Mastodon, Gnu etc. and of course an api to communicate with the frontend.
No mixing the api together. Activateing the maybe Mastodon APi as main class with subclasses in one folder and subfolders.

@Philipp Holzer @Michael Vogel

So far we’ve done a good job at having the business code identical for the Twitter and Mastodon API endpoints. There are some legacy Friendica endpoints (mostly the asynchronous endpoints used by Javascript) that are redundant with the page modules.

@Hypolite Petovan
Can this endpoint not be closed and moved to an other area. So that you have the main friendica core who will do the internal magic. On the other hand the API section who is communicating with the core. Additional an internal API who is communicating with the core and the frontend section. On all APIs there is only data communication.

The Frontend Section is an additional area who will communicate with the frontend API and the user.
So the magic on the frontend section will be created only in the frontend and the API communication will only send data ... No html, no Jscript and no other magic.

In that case all three sections (Core, API, Frontend) could be developed separate with less interference between them.

Sure if you need a new function... First core the API and if needed then frontend
@Philipp Holzer @Michael Vogel

I don't think we need to go that far. Separating the web frontend from the API would be a massive undertaking at this point, and also there's a trend where even Javascript frontends are starting to request already formed HTML from the backend because it turns out it's faster this way. Which means we're both behind and ahead of the curve!

However we do need to extract the business logic in a unique place so that we can reference it from the places it is duplicated.

@Hypolite Petovan
I think this is very necessary.
Passing preformatted web content makes you very inflexible since you have to go directly to the core. That's where I see the problem, that you either have a good coder for the core but not a good designer. The other way round a designer of the frontend can't write a good core code.
For this reason the Smarty framework is currently running in Friendica, which as I understand the framework wants to separate this.

If you want to speed up the whole thing, you have to get away from PHP code which is executed at runtime and create static pages. Peppered with lots of javascript which offloads/executes the execution to the client.

But ok that's my opinion on the subject.

@Philipp Holzer @Michael Vogel

Thankfully, we can have both HTML modules and API endpoints! As long as we don't duplicate business code, which is what Philipp has been encountering.

On the other hand, writing a full Javascript web frontend is a massive endeavor, there currently are almost 500 web frontend routes that each represent a part of a Friendica feature. They all would need to have a Javascript counterpart, without even counting the corresponding bespoke API endpoints that would need to be created.