How to make sure javascript and css is cached in Angular app - javascript

I am reasonably new to angular (5), and have noticed that the javascript files (vendor.bundle, main.bundle, etc) are being reloaded each time I visit a page.
Is there anything in particular I should be doing to make sure that these are held in a browser cache after the first time they are loaded?
I guess I would need to add a cache-control header, but am not sure where to put it in the code, or whether this is something that the Angular-Cli could generate

Angular have lib called Service workers, which simply can be installed in cli project by below cli command
ng add #angular/pwa --project *project-name*
Note: project name can be obtained from angular.json
This command do the most required configuration but still some other stuff is needed, Which can be found on the flowing link service-worker confi. but some of this configuration already done by previous mentioned command. but also more configuration may be needed in "ngsw-config.json" file.
But unfortunately i tested this inside spring war and still the big files still downloaded every time without any caching but if i deployed on http server direct it work perfect.
Inside Spring War Result
For More Info. Please Check the blob of Angular Service Worker - Step-By-Step Guide for turning your Application into a PWA

Related

Fundamental Understanding of Node JS in the front end

Some things to know:
I understand how to make a HTML / CSS / JS website.
I understand how to make a Node JS app and host it on Heroku
I encountered a problem that was very confusing and I still working it out. I am making a firebase project using their latest tree-shaking V9 SDK
import { initializeApp } from 'firebase/app';
I understand Node JS is meant for backend (it can't be run in a browser) so how am I supposed to "build" this into something that I can reference in a script tag? I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Developer Testing:
How would one live preview this Node JS app on a localhost if Node JS can't be run in a browser? I would live to be able to preview this Node JS app and quickly make changes if that's possible.
I've heard of webpack but that requires you to run npm run build so how is that practical in any way? That would mean every change I make I would have to build it?
Yes, that's the general idea. You make changes to script files on your local machine (or network), and then in order to see the changes take effect, you rebuild the app so that a new bundle is generated. This bundle can then be hosted on your web server or development server, and once it's there, you can refresh the page to see the differences.
But almost all of this can be automated, resulting in it not really being much of a chore at all.
Nodemon is a popular tool that watches a directory for changes and can run Node scripts when a change is detected. With it, you could, for example, make a change to a file, and then it'll automatically rebuild your app.
For Webpack in particular, there's webpack-dev-server, which can automatically refresh a page when the app gets rebuilt.
So, during development, the workflow can be as simple as - make a change, then alt-tab to your browser (hosting the app on localhost) to look at the changes.
Bundles built for the purpose of eventually hosting them on the front-end can easily incorporate Node modules - the build process can take the code from the module, and the bundle produced can include that code. This sort of thing is extraordinarily common.

NodeWebkit - deploy the application

I have one code base for both Web and NodeWebkit (NW) application.
I use the following stack:
- React
- Hapi
- Sequelize
- Windows environment
Web version of the application uses MySQL, while NW uses Sqlite. It all works fine. I have config file that compiles application for what I need (web or NW).
The problem that I face now is how to deploy the NW application. Idea is to provide NW applicaiton to a client, where he will open it clicking the icon.
Since I use the Node for the NW version, and the application uses many modules which are stored in node_modules, I face a challenge how to pack it all up.
My idea is to make an Windows installer. User will click it and the installer will extract all files to the destination. And also make an icon on the user desktop to run it.
Problem is with the Windows file name limitation. Inside the node_modules, there are many subdirectories that simply violate the Windows limitation. I cant even copy the node_modules folder. I cant even delete it. Well sure I can copy it If I zip it... or remove manually long folders.
I have not yet started working on the installer, but I am thinking I will hit the wall with this approach.
Does anyone have an idea how to make this deployment?
How can I integrate NPM3 in NW?
My plan now is to make Windows installer. That windows installer will install normally application files. The node_modules will be zipped previously and placed inside the installer. Installer will then simply unzip it to the destionation folder.
I will post my progress here.
Some update here.
Main issue here was the depth of the node_modules. I have many modules in node_modules, and after some thinking I figured out there is a simple rule there. Some modules are server side modules, while other ones are used by react.
And since Webpack already creates a huge files in which all of the modules are already included, I simply do not need them at all.
So I have removed all front end side modules(babel modules, react-*), and left only server side (Hapi, sequelize...). Miracle happened, application run and was much faster at the startup.
I am going to use Inno setup to make a manifest file, and it should be good to go.
I am still not out of the danger zone, as developer might need a server side module, which has huge depth. But I will think about that if it happens.
More to follow...
actually in nodejs you can do the following:
1-Create another folder inside your project folder for example "server_modules"
2-In the created folder create another package.json file and install any modules needed for server out there
3-All these modules will be accessible as normal node_modules using require('module_name') and you can delete "server_modules" folder when you package your desktop version if you don't need it
Note: this approach used by some developers to achive micro services in nodejs but it is useful in your case

Sails.js run asset pipeline on js file change

I understand when I run sails lift that the grunt tasks will run and put my assets in .tmp/. However, if I'm doing local development and want to make changes to some files in assets/js and refresh the page in the browser and see the updated code it seems I have to stop the server and re-lift the app.
I know there's a grunt watch task configured, and it seems like that is intended to handle this kind of thing. My questions are:
is the watch supposed to handle (for example) .js file changes and deliver the re-compilied/minified/concatenated/whatever'd scripts to .tmp/ without restarting the app?
if it is supposed to work like that, what common things should I check to troubleshoot why it's not?
As a side note, I'm running it with forever and simply ended up omitting **/assets/** from my .foreverignore file from what was listed in this answer. However, that still has the issue that the whole app is restarting when really I just need the asset pipeline run on change.
I disable Grunt during development and works fine for me.
This is how my .sailsrc looks:
"hooks":{
"grunt":false
},
"paths":{
"public":"assets"
}
Documentation:
http://sailsjs.org/documentation/concepts/assets/disabling-grunt

How to use New Relic with ember-cli?

right now I'm running an ember-cli application on heroku by serving it with the ember server command (not sure if this is the best method) and I'd like to integrate it with New Relic, but I have no idea how to do it.
Careful, ember server starts a live-reload server for development purposes — you edit a file, save it, and the application gets rebuild in an instant — you should not use it to serve an Ember app in production, it's a potential security risk. Normally you run ember server only on your local computer where you develop the code.
For production, build your app with ember build --environment=production, that will create a set of static files in your project's dist/ directory. You can upload these as you would upload any HTML/CSS/Javascript.
Keep in mind that Ember (and other frameworks of this kind like Angular and Backbone) is a single page application (SPA) framework; there is no server-side code at all, it all runs in the browser. Usually you would provide some sort of API (like a REST-API) on the server to provide and process data from a database or to provide other server-side services. That way you can develop the front and back-end separately.
I'm not too familiar with New Relic, but as far as I can tell it is analytics software that runs on the back-end, so it has nothing to do with your browser-side framework.
At the server folder, just find the index.js file and add require('newrelic'); at the beginning of the file. Of course you should also follow the instructions when you setup New Relic at you Heroku App, setting your application as a node.js app, which means you'll have to run npm install --save newrelic, go to your node_modules folder, find newrelic, copy newrelic.js file to the root of your application and edit the file with your app_name and license_key.
I recently removed my code from <meta ... in app/index.html and started to use this addon Ember-new-relic.
Get the JavaScript snippet.
And add it below <meta http-equiv="X-UA-Compatible"... in app/index.html.

Bundler for javascript, or how to source control external javascript files

I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).

Categories

Resources