Issue
I'll start by mentioning I'm new to angular and I'm new to ASP.NET. I am working on a web app that combines pdf documents into one pdf document. The tool is an angular front end and ASP.NET core back end, and it should support multiple browsers at the same time.
I have got a functioning version of the web app already going, but without the support for multiple browsers. It works as follows:
Submit pdf 1 through the angular app, that posts the pdf to the asp.net backend controller. The backend stores the pdf in a service (singleton service).
Submit pdf 2 through angular app, that posts the pdf to asp.net backend controller which stores pdf in service
Click Combine button in angular app, which posts a request to backend to combine the pdfs it has into 1, and return the newly created pdf to the angular app.
Obviously, the problem here is that I use a singleton service to persist data for the browser: If I submitted pdf1 through one browser, and then loaded up another browser and submit pdf2, and load up another browser and click the combine button, it will combine pdf 1 and 2 - which is obviously not right!
I've been looking into using session data to store the individual pdfs, but ran into a problem in that using session data in SPA applications is not advisable, and with web api is code smell. So I'm wondering what the correct way to tackle this problem is so I can go away and read up on it! How do I go about storing data per user / per browser temporarily in angular web app with asp.net backend...
Solution
I would move away from the singleton having any awareness of session/users/documents/etc and just do activities; it should be pretty stateless.
I am guessing you are persisting them in memory, which is what you mean by in the service, and that can also get tricky. Scaling could become an issue very quickly.
Perhaps there is a technical and UI solution to this? Could you persist the PDFs in a datastore, and then choose which to combine from those in the database in a separate view or page? This would be the cleanest from a data perspective.
However, if you are deadset on the same view and that view/session only being aware of what has been uploaded in that session, you would need to use some sort of identifier as J.Salas mentioned. I would still vote for moving away from storing the documents in memory, but the solution here wouldn't care either way. You can prepend the pdf identifier stored with the session ID and you know which is attached to which.
Answered By - Ben Matthews
0 comments:
Post a Comment
Note: Only a member of this blog may post a comment.