How should I structure a Meteor project with external scripts? - javascript

I'm curious if anyone has developed a best practice for organizing Meteor applications that contain external shell scripts, or other back-end processes that happen outside of the node.js server code and the client side js code.
For instance, I have a meteor app that is structured like this:
project-name
client
lib
models
packages
public
server
I have a shell script that processes some external data sources, and a Python script that does some other heavy lifting. These all then help by inserting new data into the Mongo instance. Yes, I know that's a bit of a jumble, but so are the backend data systems. My question is should I put these sorts of projects within the meteor app folder, or should they live outside of the system? Just curious how others are structuring apps like this.
Option #1
project-name
client
...
server
data-processor.sh
other-utility.py
Option #2
project-name
client
...
private
data-processor.sh
other-utility.py
Option #3
bin
data-processor.sh
other-utility.py
meteor-project-name
client
...
private

You shouldn't put any non-meteor files inside your meteor project directory, all of those CAN be picked up by some package, even if standard meteor-platform packages don't recognize the extension. So putting them in the /server might cause problems in the future. The /private folder on the other hand is meant for resources used by your application, so placing the scripts there is unsemantic and inelegant.
To avoid moving those scripts outside of the project folder you can store them inside a hidden directory, that is any directory with name starting with a dot, i.e. /.scripts. Files placed there will not be picked up by Meteor application.

Related

Where to install webpack using client/server folder structure

Im building a React Nodejs web application and Im trying to understand how to bundle the frontend with webpack. [
This is my project structure
Where should I install webpack and configure webpack.config.js? Most of the project structures I have seen put the frontend folder inside the backend folder, also in some projects they also bundle the backend separately. Can someone give me an explanation on where to implement it with this folder structure? I'm really confused
This article was kind of getting to the point but didnt solve my question
Webpack should be part of the frontend repository, so it should go into the frontend/package.json. Similarly, just like frontend/eslintrc.json is your linting settings for your frontend, you should create a frontend/webpack.config.js for your frontend webpack config.
Since you're in VSCode, it looks like, when dealing with just the frontend, you could consider making things easier on yourself by going to File -> Open Folder -> select the Frontend folder, and then you can easily operate on it, its package, and everything it contains (without getting mixed up with the backend at all).
Where your frontend folder goes is up to you, but your current approach is fine - organizing to have a /frontend and a separate /backend folder in the same parent directory if you wish.

Why is server.js never built in Webpack?

I am using Vue.js 3 for my front end, and Node/Express on the back-end. I am trying to enable server side rendering which is proving difficult.
I understand the client-side is built into a file called app.js. However I never see server.js being built and exported to the dist folder? Here are some examples:
vue-hackernews where there is an entry-client.js and entry-server.js file being provided to Webpack, but server.js is not anywhere to be seen.
Another question/answer also only provides main.server.js as the server entry file and does not build server.js.
It is my understanding that server.js is the back-end and has to run for Node.js/Express to work. In the above two examples what exactly is being built from the server entry files because it doesn't seem to be server.js where the Express routes live. Surely server.js must be built to the dist folder so that it can be accessed and run by a web server like Windows IIS for example (which I am using)?
You are correct, usually there is no need to bundle the server code.
But there are some benefits from doing so:
One project wide configuration, must of the client & server config can be shared - no need to maintain multiple build tools
Server code HMR (Hot Module Replacement)- you can swap your server code during dev without the need to restart the server
Code sharing between client & server
Code transpilation - server code can be written in modern syntax (ESM etc...) and it will be transpiled to the target node version.

Project structure when using VueJS, VuelidateJS with NodeJS/Express

My web development is principally intranet sites and web front-ends for embedded devices using NodeJS.
My current structure is to have everything in one NPM package. I run NodeJS behind Nginx, and let Nginx serve css/image/client-side-javascript files directly from public.
I'm starting to use VueJS and Vuelidate, both of which use the now ES6 modules system - e.g. import { required, minLength } from 'vuelidate/lib/validators'.
While I've (rather hackily) made these work with my current structure, I think the time has come to get into the world of Javascript build-systems/bundlers.
If I use VueJS's preferred option of WebPack, how should I change the structure of my code?
Should I have one NPM package for the frontend (generated by vue-cli init) and another for the Express backend app?
Should I put my Express App into the generated Vue frontend package?
Should I use browserify to do the job of WebPack and stay with my existing structure?
Or something else entirely?
I’m not sure why you’re intent on putting your JavaScript code in other packages. If you have an application then you can keep your raw JavaScript files in there, along with the build script(s). Someone should be able to check your application out and be able to build it.
If you’re looking to get started with a build system, then a nice “bridge” might be to use Mix, a project created by Laravel for building front-end assets such as Sass and JavaScript. It uses Webpack under the hood, but in turn exposes a more user-friendly, fluid API.
If you go down this route, then you could put your raw JavaScript files in a lib/ or src/ directory. You could then use Mix to compile these components like this:
mix.js('lib/your-entry-point-script.js', 'public/js/app.js');
Your entry point script would just be the script that requires all your other scripts and components and the script that you want “built”. Mix would then compile that and place the resultant script at public/js/app.js.
Mix itself is just a npm package, so all you need to do is npm install laravel-mix --save-dev.
You can read more about Mix at https://laravel.com/docs/5.7/mix

Static files from node module for client

Im making a module for node.js and it is meant to serve javascript on the server side (like most nodejs modules) but also needs to enable a javascript file to be shared with a client (browser).
The client is served by an express server, dealing with the routes.
However I can't seem to find a way to server the javascript file from the node module, as a static file (without it having to, either be placed to a static folder by the user or having to parse the app as parameter to the module).
These are two posibilities that I'd like to avoid, as I noticed Socket.IO does not take these steps to share its socket.io-client code.
I looked into their code, to look in how they did it but can't seem to find it.
So I am wondering what the best way is, to share a static javascript file to a client from a node module.

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.

Categories

Resources