Migrate to full stack

[justincadburywong]

This project is becoming a monolith and best practices show that after about 20 posts, this should be migrated to a full stack application instead of a static HTML website. This way we can pull entries from a database and paginate the views with dynamic results, instead of having to rely on lazyloading assets for fast views.

This also would allow anybody to make a post, upload a picture, etc. We can put this feature behind a login page that only the three of us have (Justin, Shane, Mikey). This would offload some of the responsibilities for curating content onto others when available.

I'm technology agnostic, there are several ways we can go about this. Ruby + Sinatra + erb + Relational DataBase Ruby + Rails + erb + RDB Ruby + Rails + React + NRDB JS + Node + ejs + NRDB JS + Node + React + NRDB

All of these can be easily hosted on Heroku, or AWS, DigitalOcean, etc.

Thoughts around this?

[andywimmer]

Happy to help with full stack suggestions, though I tend to avoid databases these days if possible (personal stuff is static/serverless mostly). SQLite would be preferable for a db. I'm not sure if Pagekit is still kickin around support-wise but that may be an option. It has access control built in iirc. or you could use Access product too.

Otherwise I prefer flat-file solution like Grav or whatever is popular with good themeing these days. that's up to you really.

I don't know ruby, only some vue and less node. I can do infrastructure for sure though or write docs for that setup.

[justincadburywong]

You bring up a good point @andywimmer . Less moving parts make for an easier development cycle. We can forget the database altogether and go serverless. This might be a good opportunity to integrate a worker as well. Flat file storage on the file system can work; Github has an upper limit of 1GB for static sites, so we'll need to integrate a minifier for images so we're not hitting that after 500 posts (or less!). I'll look around and see what other options we have, but thanks for the suggestions!

[andywimmer]

photos.andywimmer.com is one example I have of what you describe. It's a static site generated with Hexo hosted here on Github pages. The images for this are hosted in a Google bucket on another subdomain. Since it's a photo site I don't want compression but you could use Polish and Github until you run out of space. This site is generated locally using the Hexo deploy process and you can view the source. For a cloud solution you could use Forestry.io for CI with Jekyll or Hugo. blog.andywimmer.com is an example of that, using Jekyll. Every git push triggers a new build/deploy from Forestry and I essentially never have to log into that service.