Seperate frontend from backend #420
Replies: 2 comments
-
Hello! Thanks for your interest in the project. Comments below.
The front end of paperless is built with Angular, and that framework apparently has some support for PWA and service workers. See https://angular.io/guide/service-worker-intro, but I guess you already figured that out :) I don't know anything about that topic and cannot provide any assistance.
So far, I did not consider putting both into separate containers. And yes, that would complicate the setup by quite a bit.
Separating the back end and front might prove difficult. You'll have to figure out how to serve the correct locale, CORS request configuration when they are running on different hosts, and login/logout workflow. Authentication relies entirely on django. The login / logged out pages you see are customized django templates and served as part of django's default authentication framework. The front end is served as a view and only served when successfully logged in. You'll probably have to implement something for authentication if you wish to run the back end and front end on different hosts / in different containers. When I implemented it this way, it seemed to be the simplest and most reliable solution: Use already existing mechanisms for authentication (which is safe and covered by test cases) instead of doing that by myself with token authentication in the front end. Also, document downloads from the API by url work perfectly fine with session authentication.
Localization is done according to the guidelines of Angular. When compiled for production, the entire app is bundled for each supported locale separately. The resulting files are stored in paperless-ng/src/documents/views.py Line 58 in ced6a61 That serves the corresponding version of the front end. The language selector on the settings page will set a cookie that tells the django part of the application which language to serve (hence the required reload). Hope this helps to figure out your issue. Regarding the config files for the service worker: no idea. Addition regarding the assets path: The reason this is unclean is that some users might customize the path to static resources, in which case this line will cause issues.
I'm not entirely sure what the benefit of a PWA is. |
Beta Was this translation helpful? Give feedback.
-
Wow thanks for that long and detailed answer. I did not think of the authentication, that would definitly be the hardest part of a split. And the big benefit of a PWA is that on Android, iOS, Windows and MacOS (reasonably up to date versions). You can than add/install the web-interface as a "native" App, including functionalities that used to be native-App only, such as Notifications and Offline-Support. I have not used Django nor Angular before so, there is much new stuff for me to familiarise myself with. Thanks again for the pointers and your work on this amazing tool. |
Beta Was this translation helpful? Give feedback.
-
Hi I only recently started using paparless-ng and I'm very happy with it.
I'm currently very interested in the topic of PWA and I thought why not use paperless-ng as perfect example for me to learn to build or in this case extend a web-app so that it classifies as a PWA.
There will be many things that I'd need to do but I'm eager to learn. (Handling file crud while offline especially upload and view will be an interesting challenge.)
Now to my question:
Has there been any thoughts about possibly splitting the API (Django/Python) and the Frontend (Angular/NodeJS) into their own Docker containers?
I know it'd be a huge change and would require many people to do a manual migration.
In my (fairly limited) experience splitting the api and the frontend have so far always been worth it.
For reference I worked on the https://github.com/stiftungswo/better-izivi and https://github.com/stiftungswo/better-dime projects during my civil service and in both situations we split the Backend (Ruby/Rails) and the Frontend (React/NodeJS) into their own containers.
The reason for this question is that I have run into problems with the localization of the Frontend and loading of config files for the Service Worker. And then I also saw the comments in the Django code about the unclean solution for the assets path.
As already stated I know this would be a quite big task with big implications so I'm open for questions and inputs.
And if this is not something that you see as useful/viable then I'm curious to why so I can learn more.
Thanks again for the amazing project
Beta Was this translation helpful? Give feedback.
All reactions