Thanks for the reply
I feel like I should've broken this post up and only asked one question at a time. Sorry if there was any confusion.
My Priority is learning about the different ways of deploying and maintaining a production level node server. Mainly devops related things like setting up servers, configuring them to run how I like (So far I am liking nginx over apache when it comes to the conf files), and basic upgrade/maintenance/security/backups/etc. It just all seems very interesting to me.
Sounds like a fun weekend project, but the full plan sounds like overkill. Focus on making something that works first and iterate on features as needed. Focus on learning what you want to learn at each stage instead of trying to learn everything at once.
I am attempting to do just this. I started in the front-end as a hobbyist years ago and recently started front-end development as a job after switching careers. Almost 6 months ago is when I started really getting into node went down the MEAN stack highway until I realized I didn't like angular, but loved express. Slowly I have been messing around with every level of the stack except the server level and I feel that I am finally ready to start messing around with full-stack development including sysadmin/devops stuff.
Don't worry about putting Nginx or Apache in front of your Node server. Yes they are "way better" at serving static files than Node, but that doesn't matter unless you're serving thousands of concurrent users. Node is perfectly fine (quite good at) serving files without any help.
I doubt my personal site will be put under enough stress anytime soon to justify anything but a basic webserver... but.. I have deployed several node apps to DO and heroku, I am ready to add some spice to the mix and learn how sites that do serve thousands of users, even if I am only slowly learning how to implement those best practices.
Make one Node app, and make it a REST-ish JSON API. 4 separate apps is certainly overkill.
I admit, 4 node servers running instead of 1 seems overkill, but I thought having small micro-service api's that only do a specific job vs. monolithic apps is the whole node mindset? Plus, I have built out REST APIs not just in node, but I have also spent plenty of hours doing this in rails and with PHP frameworks.
Why do you need a user or admin API if the site is only for you? What is your API serving?
Honestly a multi-user system isn't what I am going for, though it is something I have set up before, I wanted to built a single admin user with a seperate admin area on the site so I can manage the blog and portfolio data with a webgui (Like a CMS).
Before using any library, learn how to do it yourself. It makes for a big self confidence boost knowing that you could do it yourself, and you know exactly what problem the libraries are solving.
I tend to use libraries as a reference to how other people solve the same problems I am facing. I try to read as much about a library/module before I use it as possible, usually the source code, dependencies, issues, and PRs to get a feel for the library/module.
If you're really itching for the GitHub auto-deploy, have you thought about deploying your site on GitHub pages? Bonus, it's free, and needs no backend maintenance.
I have done this by hand and with tools like jekyll/metalsmith/etc. It's fun, but I want to have more control over the environment I am deploying in.
Write a manual deployment script first to understand very well what needs to be done. Write some bash to ssh into your server, clone your repo from github, install it, and then start it. This may lead you down the paths of learning about Upstart scripts, or Node modules like Forever, PM2, or ShipIt. Those are all fine, but learn to write some bash first!
This sounds like a wonderful plan! It would be a great way to get my deployment script production-ready without having to learn how to do it safely with Github webhooks and node. BTW, the words 'Upstart scripts' are by far the most helpful thing in your post, and I mean that in a way like.. Thank you! I googled all around trying to find out how to go about creating my own forever/pm2 system or at least kind of emulate what they do. Those 2 words just led me here and just led me down a trail learning about sysvinit and how the linux kernal starts up.
My personal, opinionated recommendations on languages features, paradigms, and libraries that are awesome (but are probably a distraction for you successfully getting to your Thing That Works):
I have to admit that I only strictly use ES6 when I am working with React. I love promises, they keep me out of callback hell most of the time. Babel is something I only use with the most basic and safest settings within webpack, I have been meaning to get into it some more, but haven't really found a reason.
Koa: I hear nothing but good things. Unfortunately I tried to get into koa a while ago and at the time didn't have a grasp on what generators were, so I just stopped trying to use koa.
My hunch is that if you really just want to write a blog, put it on Medium, and if you really want a portfolio site, handcraft a "static" front end site. No back end is the best back end!
Honestly, the blog is a tertiary thought to setting up the servers. Its kind of icing on the top, I do plan on writing about JS aimed at beginning and fellow intermediate JS coders.
Thank you again for the reply, and sorry for any confusion the original post created.