Closed Fr3574 closed 1 year ago
I was wondering, maybe for downloading we should do it in BE? A new endpoint where you provide a filterset, which you always anyways have to prepare when saving a trace or you have it already when getting a saved trace.
In that case, when FE would change in the future by udk, it would be still supported?
I think the idea behind doing it in FE was because we already have the data there. In the end is an endpoint which takes a traceId or filterset the more generic approach.
The problem with a backend endpoint is that it would give us 2 routes that both give the same results, creating redundancy. In addition, we would have to provide static files on the backend side, the current variant is much simpler and could also be implemented quickly for another FE.
Okay I see. If we extract our method into a FE-service it's easily reusable. However, if we create the file in BE, later on ZIP-archives could be created of the data. Maybe we should just start with FE and if we run into problems move to BE?
I though this might be a good way of doing it, let me know your thoughts :) Would it make sense to name the files differently, maybe by ID or title?
Closes #127