I have offline caching with a NextJS PWA working fairly well by following this post.
Now what I need to do is precache a set of routes (in this case all the descendents) without the visitor needing to visit every one individually (in some cases 100s of routes and media files).
I have been able to define precache pages at build time, and cache pages that are visited, but not been able to find or understand how to interactively set an offline cache. Can someone please point me in the right direction?
Related
I have 2 different sites basically. 1 is a rest api, the other is the front end built in vue.
Actually uploading a file isn't the issue. My question is how to have the Vue portion access the files that were uploaded via rest.
Should I save the files to c:...VueProjectFolder\images (could use some code help if this is the case)? Or should the Vue site be inside the rest api folder for relative access? Or is it better to save relative, then move the uploaded files? Or do I have vue access the files via the rest api address?
None really seem like the right answer and I'm failing with google atm.
Down the road, I would expect them to be served from a mapped drive as there will be many. Mostly images, but also sound files.
This is probably not a Vue or 'two sites' issue. This is an architecture issue, and like such issues, It depends. What I can do is tell you how I approached a similar situation.
I uploaded the files normally
I renamed them, created a folder structure based on the year, month, and day the picture was uploaded. Then I moved the image to the permanent location. So an image uploaded today will be located at .../assets/images/2020/09/01/randomImageName.png for instance.
I stored the image location along with whatever resource came with the uploaded image in the database.
Now in my frontend, I do a normal api call for a particular resource and it spits out everything about that resource, including the image location.
I think I should point out that my case was an ecommerce website with a REST API endpoint servicing the frontend requests. Generally this approach is advised since you can take advantage of backing up the image directory, backing up the database and easily moving between servers if need be.
This may not exactly be your case, but I hope it gives you insight into how to approach this efficiently.
I was reading this guide on offline storage for PWA's that described two storage API's, the Cache API and IndexedDB, however it seems that neither storage option is truly persistent. The Cache API is temporary by design, and the IndexedDB data can be wiped when the user clears their browser cache.
So, is it possible to have truly persistent storage in a PWA? What I'm trying to do is this:
User visits my website on their smartphone and I generate a unique ID in JavaScript.
They press "add to homescreen" on iOS or press the "add to homescreen" bar on Android.
The PWA gets added to their phone. At this point, I would like to store that unique ID persistently.
Is there any way that I can do so? Maybe an API that I don't know about? I only need a tiny unique code, since this PWA is not designed to have users log in with cookies.
No
The user can delete the PWA (if installed on Android) and clear their browser's cache of everything from your PWA.
Then if they visit again you would need to generate a new ID for them.
But you would know nothing of their previous ID if you have no login back end tied to unique users.
As Mathias already stated, it is not possible to achieve your goal with just PWA, as the user can wipe all the previously generated data.
So, long story short, you must use some other solution to ensure "truly persistence storage".
For example in a personal PWA Project of mine, I use Cloud Firestore. It offers also a very generous free tier you can use and it even allows offline persistence, granting full CRUD operations to your application (even when offline!).
Service Workers, through the Cache API, allow to cache only GET Requests, but no POST.
I wrote another answer about this on SO. And here you can find the official documentation.
I am trying to figure out how to run an A/B Test for a change on a Page Step for a Single Page. The idea is we have a payment flow with several page steps each containing a form. We'd like to swap out forms and test how our users react. We are trying to avoid changing the URL.
I looked into tools such as Google Analytics, but that requires a different URL to run the A/B test. The hesitation about creating a new URL is because our users are known to bookmark them, and we don't want to keep a backlog of redirects from invalid URLs, also we'd like to avoid constantly deploying new URLs for our tests.
I cannot seem to find any tool to do this, so I've tried to think of a few solutions but I'm not having a lot of luck.
My best idea is to build both a and b forms into the page, and when a user accesses the flow, the session randomly(based on a preset%) stores a value that dictates whether the user is in test a or b. Then when they step into that form, the server will serve the proper form to them. If they abandon their session, we'd track that, and if they complete the action, we'd track that.
I feel like there should be a better solution, but I just cannot come up with one.
My results online were either blogs showing how to approach it from a high level, and all of them used different URLs, I have found almost no developer resources.
Thanks.
We're using ExtJS 4.2.2, and .NET as our server.
Whenever you need the server to be involved, you need server-side instrumentation. No free tools offer that, but you could consider Optimizely "full-stack" (has support for C#) or Variant (does not yet).
I had an idea about website vulnerabilities, and I would like to know if it is possible. Also some suggestions on how to fix them.
If some part of my website writes data to the DOM and then calls the data back from it, would it be possible for someone to “hack” the server by editing the DOM in the browser?
For example, suppose I have some radio buttons. Each button has its own logic associated with it. If I remove one of the buttons, but fail to remove or comment out the logic, could someone go in and edit the DOM name of one of the buttons to the removed one, and upon submission have the server execute the logic associated with the removed radio button?
I understand how to fix that situation, by removing or commenting out the removed button’s logic, but I fear my site relies too heavily on such things that could be manipulated via the DOM. Hence, I’m wondering:
Is such a thing possible?
Is some complex validation method the only way to prevent “hacks” of this nature?
The answer to your question is yes. For example in many browsers you can open a javascript console and change not only the DOM but also the javascript on the site.
There is no guarantee that the code you write for a webpage will be run as you code it. Any user can change their copy. What they should not be able to do is change other people's copy. When they do this is called a cross site scripting (XSS) attack. (Typically done by adding script to a field which is saved in a database server and then served to another user.)
To protect your site you need to ensure that all web service calls are secure -- that is a user can't call them with malicious data and cause problems.
You also need to block against SQL injection attacks.
There is NO way to protect against a user changing the web page on their machine and having it do something you did not intend, so all validation needs to occur both in the browser and on the server.
As an example of how easy it is to change the local browser behavior, consider the browser extension. A browser extension is a pre-coded way to change the way web pages act locally.
(Think about ad-blockers as a specific example.)
I know this is similar to other topics, but I've not yet found a satisfactory answer.
I have a GWT / GAEJ application that essentially allows users to interact with the web app as if it were a desktop app. i.e. they login, and use the application in full-html mode (i.e. the GWT app occupies the entire html page). They are typically power users and so don't mind a few seconds dowload / login time when starting to use the app. Typically they might stay logged in for several hours.
I would also like to make available some small subsets of functionality, pointing to the same Back end, as widgets to be included in OTHER existing websites. I know one of the features of GWT is that you can either embed your GWT into existing html pages or go full page.
My question is how do I partition the GWT components into small tidy parcels so that only the relevant bits are downloaded for these embedded 'widgets' whist not having to duplicate my backend code. (for example I could create a new GWT project write only my small widget and copy the server side code - but I really don't want to do this!) Each widget still needs to interact with the same backend so none of them will be stand alone GWT. Communication is GWT-RPC.
anyone done this?
Seems like you want to split your GWT stuff into multiple GWT modules that you want to later combine in possibly more than one project. One way is having a multi-module maven setup (gwt-maven-plugin), there's no need to copy/paste code.