Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker.
He believes in clean code, pragmatic development, and responsive native UIs.
Also in this series:
Part 1 – You Need a Starter Kit
Part 2 – Editors and Configuration
Part 3 – Package Management
Part 4 – Development Web Server
Part 5 – Automation
Part 6 – Transpiling
Part 7 – Bundling
Part 8 – Linting
Part 9 – Testing and Continuous Integration
Part 10 – HTTP Calls
Part 11 – Project Structure
Part 12 – Production Build
Part 13 – Production Deploy
Separating the UI and API
In a real app, Cory recommends separating the UI and the API into different projects, and he explains 5 reasons why we should do this.
Where should we host our app? Here are just some options:
– Amazon Web Services
– Microsoft Azure
– Google Cloud Platform
– GitHub Pages (static files only)
– Surge (static files only)
In this module Cory uses Heroku for the host API and Surge for the host UI.
Demo: Automated API Deploy via Heroku
To follow along with this lesson, sign up to Heroku and go through the introduction and setup steps first.
Cory created and API project that works well with Heroku and you can find it at https://github.com/coryhouse/js-dev-env-demo-api
Its a modified version of the Heroku starter kit.
This project contains only five files and Cory runs through each of them here, beginning with our package.json file.
Cory has kept the code in index.js as simple as possible, although you can use some of the tips you learned earlier in this course to enhance it if you like.
The app.json file describes our app to Heroku and we define the name, description, repository and keywords here.
The Procfile declares the command that Heroku should run.
We see that the command to loggin into Heroku is quite intuitive:
> heroku login
As well as logging in, we see how to create the app and load the generated URL. We also see some git commands for updating our app.
We can see the JSON for our users here:
We can now update our baseUrl.js code with the URL for our actual API.
Demo: Automated UI Deploy via Surge
We setup a 3 stage process to get code into production:
- npm start (to do development)
- npm run build (build in production mode)
- npm run deploy (push production build to production host)
We’ve already done the first two of these steps earlier in this course.
And in this lesson, we learn that surge makes this final step easy. In fact we just add one line of code to our package.json.
Cory says Surge is awesome for hosting static frontends.
Starter Kit Update Approaches
If we have updates to our starter kit, how can we get those updates into the apps we’ve previously released? We could do it manually, but there are three options for doing this automatically:
Option 1: Yeoman
We could create a Yeoman generator. Then we can
- Scaffold over the existing project
- Resolve conflicts manually
For detailed information on using Yeoman, see Steve Michelotti’s Yeoman Fundamentals course.
Option 2: Github
- Host on Github
- Fork starter kit for new project
- Pull changes from master
Option 3: npm
- Encapsulate kit in npm package
- Update npm package to receive latest
Cory asks the question “What can we centralize?” and discusses various items:
- build scripts
- npm scripts in package.json
- webpack.config files
Cory also lists the items that will likely need to remain decentralized.
He also provides some search terms for searching for starter kits online.
Unlike Cory’s React and Redux course, the challenge here isn’t about writing code. It is just to send a meeting invite out to your team. Get talking about the issues raised in this course and how they can help you.
One of my very favorite courses on Pluralsight.