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.
Related
I recently started building a small project with TypeScript. It is a small application that runs some workflows based on received Webhook calls. This means that it exposes an Express app to handle these requests.
Currently I have an npm script that builds this project and transpiles it into JavaScript which can be then interpreted by Node.js. (The script runs: tsc --build --clean)
My question is, since this is not meant to be a library/package that will be published on NPM, is there any reason to transpile the project at all since I can just run it with ts-node?
I've been looking around for some information regarding this but couldn't find anything.
Are there any security, performance or any other implications when running the project directly with ts-node in a production environment instead of building it and running it with node?
It depends on the size of your project. Most people transpile because it improves performance, consumes less system resources and provides more stability.
But in a small project this won't make much difference, so using ts-node may be sufficient.
I have a node.js application that run as a application server.
It is deployed on an Ubuntu 20.04 machine running on AWS, uses nginx as a reverse proxy and PM2 as a service starter.
Everything seems perfectly configured.
What looks strange to me, is that I have a React application, in a similar environment, but, before to move it on the server, I run build it, so creating a sort of packed and not easily human readable application.
My question is: Is there the need to do the same with a node.js application?
And, in case of positive answer, How to 'build' a node.js application?
There is no need to build a normal nodejs application.
What you mean is the use of a bundler e.g. webpack and a javascript compiler e.g. babel. To create a react application, you usually use a tool like create-react-app that sets up all this stuff for you. For react you need the compilation beacause you use the jsx syntax that browsers do not understand. In addition to that a bundler has some more advantages.
Check out this video if you want to know more about it:
https://www.youtube.com/watch?v=5IG4UmULyoA
No you don't have to build anything for node.js you just have to run the server. for client side apps you need to build and serve the Dist through web servers like apache or nginx.
Seeking some ideas on how to better improve my teams local development workflow...
We have a Vue CLI shell application project that runs locally via node. Then we have a number of small Vue CLI web-component applications that served up via node.
When the shell is ran it reaches out to each web-component application retrieving a manifest.json file which tells the shell where/when to display the respective web-components.
Our web-component applications are built using something like...
vue-cli-service build --target wc --name foo 'src/components/*.vue'
Having to continuously build the web-component projects after making a code change... debug... and then rebuild again seems cumbersome. This is a new application so at the moment the codebase is in constant flux.
Was hoping someone may have suggestions on how or tools we might use to increase our productivity.
Don't overcomplicate things.
Here's Nuxt.js
As far as I can tell it does everything you want to do straight out of the box. Just set up a basic hello world project with Nuxt and see if it does everything you need it to do for you. It uses Vue.js and Webpack to build the exact same type of application you'd be developing otherwise with Vue, it just has a nicer layout and easier workflow in general. It supports hot reloading on file changes, you'd just run nuxt in the root folder of your project and a local server is started that hot reloads your project whenever you save changes to a file. You then distribute it either as a static application with nuxt generate or build it as a server side rendered application using nuxt build and nuxt start.
So I'm new to Vuejs and doesn't know anything about npm, node, and other javascript apps.
I wanted to switch to VueJS so that I can take away from JQuery. Been using AdminLTE for my projects before.
I wanted to use vue-admin now since it seems to address all of my needs. However, I have specific work area situations that seems to hinder learning Vue and other JS apps, these are:
The workspace folder (development) where I'm creating applications is hosted in the production server (Windows Server).
I think NodeJS isn't installed in the server
Adobe Coldfusion is used. I don't have a local server, so the production server is used when developing.
Question:
Will the production server run the app built with vue-admin even if the production server doesn't have NodeJS installed? (I have NodeJS locally).
I need to use Coldfusion for the logic of the application, specifically I'm using CFWheels right now and vue-admin for Frontend and UX. Is it possible? The application I'm making is closely related to parts of an ERP system.
Any pointers on how I could do this?
Yes you can. Most likely you will need NodeJS locally to make your development life a bit easier.
You can simply include Vue in your project with a script tag or your can use a buildtool like Webpack to enable you to write ES6 and use a module system.
If you go with the latter it still exports as plain ES5 allowing you to use it on your server without any problem since all of this is code which runs on the clients machine, not on your server.
As you can see the requirements for this project have a big bold headline with: 'Development'.
https://github.com/vue-bulma/vue-admin#development
You don't need any of the requirements in production.
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.