The traditional loading of a page is a
e.g. calling the main address
which uses other
php files to answer the request.
XHR is widely used throughout the project but should be replaced. So do not implement new features with XHR!
We use XHR (XMLHttpRequest)
For example, the Update-Übersicht on the Dashboard is loaded by an XHR that gets a json file with the information of the updates.
it calls addresses like
This requests an answer by
/xhrapp.php which in turn calls the correct
php file based on the options that are given after the
? in the url.
For example, the
activity.js requests are answered by
In this case, the database is queried for the information via the
ActivityModel.php which in turn uses the
XHR-request answers contain a status and data and ? and always sends the HTTP-status 200. So errors are not recognizable by the HTTP-status but by a status in the sent json data.
nodejs for messages
The chats have a separate way of communication between client and server.
For all other pages the initiative starts at the client,
the client sends a request to the (
php) server and gets an answer.
Each request uses one connection that is closed afterwards.
This is not useful for the chats since the server knows that there are new messages and has to tell the client.
For this case there exists a separate
nodejs server (on the same machine as the
php server but separate). This holds an open connection to each user that has
foodsharing.de open on their device. Each time a message arrives at the php server, it sends this information to the
nodejs server via a websocket
which uses the connection to the client to send the message.
Note that there can be several connections to each session, of which there can be several for each user.
nodejs sends the message to all connections of all addressed users.
The code for the
nodejs server is found in
/chat/src/index.ts and other files in
chat/socket.io -> nodejs server, in chat/src/index.ts. There is documentation for all used parts in
nodejs-documentation is found on their webpage.
The more modern way to build our api is a REST api by FOS (friends of symfony). The documentation of the REST api endpoints is located at the definition of the endpoints and can be nicely viewed on (https://beta.foodsharing.de/api/doc/).
In the documentation you can read how to properly include the documentation. A good example can be found in
All php classes working with REST requests are found in
This is configured in
There it is also configured, that calls to
/api/ are interpreted by the REST api, e.g.
This is being called when you click on a conversation on the „Alle Nachrichten“ page.
@Rest\Get("subsite")specifies the address to access to start this Action: `https://foodsharing.de/api/subsite"
@Rest\QueryParam(name="optionname")specifies which options can be used. These are found behind the
?in the url:
http://foodsharing.de/api/conversations/687484?messagesLimit=1only sends one message.
QueryParamcan enforce limitations on the sent data with
requirement="<some regular expression>".
@SWG\Response, ... create the documentation (see above)
Functions need to have special names for symfony to use them: the end with
They start with a permission check, throw a
HttpException(401) if the action is not permitted.
Then they somehow react to the request, usually with a Database query via the appropriate Model or Gateway classes.
During running php, the comments get translated to convoluted php code. REST also takes care of the translation from php data structures to json. This json contains data. Errors use the error codes of http-requests.
/src/Services we have services.
/src/Sockets, we have sockets. We use them to reduce the use of