Here's the only solutions I've come up with (don't know if they're the adequate though):
Server-side updates:
Version every client request and have the proxy route to the
appropriate server version.
Cient-side updates:
Notify the client over a websocket connection to re-inject the
script/style tags after X number of idle minutes thereby invoking 2
ajax requests for updated JS/CSS files and refresh the HTML of the
page.
I don't know if this is something that shouldn't be a priority in the early stages of the app and I should just take the entire app down for "scheduled maintenance" in the early hours of the morning.
For SEO purposes, the front page's HTML is sent by the server along with the single JS/CSS file.
I think the Right Thing (tm) is to make build your single page application in a way where it consumes RESTful API which is public quality. In other words, think about it as if you are publishing your API to the world and when making changes make them backwards compatible. I think this is not as hard as it might think and will leave you with a cleaner system. Certainly better than building a complex versioning and live patching scheme!
If you are deploying to a tomcat server, you can simply overwrite the .js and .css files in the correct "deployed" location....
copy files to /your/deployed/app/location/webapp/js, etc this is a quick and easy way to "hot deploy" a new JS / CSS w/o taking the server down..... however if you have backend support that also needs to be updated, that may require a restart of the tomcat service. in which case something like Jenkins might help. http://www.tomcatexpert.com/blog/2012/03/21/integrating-jenkins-and-apache-tomcat-continuous-deployment
Related
I need to create an application which will be ran on the browser (local only, not hosted online). I will need to use a lightweight database which has a physical file (eg SQLite3, so I can have a .db file).
Also, just to mention:
I cant use IndexedDB alone to save the data because clearing browser data would clear the entire "database".
I also wouldn't be able to use electron since the bundle is too big. I need the browser for its portability
Also cant use PouchDB, since due to security constraints, online sync (CouchDB, etc) is not possible. Then it would be 100% stored in IndexedDB, which brings me back to my point on bullet 1
My question is - is there a way to create an offline web application build with VueJS frontend + NodeJS backend? I only need NodeJS because SQLite only works on the Node environment.
Deployment is preferably in .html only (is there any way that is possible, and access only using the file protocol file://)? Otherwise, I may consider using a local web server (localhost) - I'm not sure though if it is possible to serve an html file without any installations (node, python, etc), so I would still have to check all my options about this.
Any thoughts?
I am still new to this so please bear with me! There is very limited info online that talks about a 100% offline web application. Thanks a lot!
Folks, forgive me if this is a repeat question: I couldn't think of how to phrase it in the search engine. I'm developing an Intranet-based set of applications with the front end (individual apps) in React and the back-end using node.js and Express. I had been using Electron JS but like the Express solution since all web browsers on the Intranet can use the apps.
I'm running into a bit of a circular dependency when it comes to production, though. Since my REST back-end handles all local calls (like node fs) I use REST calls to load and save preferences files from the front end. However, I'd like to be able to set the REST URI from a config file or setting. Since the only way I can access this setting is a call to the REST back-end, I'm stuck. It's possible the client may want to change the host URL and the port for the server. This will affect all axios calls to the REST back end in every React application I have. Instead of calling http://localhost:5000/api-call/ I'd like the localhost and port number to be read from config.
I am transpiling the React apps and storing them in a static folder underneath the REST server. I would like to avoid something complex or additional like REDIS or another local database. My projects don't require any heavy database setups.
Am I simply implementing poor architecture here? I even thought of env variables but then will get into setting them on each client's system which takes away from the flexibility of using a web server in the first place. Any thoughts to move me in the right direction would be greatly appreciated!!!
I knew if I posted this, I might find an answer.
I'm not sure how elegant a solution this is but I could test the env for development vs. production. If in production, I can then use window.href (host and port) to get the information I need. I think this will work but would still love to hear some other thoughts from those with far more experience than I have!
Firstly I must confess I am a noob at node. I've been using ASP.NET then PHP then Django before. Regardless, I've found node a breath of fresh air. This problem is also not strictly a node problem, but I need a node specific answer.
I have an express server and angular frontend. The server side templates are in swig and currently only serve for error pages and the index page. Mostly the angular templates will make up most of the front matter.
What I'm struggling with, if only only in deciding how to do it, is getting an efficient work flow for the asset pipeline. Server side templates must be able to inject the vanilla of assets during dev and testing. The same for client side templates during testing. Basically, running with express' static middleware should be an option without any configuration (maybe with some helper in server side assets). Thus git clone -> grunt -> viola.
However, during staging and production, I would like the server side files to stay vanilla. The template helpers may parse a manifest file indicating the cache busted links (CDN path maybe too). How to make the link from logical asset bundle name to production ready asset is a mystery for me, while keeping development transparent.
The client side templates may be minified, concatenated, injected or whatever, as it will be saved to some dist folder for uploading. It is important that the whole dependency tree (images, fonts, css, js) must be "exported" to the dist folder.
To deploy would then be: pushing the server side code to the server and running. And pushing client dist folder to some asset host (CDN, nginx, another node, maybe even connect static)
What my question(s) then actually is(are):
Is this workflow possible with tools such as broccoli/gulp/grunt alone?
I've tried connect-assets but I don't want to conform to some predetermined folder path. Also the cli tool didn't produce the other static assets. Perhaps I don't understand the tool.
Am I following the correct approach?
I've added to a discussion on broccoli concerning the manifest file consumption:
https://github.com/mjackson/broccoli-rev/issues/1#issuecomment-49076249
Edit: I forgot to mention that I use bower, so assets should be pulled from arbitrary (URLs too maybe) locations.
I think angular-fullstack is what you want. Even if you don't use it, it does almost all of what you're looking for.
The only thing that it might be missing for you is deployment. It has built in support for Heroku and OpenShift deployment. You could use something like grunt-ssh or grunt-deploy for other deployment scenarios.
After reading the Meteor official documentation regarding this subjet, I would like to know if it's possible to change my code, deploy the new version, but without restarting the node js server? My idea is to have a development server, where I make my updates, and then after testing commit the changes to the real production server, so that I don't break anything.
If this doen't make any sense, what is the current best approach to accomplish the same results?
Thanks a lot for the help.
You should not need to reset the node js server. Any changes to the code will be injected into the client's browser.
From Meteor main page:
Hot Code Pushes.
Update your app while users are connected without disturbing them. When you push a new version, the new code is seamlessly injected into each browser frame in which the app is open.
I am coming from Microsoft world so please bear with me on this. I was told I could install node.js and use that as a web server instead of IIS. This is a very small business application. In IIS I can create virtual directory and point to the location of the web page and everything works just fine. Based on very little I read, I have few questions;
Is it possible to run node js as a windows service or any other form so that it runs for ever? I did find the forever package that I think I can use.
In IIS, I can create virtual directory set the port and thats it, I have myself a website.
I do not see any examples where I can use a directory where I have a web page, written in java script and point it to run as a web site. All the examples have some thing like server.js and that runs and routes the call. what is the other way to host web sites and use node.js to simple run as a fast web server.
I was told I could install node.js and use that as a web server instead of IIS.
This is true, but as you already found out then you are in charge of providing for things that IIS was already doing for you (e.g. automatically restart on reboot, or on crashes, hosting multiple sites by creating virtual folders, et cetera.)
You can indeed get all of these things worked out in Node.js and there are several libraries that help on each of these areas. It's not too hard but you'll need to do a bit of researching.
You can also run Node.js behind IIS. Take a look at iisnode http://tomasz.janczuk.org/2011/08/hosting-nodejs-applications-in-iis-on.html
Is it possible to run node js as a windows service or any other form so
that it runs for ever?
The library Forever takes care of restarting the site when it crashes...but I don't know if you can run it as a Windows Service. I haven't tried that.
In IIS, I can create virtual directory set the port and thats it,
I have myself a website.
I assume you are talking about a site that serves static HTML files, right? If that's the case that's very easy to support in Node.js either writing your own web server or using Express.js to serve static files.
I do not see any examples where I can use a directory where I have a web page,
written in java script and point it to run as a web site. All the examples
have some thing like server.js and that runs and routes the call.
Here is an extremely simple example to serve plain HTML files in Node.js https://gist.github.com/2573391 Don't use this in production, though. It's just an example and it does not have any kind of error handling or security.
what is the other way to host web sites and use node.js to simple run
as a fast web server.
As others have said, you should look into Express.js http://expressjs.com/ It provides some of the infrastructure that you are very likely going to need when building traditional web sites.
You say you're running a "very small business application" behind IIS. Unless it's written for Node.js (in JavaScript), it won't work.
There are no examples pointing to a directory and running that as a website, because that's not how things are done in Node.js. You write a Node.js-application and pull in a webserver-library.
Put simply, In Node.js, you don't embed the appliation in the webserver; you embed the webserver in the application.
When I used node.js, I redirected HTTP requests by a proxy server, nginx. I don’t know if you can directly bind node.js as an HTTP server, but for what’s it worth, nginx is pretty nice!
First things first, allow me to share an introduction. IMHO you should take this decision ( of moving from IIS to nodeJS) by adding various parameters. I belong to the Java & PHP community yet I use NodeJS to achieve extremely specific implementation where NodeJS perform the fastest ( fast IO, AJAX-JSON responses & more ). As you are coming with a Microsoft background you should bare with less comfortable solutions.
Yes, its possible to run NodeJs as a windows service and Forever will do fine.
and yes you can create "Virtual Directories" but by creating symbolic links to each of your customer's web site.
I recommend to take a good look at bouncy & express, If you're willing to take this step then these packages is just what you need.
Cheers!