I'm learning webpack, and this is a theoretical question. For each webpage in a site, I'm planning to make a page-specific module that itself will require a module for site-wide code. I'm planning to use webpack's splitChunks so that the sitewide code is saved to a separate bundle.js. In theory, is this plausible / best practice? I suppose the inverse is possible where the sitewide module is the main entry. Thoughts?
OK I had my a-ha moment. Yes, each page in the site is an entry and needs to be registered as en entry in one main webpack.config.js. When I webpack the site, webpack will automatically split common code into chunks. Since each page will require the site-wide module, webpack will see that common dependency and optimize the chunks.
Related
My searches have turned up nothing concrete. My extension uses Google's file picker to allow the user to browse their sheets and choose a desired file to write some data to, which manifest v3 breaks because of some GAPI limitations. Unless I've missed something obvious, there does not seem to be a simple workaround or method for this to migrate to v3 -- it just seems to be disallowed.
I'm not asking if there's a way to do something that they intend to not be possible (even though I doubt such a thing would exist with Google) but I'm optimistically hoping that maybe there is some hacky/annoying workaround that still fits within their rules. If I absolutely have to just allow them to set a sheet URL manually I will...I'm just trying to avoid it.
Any tips or suggestions would be appreciated.
You may have to test it yourself to make sure there are no weird behaviors, but Google has some recommendations regarding this in their migration guide:
In Manifest V3, all of your extension's logic must be included in the extension. You can no longer load and execute a remotely hosted file. A number of alternative approaches are available, depending on your use case and the reason for remote hosting. Here are approaches to consider:
Configuration-driven features and logic
In this approach, your extension loads a remote configuration (for example a JSON file) at runtime and caches the configuration locally. The extension then uses this cached configuration to decide which features to enable.
Externalize logic with a remote service
Consider migrating application logic from the extension to a remote web service that your extension can call. (Essentially a form of message passing.) This provides you the ability to keep code private and change the code on demand while avoiding the extra overhead of resubmitting to the Chrome Web Store.
Bundle third-party libraries
If you are using a popular framework like React or Bootstrap, you can download the minified files, add them to your project and import them locally.
For your case, option #3 seems like the easiest. Looking at the Google Picker API documentation it only uses two relatively small script files, https://apis.google.com/js/api.js and https://accounts.google.com/gsi/client. You could try to bundle these in your Chrome extension and call the methods locally.
I'm considering integrating nuxt.js into our vue.js application. I'm trying to figure out if it's feasible. By feasible, I mean how much of an overhaul would it require.
I understand that nuxt.js is more than just a pluggin. If it were a plugging, it would be super easy. You would just npm install and Vue.use(nuxt) and that's it. But as a framework, I understand that nuxt.js expects certain structures to be in place. For example, I know from https://hiswe.github.io/2018/12-vue-with-nuxt/ that nuxt expects a certain folder structure (/static, /page, /layouts...), but can these live side-by-side with the standard vue.js folders (/assets, /components, /views...) or do they have to be replaced? If side-by-side, then no overhauling of existing code (just add new folders). Otherwise, there could be quite a bit of work to overhaul the structure.
And if they can live side-by-side, would the nuxt folder supersede the vue.js folders (ex. would it no longer look for components in /components or /views and instead expect them to be in /pages)?
I also understand that nuxt router depends only on the folder/file structure in /pages rather than the router.js file that vue.js depends on. Does this mean router.js will no longer be used? Or will router.js still be used until we tell it not to (by removing certain routes from it, for example).
You don't need to answer the above questions (although it would be super useful if you did). I just provide them to give an example of the things I need to consider. The main question is: how much work is involved in overhauling a vue.js application when nuxt.js is being integrated.
To give some perspective of the size/complexity of our application, you can see it here:
https://www.bodecanada.com/
The source code is just under 600MB (compared to a startup vue.js application which is usually < 100MB). It includes a backend API that connects to a postgres database. We host it on AWS Lambda. We'd like to take advantage of the SSR abilities of nuxt.js but as I understand it, that requires a node.js server (not sure how easily that integrates with our Lambda instance).
^ Those are the specs. Just looking for a rough idea. Easy? Difficult? Thanks for any feedback.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
I'm looking for the equivalent of a URL shortening service such as http://bit.ly/ for an internal deployment in our organisation. Anyone know of any open source projects (especially Java ones) or commercial products which I can install internally rather than using an external service?
Thanks!
Shorty : http://get-shorty.com/
But there's several other url shortener .... most of them are in PHP/Mysql.
Don't know if a Java one exist.
http://monkeytooth.net/2010/12/htaccess-php-how-to-wordpress-slugs/
tells you the core basics of how to achieve the concept with PHP and Htaccess building up from there I can say would solely be on your own. However not all to hard a concept in general to build off of if you know php/mysql. That said your not likely to find anything directly built in JavaScript however using this with JavaScript again wouldn't be all that hard a concept. I say your not likely to find one JS based as you need some type of server-side script to communicate with a DB somewhere, where you have all your short URL identifiers, and JavaScript to my knowledge doesn't support directly at least database connectivity. You can go through any means of AJAX to communicate with a server-side script to then do what you want with the JavaScript though.
I'm building an application with a self-contained HTTP server which can be either accessed directly, or put behind a reverse proxy (like Apache mod_proxy).
So, let's say my application is running on port 8080 and you set up your Apache like this:
ProxyPass /myapp http://localhost:8080
ProxyPassReverse /myapp http://localhost:8080
This will cause HTTP requests coming into the main Apache server that go to /myapp/* to be proxied to my application. If a request comes in like GET /myapp/bar, my application will see GET /bar. This is as it should be.
The problem that arises is in generating URIs that have to be translated from my application's URI-space in order to work correctly via the proxy (i.e. prepending /myapp/).
The ProxyPassReverse directive takes care of handling this for URIs in HTTP headers (redirects and so forth.) But that doesn't handle URIs in the HTML generated by my application, or in static files and templates.
I'm aware of filters like mod_proxy_html, but this is a non-standard Apache module, and in any case, such filters may not be available for other front-end web servers which are capable of acting as a reverse proxy.
So I've come up with a few possible strategies:
Require an environment variable be set somewhere that contains the proxy path, and prepend this to all generated URIs. This seems inelegant; it breaks the encapsulation provided by the reverse proxy.
Put the proxy path in a configuration file for my application. Same objection as above.
Use only relative URIs in my application. This can get somewhat tricky; I would have to calculate the path difference between the current resource and where the link is going and add the appropriate number of ../'es. Seems messy. Another problem is that some things must generate absolute URIs, like RSS feeds and generated emails.
Use some hacky Javascript on the front-end to mungle URIs in the document text. This seems like a really horrible idea from an interoperability standpoint.
Use a singe URI-generating function throughout my code, and require "static" files like Javascript, CSS, etc. to be run through my templating system. This is the idea I'm leaning towards now.
This must be a fairly common problem. How have you approached it in the past? What has worked and what has made things more difficult?
Yep, common problem. How to solve this depends on the kind of app you have and the server platform and web framework you're working with. But there's a general way I've approached these problems which has worked pretty well so far.
My preference is to handle problems like this in application code, rather than relying on web server modules like mod_proxy_html to do it, because there are often too many special cases (e.g. client-side-javascript assembling URLs on the fly) which the server module doesn't catch. That said, I've resorted to the server-module approach in a few cases, but I decided to revise the module code myself to handle the corner cases. Also keep perormance in mind; fixing up URLs in your code at the time they're generated is usually faster than shoving the entire HTML through another server module.
Here's my recommendation of how to handle this in your code:
First, you'll need to figure out what kind of URLs to generate. My preference is for relative URLs. You are correct above that "add the appropriate number of ../'es" is messy, but at least it's your (the programmer's) mess. If you go with the config-file/environment-variable approach, then you'll be dependent on whoever deploys your app (e.g. an underpaid and grumpy IT operations engineer) to always set things up correctly. It also complicates release of your code, even if you're doing deployment yourself, since you can't simply copy your development files into production but need to add a per-deployment-environment custom step. I've found in the past that eliminating potential deployment problems is worth a lot of pre-emptive coding.
Next, you'll need to get those URLs into your code. How you do this varies based on type of content/code:
For server-side code (e.g. PHP, RoR, etc.) you'll want to make sure that server-side URL generation happens in as few places as possible in your code (ideally, one method!). If you're using any of the mainstream MVC web frameworks (e.g. RoR, Django, etc.), this should be trivial since URL generation using an MVC framework already generally goes through a single codepath that you can override. If you're not using one of those frameworks, you likely have URL generation littered throughout your code. But the approach you'll want to take is to generate all URLs via code, and then override that method to support transforming non-relative URLs into relative URLs. You can usually search for patterns in your code (like "/, '/, "http://, 'http://) and do a manual search and replace (or if you're really nerdy and have more patience than I do, craft a regex to replace each common case in your source code).
The key to making this work reliably is that, instead of manually replacing all absolute URLs with relative ones in your server-side code (which, even if you get each of them right, is fragile if files are moved), you can leave the absolute URLs in place and simply wrap them with a call to your "relativizer" method. This is much more reliable and unbrittle.
For Javascript, I generally like to do the same thing as server code-- move all URL generation into a single method and ensure any URL generation calls this method. This can be hard on an app with lots of pre-existing javascript, but the search-and-replace method above seems to work well in JS too.
For CSS, URLs in CSS are relative to the location of the CSS file (not the calling HTML page) so using relative URLs is generally easy. Simply put your CSS into a folder and either put images into deeper folders beneath it, or put images into a parallel folder to your CSS and use a single ../ to get to the images relatively. This is a good best practice in general-- if you're not doing relative URLs in CSS already, you should consider doing it, regardless of reverse proxy.
Finally, you'll need to figure out what to do for other oddball static files (like legacy static HTML files sometimes creep in). In general, I recommend the same practice as CSS and images-- ideally, you'd put static files into predictable directories and rely on relative URLs. Or (depending on your server platform) it may be easier to remap the file extensions of those static files so that they're processed by your web framework-- and then run your server-side URL generator for all URLs. Or, barring that, you can leave the files in place and manually fix up URLs to be relative-- knowing that this is brittle.
Coming full circle, sometimes there are just too many places where URLs are generated, and it's more effective to use a server module like mod_proxy_html. But I consider this a last resort-- especially if you won't be comfortable editing the source code if needed.
BTW, I realize I didn't mention anyting about your idea #4 above (javascript-link-fixup). I wouldn't do that-- if the user has javascript turned off or (more common) some network problem prevents that javascript for some time after the rest of the page loads, then your links won't work. Too risky.