React Build Settings on Amplify
The technology stack that was inherited from the prior tech team at Research Blocks came with some outdated methodologies. One of those areas was in the deployment of React applicationa on EC2 instances. For Single Page Applications (SPAs), like React, there are better options for rapidly deploying a scalable production app. The Amplify environment also makes it very easy to stand up multiple instances of the application container. These canrepresent different builds such as a development, staging, or test environments.
While there is plenty of documentation available on how to go about building an React app, there is very little on problem solving or details on what is going on “inside the black box”. This article is a collection of notes on what was found delving deeper into the AWS tech stack for Amplify.
Amplify Hosting
The first thing to know about Amplify is it is a hosting service for STATIC WEB ASSETS; as they like to say “Amplify Hosting provides a git-based workflow for hosting full-stack serverless web apps with continuous deployment.”. In other words, it does not work like a traditional web service such as Apache or nginx.
Amplify uses CI/CD to continually monitor your repo, clone that code when a branch changes, run commands specified in the Amplify console Build settings, and copies the files out to a CDN. From here, Amplify serves up the entire thing as a static web page. For React apps that typically means it zips up your build folder including an index.html loader and stack of JavaScript files compiled via a utility such as webpack.
This also means it is not going to do well with actively listening to incoming web request. Amplify is not going to play a good host as an Express server. There are ways to do it using Lambda functions and some additional configuration that will be content for another article.
Build settings and Amplify.yml
Build settings determine what commands are run to build your app after the code repo has been cloned. Normally this includes the install command to install a million mostly-useless node files into your project; These files are necessary so it can leverage twenty-lines of actual useful functions needed to make your JavaScript app work. The build command then links all that code together, runs through something like Webpack to rip out lot of that useless previously-downloaded Node code, and ends up with a somewhat useful app for your customers.
While you can enter the various commands in the YML formatted Build settings on the Amplify console, learn from my mistakes and instead put an amplify.yml file in your source root directory. That way when you inadvertently tell it to start the node server within the build file you can go back and look at an older commit and revert to the working copy of the file.
Regardless of which method you use, a simple Amplify.yml (Build settings) should look similar to the following image.
What To Put In Build Settings
The build settings should only contain the commands that are needed to download required code libraries and subsequently compile the code into a set of static files. This is where your React app’s package.json comes into play; package.json will tell Node which modules are needed for the yarn install command (we use yarn vs. npm) as well as how to build the static files for the SPA with the yarn build command. In our case, run webpack and set some environment parameters.
What NOT To Put In Build Settings
Do NOT put in any commands that START a node server into the build settings. The build manager for Amplify looks for any specified commands to finish executing. Starting a node server runs a command that , as far as the “build monitor” is concerned, never finishes.
The following is an ASSUMPTION about how Amplify works. I have yet to see official documentation that states the following…
LC
Remember, Amplify is going to stand up a static website for you. Along the way it will setup an https/http listener and route traffic to your Single Page Application accordingly. There is no need for a node server in this situation. Amplify is going to take over the responsibility for the apps it hosts.
Artifacts
Not super well documented, but again based on observations and assumptions, the main setting here is the baseDirectory. This tells the Amplify build manager “copy all the files under the specified directory and go through them out on the CDN as a static file set”. The subsequent files specification is a ‘stack’ of file paths you want included where the **/* specification means “any file in this directory and anything under it”.
Amplify’s build manager seems to us this setting to execute a zip command which grabs all the files in the directory and files list specified, zips them up and distributes it to the CDN.
Cache
The cache section tells Amplify which directories and files to carry over from one build to the next. While most of the building/distribution manager services on Amplify start with a fresh container, anything in the cache appears to be copied from one build to the next.
Almost all the Amplify documentation cites putting node_modules/**/* in this list to save the previously-mentioned yarn install command from having to download the same million-plus node files on every build. Instead it copies them from one container to the next saving all those electrons from flying around Internet servers to recreate the files every time. Instead the electrons all stay within Amazon’s borders and maybe speeds things up a bit.
On to bigger & better things… next up trying to see if we can trick Amplify into hosting an Express server WITHOUT lambda proxy functions.
MacOS Monterey Node Port 9000 Refused
I’ve been working on a React App for months that connects on localhost port 9000. Recently the app stopped working after an upgrade to Monterey. Turns out the upgrade also required a number of services to be re-installed via brew. One of those services, php-fpm, is now taking over port 9000 automatically on startup despite not having explicitly set the updated PHP version to run at start.
As such, opening http://localhost:9000/ on the browser was routing to PHP apps and not the node app I was looking for.
MacOS Listing Port Usage
The first step to finding what other services might be fighting with the node app is to run the lsof command.
sudo lsof -i :9000
The :9000 should be replaced with whichever port you are investigating. Port 9000 is the default for most node servers.
In my case the results looked like this:
This tells us that php-fpm will first answer any port 9000 queries on IPV4 localhost.
Node server has been relegated to only answer port 9000 on IPV6.
The node server on IPV6 can be verified by pointing the browser to http://[::1]:9000/ and connecting to the app.
[::1] is the IPV6 syntax for localhost.
Listing Homebrew Services
To stop the php-fpm service it needs to be managed via brew since that is where I started the service from in the first place. The service php-fpm does not exist, so what is calling it? Let’s check brew services…
brew services list
Turns out is is the php@7.4 service causing the issue.
Stopping Brew Services
Now that we know which service is fighting with node server we can stop it.
brew services stop php@7.4
That stops php-fpm from intercepting port 9000 traffic on localhost and the original http://localhost:9000 access I was running previously is now back in action.
Here’s What’s Happening in That Viral Oil Well Bitcoin Mining Video
A video of a bitcoin mining rig on an oil well got thousands of retweets and replies, criticizing it for destroying the planet—but it’s not that simple.
— Read on www.vice.com/en/article/dy8b9y/natural-gas-oil-bitcoin-mining-rig-viral-video
Radiative Cooling and Solar Heating From One System – No Electricity Needed
Radiative Cooling and Solar Heating From One System – No Electricity Needed
— Read on scitechdaily.com/radiative-cooling-and-solar-heating-from-one-system-no-electricity-needed/
Cleaning Up WordPress – Large wp_options.idb
Did your tiny AWS Bitnami WordPress server run out of disk space? The culprit may be unoptimized data tables in MySQL. Finding a 4.9GB wp_options.idb file on your server is not as uncommon as you may think. What makes it surprising is when you look at your wp_options entries and discover there are only 300 rows in that table with limited text in the option_value column.
Thankfully there is an easy fix as long as you can get enough disk space to manage the task. Start by looking for any log files or other files you are CERTAIN you don’t need so you can shut down web, php, and mysql services.
Finding Large Files
# sudo find / -xdev -type f -size +50M -print | sudo xargs ls -lh | sudo sort -k5,5 -h -r
This command finds all files on the drive over 50M in size.
Look for specific MySQL raw data files (wp_options.idb for example) in that list. Remember the table name for later.
Stopping System Services
Stop the services. On an AWS Bitnami WP server they have their own special control scripts in place of the standard Linux services library.
bitnami@ip-172-31-87-127:/opt/bitnami/mysql$ sudo /opt/bitnami/ctlscript.sh stop mysql usage: /opt/bitnami/ctlscript.sh help /opt/bitnami/ctlscript.sh (start|stop|restart|status) /opt/bitnami/ctlscript.sh (start|stop|restart|status) mysql /opt/bitnami/ctlscript.sh (start|stop|restart|status) php-fpm /opt/bitnami/ctlscript.sh (start|stop|restart|status) apache help - this screen start - start the service(s) stop - stop the service(s) restart - restart or start the service(s) status - show the status of the service(s)
Stop all the services, then start MySQL only.
Cleaning Up MySQL
If you are doing system admin commands you should know how to find your data access credentials in the wp-config.php file. No need to go into that here. Find the credentials and login to MySQL.
No OPTIMIZE that table (and any others that you suspect have unusually large .idb files).
mysql> OPTIMIZE NO_WRITE_TO_BINLOG TABLE wp_options;
That’s it. One simple command may easily recover 4.9GB of disk space , making a 4.9GB file on a 9GB drive get back to a more reasonable 10MB.
Why WordPress core or cron jobs are not doing this on a regular basis is a question for another day…
