Hey hey! I'm a full-stack product developer in Salt Lake City, UT. I love enlivening experiences, visualizing data, and making playful websites.
🧑💻 Formerly Course Director @ Code School.
📚 Currently founder @ https://hardcover.app
✏️ I write about personal growth, building websites (#ruby #nextjs #rubyonrails), #minimalism, #mindulness, #FIRE, recovering from an ACL tear, and awkwardly posting on TikTok (😂).
| Personal Site | https://adamfortuna.com |
| Minafi | https://minafi.com |
| Hardcover | https://hardcover.app |
| Line of Thought | https://lineofthought.com |
For the Hardcover migration from Next.js to Rails, one thing I'm removing is any use of Apollo Fragment caching to determine UI state.
Previously for things like a Like Button, or your Ownership for an Edition, we'd prime the Apollo cache and then load your state from that.
With the new setup, we're just loading that data into Redux (what you've liked, what you own), and then the initial render can use it.
So far it's a lot cleaner - and no GraphQL to worry about.
One of the neat little charts on Hardcover is this Ratings Distribution that's on each book page (ex: https://hardcover.app/books/tomorrow-and-tomorrow-and-tomorrow ).
I previously tried to generate this using D3.js on the server side using JS DOM - which is what Hardcover uses right now.
In the conversion to Rails, I'm switching this to just use D3.js scales, then generate the SVG directly. It's sooo much smoother, and uses the good parts of D3.
This course used the same technique:
https://www.newline.co/courses/better-data-visualizations-with-svelte
I'm working on refactoring pages from Next.js to Ruby on Rails with Inertia.js and it's hard to put into words how much less code there is.
There's more that I could clean up here, but these are sample endpoints that would correspond with https://hardcover.app/live and the single ep pages.
Instance variables are passed to the React Component as props via inertia-rails.
I could see moving this into a Presenter that handles caching+service+serializing, but seems overkill, but feedback welcome!
Looks like the all-out-nothing problem is solved in Inertia v2 announced last month.
Looks like it can be used when something scrolls into view or with a fallback block.
Can’t wait to try it once it’s in inertia-rails.
https://pascalbaljet.dev/taylor-otwell-announces-inertia-v2-at-laracon-us-2024-heres-whats-new
I can work with this. :)
We also ended up moving everything from `/_next/static` to be served from CloudFlare's CDN, which should further speed things up.
We had local fonts, some images, and all compiled JS served from Google Cloud Run.
Total blocking time (TBT) is the number 1 culprit right now.
Pretty impressed with how far I'm getting with just GitHub Copilot for this 😂
✅ Build images with Docker
✅ Push images to Digital Ocean
✅ Pull images from Registry to Kubernetes
❌ Automatically push images on push to staging/production branch
❌ See anything working 😅
I'm starting to wrap my head around the process at least - which was more than yesterday.
About a year ago, I switched from posting about Hardcover in bulk on social media to posting one long email monthly with updates.
This wasn't because I think that's the best way to grow an audience, but because I just didn't have time to do that AND build the product. 😅
Since May 1st, we've seen our newsletter audience almost double! I think we're doing something right. Each time I send out an email now I get dozens of responses.
Here's this months Hardcover Report:
Even after years of sending newsletters, I'm nervous every time.
Yesterday, I sent a message about today's Hardcover Live (in 2 hours at 12 pm PST / 3 pm EST), where we're talking with an indie author. https://hardcover.app/live/51
This email was sent to ~12k emails; 128 people unsubscribed, with a 33% open rate, with 290 clicks.
I used to feel some way when I saw that many people had unsubscribed. Now I think of it as "3 days of signups," and it's less personal.
