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.
Related
I prepared an ember-cli project that gets api from express server. Then I added fastboot to using the command:
ember install ember-cli-fastboot
After that, all the links began to be rendered on the server. Tell me, how do I run this in production?
If I run ember build and load the project from the dist folder (via express route), the application opens like a usual SPA, and the child pages do not reload, and are not accessible for curl. That is, it behaves like a usual SPA.
Please tell me how to run it? Should I run it in production as it is, withowt build, i.e. from ember-cli folder, using ember serve?
Thanks for any help.
The recommended way to serve an Ember FastBoot application in production is currently using the Ember FastBoot App Server.
Ember FastBoot App Server is a Node.js HTTP server. It serves your application build. So you should still do you normal build. But you replace the static web server with Ember FastBoot App Server. It's documentation contains a Quick Start example.
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
I am trying to optimize an existing UI5 application which resides in SAP BW as BSP Application and runs from SAP Portal (You press on the link and the UI5 application opens in a new Tab).
My main concern is with the amount of calls between Client and Back-end system. Especially calling all the library.css/library-preload.js/etc files AND custem controller.js and view.js files.
I found possible solutions involving grunt/gulp or deploying from SAP WebIDE. I trying building and deploying the App with SAP WebIDE, but after opening the App, Network still shows a lot of traffic + there is no Component-preload.js call. I'm guessing it has something to do with where the app is launched or I still have some configuring to do on the back-end?
I would like to build my App with either grunt/gulp since I can involve other plugins like lints, compression (for js, html, css), test, and many more. The problem is that the App resides not in OS, but somewhere in DB.
So I want to build my App with all those Grunt/Gulp tasks and deploy to ABAP AS (in BW as BSP application) using ABAP Team Provider and ensure that when I call the app from Portal, the files will be compressed/minified and, what is more important, that all the relevant .js files will be loaded as a single request.
Is what I imagine even possible? And if yes, then what are the steps required to accomplish this?
NOTE: I checked SCN and unfortunately I can't use your typical npm grunt or grunt-openui5 etc since the App resides somewhere in the DB :/
If you have a build configuration inside your WebIDE project, WebIDE will reate a DIST folder containing the distribution package.
Inside DIST there is an autogenerated Component-preload.js
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.
I am developing a web application using Sailsjs for the backend and Angular.js for the front end. To scaffold the Angular app I have used yeoman with the angular generator and for the back end I used the default Sails app generator.
During development I run 2 servers, the 1st is the sails server to host the back end and the second a grunt server for the front end.
For now my configuration works fine but when in production I want to combine the two ends in one and have sails server serve the angular web app...
Can someone explain how to do this?
I haven't used Sails before but it looks like it generates an assets directory. If you'll notice, Yeoman created an "app" directory into which it put the index.html, JavaScript, styles, etc. It appears you could transfer the contents of the Yeoman "app" directory to the Sail "assets" directory and it would be served up.
http://sailsjs.org/#/documentation/concepts/Assets
If no one with specific experience with Sails shows up, maybe that will help some.