When my son joined Troop 446 in the spring of 2013, one of the adults on the Troop committee approached me and informed me that I was going to be a merit badge counselor and Assistant Scoutmaster. I was not surprised to have been "volun-told" in this way. As an Eagle myself, I was prepared for something like that. And I'm very glad she did because volunteering as an adult leader in Scouting is probably the most rewarding and enriching thing I have gotten to do in my life- other than helping raise my own kids, of course. What I hadn't anticipated was what she said next - "oh, and you can build our new website."
At the time, the Troop had no tools to track Scout advancement, manage the calendar, or record charges and debits on the Scout accounts. So, I built a somewhat over-engineered WordPress theme and stuffed all these features inside. And those features interacted beautifully. Signing up for a campout, for example, would debit the family's Scout account.
From the committee's standpoint, it was a good solution, but I knew it was only temporary. WordPress is a maintenance headache- logging in every few weeks to update core & plugins and scrambling to fix the subsequent issues. Oodles of very fragile PHP & jQuery. Not only that, the crotchety old VPS was costing me $40 every month. To top it all off, the 2013-era website was looking old, and Scouts were having trouble adding photo galleries and whatnot.
When the BSA bought Scoutbook and made the service free for Troops, I was all in. Even though Scoutbook only replaced 80% of our existing feature set, it had much better advancement features and connected directly with the district and council, saving our people a lot of time and headaches.
This was an exciting opportunity to come up with something new, but before diving in I needed to come up with a list of goals.
- It had better be fast.
- It's got to be secure.
- It should be easy for Scouts and other adults to make changes.
- I'd like to spend less money hosting the thing.
- Oh, and it has to look good, too.
The architecture that would meet these needs seemed obvious from the start: a headless web app with NodeJS/Express in the back end and ReactJS on the front end.
Headless means that the front end never communicates directly with the back end, which is a huge boon for security. The back end CMS pushes content as JSON files along with images to an Amazon Web Services S3 bucket where the front end pulls it in as needed. The other benefit of not having a persistent database connection on the front end is that it loads almost instantly.
Serving static files on AWS means we don't need to use traditional hosting. The whole front end runs in an AWS bucket and costs around one or two dollars per month. The back end is hosted on Heroku for free. There's a bit of a lag when you first load up the back end CMS, but since we only need to make changes once or twice a month, Heroku was a great fit.
We pull in the calendar from ScoutBook, but we could not do so directly. Instead, we subscribed to the calendar in a separate Google Calendar and then pulled that into the front end application.
As with other recent sites, the back end CMS makes use of a block-based page editor for maximum flexibility within a rigid design system. Once the pages or galleries are ready, click "publish" in the backend and the JSON files and an updated sitemap fly off to AWS.
The back end leverages Express for not only the API endpoints but the login and display features for the back end admin panels. I came to really enjoy working with Express in this way. Organizing controllers and views felt like good old PHP, specifically a framework like Laravel.
I used the Pug layout engine, which is both very easy to read and quite easy to break since it relies on tabs/spaces to determine parent/child relationships on various tags. Once you get the hang of it, Pug is great, though. Much of the interactivity in the back end CMS is vanilla javascript, including the dropzone-style image uploader that sends images directly to Amazon S3.
We added a special user for the Troop historian with limited access, the youth in charge of adding photos and galleries to the site, and designed the UI around making the process easy and fast.
The design features a "dark mode" look, animated buttons and SVG graphics. Without the need for all the tracking features, we could focus on marketing the Troop rather than managing it.
So, there we have it. A new website for the Troop; no more fretting about WordPress security; no more VPS bills. Hopefully, this will serve them well for another seven years, then I can rebuild it in WebAssembly or its inevitable successor.