API usage for Friendica Frontend
And another question 
Currently, we strictly separate between API calls and the Frontend.
But, Why?
I'm currently moving the events to the Module directory.
And there's already an API for it, but as far as I understand @Michael Vogel , we must not mix API and Frontend.
But as far as I know, in modern environments, there's a backend part (= API), and a frontend part (= view)
The own frontend still uses the same API. So we don't have to implement the same business logic at different places. As I said, I came across at Event, where this issue produces significant double-code.
So at least what I would like (in a final state :
- API ... Create, Update, Delete, Get, GetMultiple for our Data model, or "everything without HTML output"
- Module ... Everything, which produces HTML output
I know, this would be a BIG change
like this
Friendica Developers reshared this.
Hypolite Petovan
in reply to Philipp Holzer • • •API is a misnomer in our case because it can designate several things:
- Our internal API (what you described in your post)
- The Twitter API endpoints we support
- The Mastodon API endpoints we support
- The GNU Social API endpoints we support
- The Friendica-specific API endpoints we expose (mainly for Friendiqa)
We definitely lack a unified internal API but thatโs supposed to be taken care of by the Repository/Factory/Model/Entity structure that we should keep expanding.
Friendica Developers reshared this.
๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐
in reply to Hypolite Petovan • • •@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
Friendica Developers reshared this.
Hypolite Petovan
in reply to ๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐ • • •๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐ likes this.
Friendica Developers reshared this.
๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐
in reply to Hypolite Petovan • • •@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
Friendica Developers reshared this.
Hypolite Petovan
in reply to ๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐ • • •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.
Friendica Developers reshared this.
๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐
in reply to Hypolite Petovan • • •@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
Friendica Developers reshared this.
Hypolite Petovan
in reply to ๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐ • • •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.
Friendica Developers reshared this.
๐ค ๐ณ๐ต๐ผ๐บ๐ฎ๐ โ ๐๐
Unknown parent • • •What is the showstopper for that? Cause that is also a thing for a new Webdesign. So The Web sould be separate from the code with all the magic.
@Philipp Holzer
Friendica Developers reshared this.