When I run the build for Gatsby project it is taking more than 1.30 HR because of lot of lot of dynamic pages. My question is when I make a change on a particular page or pages Is it possible to run the build for the particular changes?
For gatsby develop try using Gatsby flags. Used like this in the gatsby-config.js:
module.exports = {
flags: {
FAST_DEV: true,
},
}
You can find a full detailed explanation of the current available flags at: https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/flags.ts
In your case, try using FAST_DEV which includes PRESERVE_FILE_DOWNLOAD_CACHE and DEV_WEBPACK_CACHE flags respectively.
For gatsby build I think you are looking for a feature called Incremental Builds: which basically only builds the pages that have changed from the last deployment.
Depending on your deploy server there's a different implementation way:
Netlify: https://www.netlify.com/blog/2020/04/23/enable-gatsby-incremental-builds-on-netlify/
Gatsby Cloud: https://www.gatsbyjs.com/blog/2020-04-22-announcing-incremental-builds/
Custom implementation: this is difficult to handle without a server implementation, which will be different in each case (and details have not been provided in the question). Try adapting Netlify's answer by enabling GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES and `cross-env, leaving your deploy command like:
"build": "cross-env GATSBY_EXPERIMENTAL_PAGE_BUILD_ON_DATA_CHANGES=true gatsby build --log-pages"
I want to use Svelte in my next project, due to its clean syntax and how nice is to work in it. Unfortunately, to deploy the app in my company I can't use node or anything like that on the server. I can only serve the app from nginx as static files.
Is it possible in svelte? I can't find anything that would allow me to do that, all solutions I've tried like #sveltejs/adapter-static didn't seem to generate it correctly to use it in this way. I can't find any guide on how to do that on the web.
In order to pre-render a SvelteKit 1.0 static site you need to:
Add to devDependencies in package.json (you can remove the default adapter-auto):
"#sveltejs/adapter-static": "next",
Run npm install
Add the following line to src/routes/+layout.js - create the file if it does not exist:
export const prerender = true;
Run npm run build
The static files will be generated in the build directory.
More details at https://github.com/sveltejs/kit/tree/master/packages/adapter-static#sveltejsadapter-static
If you aren't using SvelteKit, you can just copy contents of /build/ generated by npm run build. This should work.
I think Libertas' answer posted a couple of weeks after this is most likely what you're looking for.
But I'll leave the below here anyway in case it's useful to you or someone else coming along later:
SvelteKit (from the Svelte core team) supports server-side rendering, and documents generating static sites:
Static Sites
Most adapters will generate static HTML for any prerenderable pages of your site. In some cases, your entire app might be prerenderable, in which case you can use #sveltejs/adapter-static#next to generate static HTML for all your pages. A fully static site can be hosted on a wide variety of platforms, including static hosts like GitHub Pages.
(my emphasis)
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 ;).
I'm struggling how to integrate client-side modules like - just as an example - Apollo Client
into the qooxdoo-specific generate.py workflow so that they become available in the browser.
According to the installation notes:
To use this client in a web browser or mobile app, you'll need a build system capable of loading NPM packages on the client. Some common choices include Browserify, Webpack, and Meteor 1.3. [...]
Side note: I currently use Babel 6 to recursively transpile all my sources from a separate folder source.es6/ into the "official" source/ folder, which is then watched and processed by generate.py. Is it possible to use this somehow as a solution to my question?
OTOH, I would love to see at least some kind of integration with Webpack, Browserify or SystemJS.
I suggest you do the following. First, create a loadable package(s) from the Apollo Client and its dependencies, e.g. using Webpack. Then make sure these package(s) are loaded in your web page before you load your qooxdoo app. Then the Apollo API is available to your qooxdoo code.
If you choose to deploy the Apollo packages with <script> tags you can let generate.py do that by using the add-script config key.
I suggest you place the output of the Webpack run in your qooxdoo project's resource path and add #asset hints for those files in your main qooxdoo class. This will make sure they are copied into the build version of your app, and you can use the relative URI to these files, either in your index.html directly or in the add-script config settings.
I don't think your transpiling with Babel6 will help here. The Apollo code is already consumable and you woudn't want to disect it and make it part of your qooxdoo (es6) source tree, let alone its dependencies. I would rather treat it as a shrink-wrapped JS library as I described that is added like a resource.
I'm trying to work out the correct way to embed an AngularJS application into another web page (served by another app). I have two apps, running on different servers:
App 1 - PHP app
App 2 - AngularJS app (calendar widget of sorts)
The PHP app is the primary app, into which I want to embed the calendar, which is served from a remote server. I have full access to both servers, and to both apps. The idea is that I want to be able to re-use the Angular app elsewhere, so it needs to be as loosely coupled as possible to the PHP app, preferably embedded in a single line of code.
I am currently using a HTML5 tag, which seems to work well, but I was wondering if there's anything wrong with this approach, or if there's a better means of doing what I'm after.
I should mention that I'm happy to use a HTML5-only solution, I'm no worried about backwards compatibility with older browsers.
No iFrame solutions, unless there's a REALLY valid solution. My ultimate goal is to head towards a microservice-style architecture.
Thanks in advance for your help.
I generally manage all of my client-side dependencies with Bower but you could use any package manager.
This is how I would do it with Bower, which just uses Git to pull down your dependencies. This solution would require you to know how to use Git.
Install Bower—see above link.
Then, create a file called bower.json at the root of your project that points to the Git repository of your project:
{
"name": "my-php-app",
"version": "0.0.0",
"dependencies": {
"my-angular-app": "git#bitbucket.org:MY_BITBUCKET_ACCOUNT/my-angular-app.git#master"
}
}
Then you can run the following command in the root of your PHP project:
bower install
This will create a directory called bower_components at the root. You can configure the default directory.
Your application should be self-contained there. You can import it and all of its dependencies with PHP on the required page.