How do I extend the duration/cancel timeout all together?
I've tried searching the project for related terms like time, and session, but everything seems to be configured in the auto generated vendor and bundle files, and I'm afraid to make changes in them, with out knowing for sure what I need to do.
Related
I have cloned a git repo regarding the swagger framework for API documentations. It is an already built project, ready to run.
However, I would like to effect some styling changes, hide certain elements and tweak with the default links and examples it provides. Indeed the changes have been easy, but by saving them and re-running the project as a web app they were not visible. It is my understanding that one has to rebuild a project in order for changes to come live. It is a React app, running on node.js, so I proceeded by following the script commands within package.json and rebuilt the project.
Still, although the changes have been saved within the dev files, they are not visible within the web app. Inspecting the DOM elements of interest confirms that no changes are in effect. My question is whether I can rebuild this project so that the changes will eventually become available, or if there is another way to achieve this.
I've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
So, here's the situation. I've recently "inherited" a decent sized web application, built using React (and Redux) and compiled using webpack/babel. Two files are generated, app.js and server.js, both of which run on Node.
The original developer of the project was mostly "winging it" on the back-end (server.jsx and so on -> server.js), using console.log to figure out what was going on, and then just gut feeling the fix. That works on a smaller scale, but will be problematic in time.
I can debug both of the actual files, but only app.js is ever mapped properly, meaning I can debug the source code. This also affects hot loading. Any breakpoints related to server.js will only trigger in the actual server.js file in IntelliJ, which is a completely unreadable mesh, so that's not really an option.
I'm using IntelliJ (WebStorm for those of you who only use the web version), and I've tried to use every single guide I've come across to set it up, which usually comes down to babel-node, babel watchers or webpack-dev-server. The current app.js is run using webpack-dev-middleware, and debugging it in Chrome works like a charm, but for some reason it always just bundles in server.js and then fires when ready (in these Star Wars times).
I understand that it's hard for Chrome to get access to server.jsx, but surely there must be some way of setting up IntelliJ (or WebStorm) to do so? I'm more used to a Java or C# server side, so I'm a bit baffled that this isn't a straight forward, out-of-the-box option. Or maybe it is, and the initial setup is lacking?
PS. When using React (and Redux) as both the front and back end on Node, is it meant to be virtually impossible to distinguish between the two? Server.jsx is fairly obvious, but there are quite a few duplicated javascript files and dependancies, especially related to handling/building the Redux store.
I have a lot of files in my assets/js directory. At first I thought I was somehow losing the ability to see/serve files from sails. But after I let sails run for a little while, it seems sails found my files in the assets/js directory and I was able to run my intern tests. I'm assuming there is some type of behind the scenes cache going on that must run before I can successfully make a request. Is this the reason, and if so, how can I disable it for a more instant access to my files?
Sails.js needs to do several things before lifting the server, you can try sails lift --verbose to see what's happening.
Also, if you dont mind, take a look the .js files under tasks/config/, Sails.js uses them to link/copy/build assets before starting.
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