The initial architecture document the project was started from can be found here. +Many things have been added since the original inception of the project, +but the core ideas within that document are still valid.
+As can be seen from the architecture, an important idea is the modularity of all components. +No actual implementations are defined there, only their interfaces. +Making all the components independent of each other in such a way provides us with an enormous flexibility: +they can all be replaced by a different implementation, without impacting anything else. +This is how we can provide many different configurations for the server, +and why it is impossible to provide ready solutions for all possible combinations.
+A very important building block that gets reused in many places is the AsyncHandler.
+The idea is that a handler has 2 important functions.
+canHandle determines if this class is capable of correctly handling the request,
+and throws an error if it can not.
+For example, a class that converts JSON-LD to turtle can handle all requests containing JSON-LD data,
+but does not know what to do with a request that contains a JPEG.
+The second function is handle where the class executes on the input data and returns the result.
+If an error gets thrown here it means there is an issue with the input.
+For example, if the input data claims to be JSON-LD but is actually not.
The power of using this interface really shines when using certain utility classes.
+The one we use the most is the WaterfallHandler,
+which takes as input a list of handlers of the same type.
+The input and output of a WaterfallHandler is the same as those of its inputs,
+meaning it can be used in the same places.
+When doing a canHandle call, it will iterate over all its input handlers
+to find the first one where the canHandle call succeeds,
+and when calling handle it will return the result of that specific handler.
+This allows us to chain together many handlers that each have their specific niche,
+such as handler that each support a specific HTTP method (GET/PUT/POST/etc.),
+or handlers that only take requests targeting a specific subset of URLs.
+To the parent class it will look like it has a handler that supports all methods,
+while in practice it will be a WaterfallHandler containing all these separate handlers.
Some other utility classes are the ParallelHandler that runs all handlers simultaneously,
+and the SequenceHandler that runs all of them one after the other.
+Since multiple handlers are executed here, these only work for handlers that have no output.
Almost all data is handled in a streaming fashion.
+This allows us to work with very large resources without having to fully load them in memory,
+a client could be reading data that is being returned by the server while the server is still reading the file.
+Internally this means we are mostly handling data as Readable objects.
+We actually use Guarded<Readable> which is an internal format we created to help us with error handling.
+Such streams can be created using utility functions such as guardStream and guardedStreamFrom.
+Similarly, we have a pipeSafely to pipe streams in such a way that also helps with errors.
In this section we will give a high level overview of all the components +a request passes through when it enters the server. +This is specifically an LDP request, e.g. a POST request to create a new resource.
+HttpHandler gets found, responsible for LDP requests.ResourceStore gets called,
+ which in the case of a POST request will return the location of the newly created error.ResponseWriter.In case any of the steps above error, an error will be thrown.
+The ErrorHandler will convert the error to an HTTP response to be returned.
Below are sections that go deeper into the specific steps. +Not all steps are covered yet and will be added in the future.
+ + + +\n {translation(\"search.result.term.missing\")}: {...missing}\n
\n }\n \n