I have http compression turned on in my production IIS box. Is there a way to turn it on in the Cassini web server (that comes with VS200x)?
The reason for this is that I am getting slanted performance results and would like the bandwidth in my dev environment to mirror that of production.
Is this possible?
the only way I know how to do it is ff you implement your own Compression Module that handles this directly instead of relying on the server you can get compression out of Cassini. If you want the server to handle this for you transparently, I don't think Cassini is built or designed for this.
You can verify for yourself that it isn't possible, the source code is public.
Obviously you are not following the best practices.
You need to set up a test environment after the dev phase. This test environment must be exactly the same as your deployment box. Then you can simulate traffic to the test box in order to find issues. Once tests are done, you can start to deploy.
Cassini is only for dev purposes, so it is meaningless to bring it for test purposes.
Related
I have been using webpack to build a server side app using express. This code is harder to debug since I don't have the immediate comfort of a web browser and if I use something like VS Code to debug, it won't accept breakpoints inside request handlers when using source maps. Besides it takes no time to compile if I just stick to Node compatible JS and skip all transpiling and whatnot. Further, if I use treeshaking, I can reduce the size, but what is the point of that when it is running on the server (no client will ever download it).
My point is that I don't see why one would want to create a bundle of server side code if the server don't have any issues with memory or other limiting factors. It's easier to read, takes no time to compile and is easier to debug.
So a question. Is it ok to have the server app as an npm package and deploy that? Is that what is common or what do people do?
The project my team works on is a TypeScript monorepo that includes a web application and server-side daemon processes. We use webpack for producing build artefacts for all targets.
I've read some posts saying there's no point using webpack server-side because it was designed for web (obv), and I can understand that point of view.
However, even if our code was JavaScript and didn't require any transpiling, we'd still use webpack for the server-side. I want a single, minimal set of files and no node modules to deploy to the servers.
Size itself doesn't matter that much for server side (though every bit helps), but running 'yarn install' on servers is out of the question IMO.
We are using Angular for front end and Node.js for backend. We are in conversation with a client to run our application on their local server, hence if we could use a package executable of the application, it would not give them access to our source code. We want to know if there are any robust tools that can help us do this or if there is any other way in which we can allow them to use all our application's offerings without giving them any idea of how the application works technically.
I think you have next options
compiles your backend part into a single executable file nexe
encode your critical parts to weird format weird
run your backend part in docker after minifier/compressor tool minifier
compiles modules to binary format binary
mix all options
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!
I have two differents apps using a gruntfile.js and a package.json and when i launch locally my second app (providing only 1 functionnality, thats why i trying to merge it with the other), this works, but when i try to works the functionnality by merging the second app in the principal app, it says that modules are missing.
My principal app is the BPMN editor from: https://github.com/bpmn-io/bpmn-js
And the second app is the BPMN-diffing from: https://github.com/bpmn-io/bpmn-js-diffing
My BPMN_editor's Gruntfile is minifying BPMN_editor's .js files, then i tried to do the same for BPMN diffing's js files. but nothing is working, my node server wont run normally (while hes working without this BPMN diffing).
I dont understand how to use the bpmn diffing, should i make an npm install to install all dependencies of bpmn diffing, and then make an npm install of the bpmn editor to install dependencies ? or should i merge the Gruntfiles and the package.json files ?
Thanks a lot
Fantemis
If they are based upon two differrent configurations, I would prefer using a load balancer or a reverse proxy to load them on the server. Merging the projects takes a little more insights from you and a little effort. The effort always depends on the setup. I would give you a little tip, but I am not seeing a Gruntfile in your main principle repository.
A little insight into "Reverse Proxy vs. Load Balancer"
What is the difference between Reverse Proxy and Load Balancers
Alternative 1 (preferred):
You could however create a small node.js server, which is handling the serving of those two applications, like the following:
- bpmn_root
|- principal
|- diffing
Afterwards you just need to write a little script, that is building both things on the server you want it to be deployed, and then you just need to do node SCRIPT_NAME.js.
Further reading, and another post about this.
Alternative 2:
You can use Docker. I am not very aware of how to use Docker to power such thing, but it is "as simple as" creating an Nginx configuration, which is doing the reverse proxy stuff for you.
Alternative 3:
Using the load balancer, which is handling the reverse proxy automatically. This is also a little more complex and needs some more learning to do. You can find plenty of tutorials on this however on the internet.
I have an Angular4 web app, deployed on Azure. Now I want to deploy this app to other environments on Azure: one for testing, one for acceptance and one for production. Every environment has different API endpoints and may have other variables, like Application Insights. All those environments run Angular in production mode.
The way Angular advises you to do this, is by the Enviroment files (environment.test.ts, enviroment.acc.ts, environment.prod.ts). I could configure all the different API endpoints in those files, and run my build with --prod for production for example.
But that is not the way I want to do this. I want to use the exact same application package deployed to test for my acceptance environment, without rebuilding the project. In Visual Studio Online, this is also really simple to configure.
The point is: how can I make my API endpoints differ per environment in that way?
The way I want to do this, is by the App Settings in Azure. But Angular can't get to those environment variables because it's running on the client side. Node.js is running on serverside and could get those App Settings - but if that's the way I need to do it, how do I make Node.js (used in Angular4 CLI) to send those server variables to the client side? And what about performance impact for this solution?
How did you fix this problem for your Angular4 apps on Azure? Is it just impossible to fix this problem with the Azure App Settings?
For everyone with the same question: I didn't fix this problem the way I described above.
At the end, I did it the way Angular wants you to do it: so rebuild for dev, rebuild for acc and rebuild for prod.
In Visual Studio Online, at build time, it builds and tests our code and it saves the uncompiled/unminified code. At release time, it builds en tests it again and releases it to the right environment with the right environment variables (--prod for example).
I don't think there is another way to fix this.
The solution is pretty old school but it works! Although you can use branching or tag for this purpose instead of cloning the code to the package.
The best solution as you said is Azure app settings will be saved as environment variable so you should implement an API with node.js and share the variables you want.
Of course there is an impact because of additional http call, but it's just one time at application start which is about max 5ms and depends on each program policy whether is impact or not.
Another option could be move the variables to the JSON file in the asset folder, and change it at deploy runtime with release pipeline. that's easier implementation but the disadvantage is you will have to use release variables instead of app settings and if you have config changes you will have to update the variable value first and redeploy it, although that works most of the times but sometimes you want to change just like a connection string and you will have to redeploy.