I started playing around with my first Next.js project.
After creating a new project via create-next-app, I ran the performance-tab in the web-app 'Lighthouse' (the results can be viewed in the tabs below). The performance report returned a score of 79, however; all the other test were above 90.
Can someone explain to me why these are the results?
The project is newly created, and totally empty, one would assume a performance report to return a great score for such a project, but it did not. If you have any insight that could help to clarify why the performance test is returning with the results that I explained above, it will be appreciated. Thank you!
I think you are running the test on the development server. In the development mode, there are a lot of unused js codes are being used. That's why the performance is a bit slow. You can check the production build.
All you have to do is:
run npm build
npm start (if your dev server is running on port 3000, then run npm start -p 5000)
then go to http://localhost:5000 and run the lighthouse. I think the performance will be better.
So I'm currently trying to run a react/react-redux/bootstrap web application template using react-app-rewired. To be specific, I run npm start, which runs react-app-rewired start via the predefined start script in my package.json file. The only error that's getting thrown is that in one of the .less files, there is some inline javascript. I'm ok with just allowing that to get through, because I'm sure there's also inline javascript in some of these other files, and having to fix every file this applies to would be a pain. I did some research, and the main way I see people accomplish this is by setting up gulp or webpack to pass enableJavascript as an option. Is there a way to enable inline javascript from the command line, and not take all that time setting up webpack or gulp on a premade program?
If there isn't, what is the way to accomplish this that comes with the least amount of headaches?
Thanks in advance for your help
I currently have ReactJS + NodeJS/ExpressJS + Webpack onto EC2, Amazon Web Services (AWS) under one project and would like to get it deployed together at once, in one project.
What are some suggestions on how to go about doing so? Done the research, and I've only seen tutorials on deploying one in specific, whether it be just ReactJS or just NodeJS. Any insights or leads would be greatly appreciated.
Will accept/upvote answer. Thank you in advance
You don't "deploy" ReactJS, it's just a static file or files like any other JS libraries in your applications. You also don't deploy Webpack. Webpack should run on a developer machine (or in CI/CD stack or build system).
As for the NodeJS part just use Elastic Beanstalk.
I do not commit builds to source control. I see that a lot and it can make things easier, but you can also forget to rebuild as you have to do it manually, and it adds a lot of bloat to your repo.
I believe builds should be run as part of the deployment process. Assuming you are using git, you can add script hooks/post-receive in a remote repo there. When you push to that remote, the script will run. This is where I do my webpack build.
You may want to look into https://github.com/git-deploy/git-deploy for context, but I do this manually.
In my projects, on the deployment machine I do git --init --bare /var/git/myproject.git then add the script in /var/git/hooks/post-receive. The hook checks out the code into /var/www/myproject, runs the build, which fills in the /var/www/myproject/build. Then it removes the old /var/www/myproject/public and renames build to public. And done.
I'm coming from more of an operations background and would say that if your goal includes keeping that site up as much as possible then use Packer to generate AMI's and CloudFormation to build an Application Load Balancer (the newer, cheaper brother of ELB) in front of an AutoScalingGroup which keeps the EC2 instances up and running.
I'm currently working on a large scale project doing exactly what you describe. First off, there are so many different ways to do this, so what you really need is some general guidelines to get started, then we can dig a little deeper into details when some initial decisions are made, if you'd like. If you've already got the app deploying and running in two separate steps, but are just looking to combine those, I can definitely help. I'd just need to know how you're currently building/deploying. If you're just getting started on building your pipeline and need to set up the process from scratch, then read on:
First off you'll want to set up some kind of build server that will install your npm dependancies and run your webpack build. Most likely you'll want a separate webpack config that's just for your build server, this'll give you a build optimized for production or qa/staging environments. This config should split out vendor files that you won't update all the time, pull out seperate css files with extract text plugin and uglify the files. If you have an isomorphic React app, or are using es6 features not supported in your version of node, then you'll need a webpack build for your server code as well. This is really different from the hot reloading build you'll want to have on your local machine while you're actually coding the app. I'll be happy to show some examples if you'd like of our webpack config files for both local development and our CI build. You may also need a build.sh or makefile to do something with the compiled .js files that your webpack build creates, but that'll depend on your deployment which I'll cover later. You can run your production build locally as your getting your config just right and fire up the app from those files to test it's all working. Additionally, since you'll likely want to be able to automate all of this, you probably want to run your tests and linting right before you build your app, we run eslint and mocha/jdom to run our enzyme/expect specs as part of our build. Once that's all working nicely, you'll most likely want to set up a build server that can run your builds automatically. My team is using Jenkins for this, which is a little more work to set up, but it's free (aside from the ec2 box we run it on). There are also a ton of subscription based build/continuous integration servers, such as Travis and CodeShip. There's plenty of articles on the pros and cons of these different products and how to set them up. The bottom line is you'll want to have a build server that can pull down your code from source control, install npm deps, lint, test and build your app. If anything fails it should fail your build and if your build succeeds you'll have some sort of archive that you'll later deploy to an ec2 instance. In our shop we use a build.sh file to tarball up our build archive (basically a folder with our node server files as well as our minified client files, css files and any fonts or images needed to run the app) and upload it to an S3 bucket that we deploy from. We like this fairly old school method because the tarball will never change, so we have ultra reliable roll backs.
What you do with your build archive will depend on how you want to do deployments. We have a custom deployment system using puppet, but there are plenty of products that do this such as elastic beanstalk, that would be much easier to set up. You'll want some kind of process supervisor to actually run your node app, so unless you have a dev ops team that wants to build custom pipelines, using AWS built in features will probably be the easiest way to get started. As usual, there are so many ways to do this, but the basic principal is that you need something to download your build archive and run/supervise your node process. You also may want to be able to create and configure ec2 boxes on the fly (Puppet, chef, etc.), or even use containers (Docker) which allow you to move complete stacks around as single units. Using automation to create and configure servers is crucial if you need to scale your app, but it is complicated and may not be necessary for smaller projects. This is definitely an area where you can start simply and add complexity later on, as long as you have good long term goals and make sure to take the necessary step to prepare for future complexity.
All of this can get you pretty far in the weeds, so it's best to find the simplest thing that will serve your needs as you get started and then add complexity as real life situations demand so. I'll be happy to elaborate on any of these details if you provide a little more context about how big and well funded of a project your working on. If it's a little side project to learn the tech, I'd have very different advice then if you're trying to build an app that'll have a lot of traffic and/or complex features.
This could get 100 different answers and they could all end up being good ideas. First, you mention react + nodejs - keep in mind that these solve different tasks. React is going to be frontend and served out via static files. Nodejs is focused more around the server-side and would be the code that serves data. They can easily work together. You might use Express for the webserver (nodejs) to serve the HTML/React pages.
Unfortunately, I saw that you mentioned webpack, so you are going to have to 'build' your application with something - either via webpack, gulp, grunt, etc. This is where source control and build servers are great - but if you're new to it, it might be more complex than you need.
If you have just basic EC2 images as webservers and only 1-2, then the biggest hurdle is just pushing up your code. Something like https://deploybot.com/ could work as it can push your git repo down to multiple hosts via ftp, etc. If you wanted to get a bit fancier, you could look at something like Jenkins or some of the other items.
Docker is a great choice and if you are going to be dealing with multiple developers, server environments, deployments - it's worth the time. Otherwise, keep it simple and just get your code on the EC2 instance ;).
Currently i discover that i can use nodemon with coffeescript, without needing to generate the .JS files, searching about i discovery that forever can do the same.
I wonder if use in production will lead to performace issues. I do not think so, since the Nodemon and Forever generate the javascript files in the dark just one time, when the server starts, then is not needed to generate these javascript files to each user request, correct?
Thank you.
That is correct, but in a production environment you would not use nodemon because your source code (for your currently deployed version) is not supposed to change. Forever would be more appropriate in this game.
I'm a newbie and that's ok.
But when I use tutorials, they always tell me to go straight to my terminal and install documents from there in which I have no clue what the next step is and no idea why I have to do it. Is it essential that I install frameworks through terminal or can I just work without it?
ex. http://net.tutsplus.com/tutorials/javascript-ajax/real-time-messaging-for-meteor-with-meteor-streams/
"Let’s create a very simple, browser console based chat application with Meteor Streams. We’ll first create a new Meteor application:"
meteor create hello-stream
I understand this is may not be very challenging, but I don't have a clear answer when I try and simply google it. Anything would help, thanks a lot!
Being a newbie is ok.
The terminal is the go to because writing programs, tools, and scripts with a couple lines of bash or python is, well, a couple of lines versus an entire gui and all the lines of code to go with it.
meteor create hello-stream
That's telling you to run the program called meteor with the supplied arguments (create hello-stream).
If you haven't installed meteor, do that next. From their website, open your terminal and type/paste:
curl https://install.meteor.com | sh
That downloads a file from the URL and pipes (|) it to the sh command. The file it downloads is a shell script that takes care of setup/installation. Now go back and try the meteor command again.
More reading
You might try and find a terminal tutorial. This is the first one I found:
http://www.ee.surrey.ac.uk/Teaching/Unix/
Answer from someone who only recently (as in: within the last year) got into using the Terminal more and more frequently:
It's generally a good idea to get used to using the Terminal for code-related things as you can pretty much use it platform-independently (meaning you can use the same commands on Mac, Linux, Windows,...) and because it makes you understand better what you're actually doing.
Once you've got the hang of it, it can make navigating your system as well as making changes to it easier. Hidden files, for example (like .gitignore files, or files in your .ssh directory, or your .bash_profile), can be viewed, opened and edited easily from the Terminal whereas you have to take multiple, complicated steps (or install other software) to view them from your Finder.
With the help of package managers (like Homebrew), which are also operated from the Terminal, you can also install software that isn't otherwise available for Mac.