May 20, 2025 • 35 mins
Swimming against the current sometimes leads to unexpected treasures. In this fascinating conversation, Adam Fortuna reveals how migrating Hardcover—a social network for readers with 30,000 users—from Next.js back to Ruby on Rails delivered surprising performance improvements and development simplicity.
The journey begins with Adam explaining how Hardcover originated as a response to Goodreads shutting down their API. As a longtime Rails developer who initially chose Next.js for its server-side rendering capabilities, Adam found himself drawn back to Rails once modern tools made it viable to combine Rails' backend strengths with React's frontend interactivity. The migration wasn't a complete rewrite—they preserved their React components while replacing GraphQL with ActiveRecord—and unexpectedly saw significant improvements in page load speeds and SEO rankings.
At the heart of this technical evolution is Inertia.js, which Adam describes as "the missing piece for Rails for a long time." This elegant solution allows direct connections between Rails controllers and React components without duplicating routes, creating a seamless developer experience. We dive into the challenges they faced, particularly with generating Open Graph images and handling API abuse, and how they solved these problems with pragmatic hybrid approaches.
The conversation takes an exciting turn as Adam discusses their work on book recommendation engines, combining collaborative filtering with content analysis to help readers discover their next favorite book. As someone currently enjoying the Dungeon Crawler Carl series (described as "RPG mixed with Hitchhiker's Guide"), Adam's passion for both books and elegant technical solutions shines throughout.
Listen in as we explore how going against conventional wisdom sometimes leads to better outcomes, and discover why Hardcover is now being open-sourced to invite community collaboration. Whether you're interested in Rails, JavaScript frameworks, or book recommendations, this episode offers valuable insights into making technical decisions based on real-world results rather than following trends.
Links
- https://hardcover.app/blog/part-1-how-we-fell-out-of-love-with-next-js-and-back-in-love-with-ruby-on-rails-inertia-js
- https://adamfortuna.com/
- https://bsky.app/profile/adamfortuna.com
Honeybadger is an application health monitoring tool built by developers for developers.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Drew Bragg (00:01):
Hello everyone and welcome to another episode of
Code and the Code Encoders.
Who Code it?
I'm your host, drew Bragg, andI'm joined today by Adam Fortuna
.
Adam, for anyone who's notfamiliar with you, would you
please give us a little bit ofbackground on yourself.
Adam Fortuna (00:13):
Hey, hey, I'm Adam .
I think maybe some Rails andRuby developers might know me
from working at Code Schooldoing interactive courses.
Some people might know me froma financial blog I wrote for a
couple of years called Minifyyou, minify JavaScript that's
kind of the emphasis of the name.
Lately I've been working onHardcover, which is a social
(00:34):
network for readers to findbooks and get recommendations
from friends, all right.
Drew Bragg (00:40):
So the way this is going to work for anyone new to
the show is I'm going to askAdam three questions.
I'm going to ask him what he'sworking on, what kind of
blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hewent about solving it.
And then we'll wrap up the showby asking Adam what's something
cool, new or interesting thathe's recently learned or
discovered.
It doesn't have to be codingrelated, but of course it always
(01:00):
can be so without any furtherado, adam, what are you working
on?
Adam Fortuna (01:13):
I just finished a really big migration for
hardcovers codebase where wemigrated from Nextjs to Ruby on
Rails and that ended up takingquite a bit of time.
Some of our back end wasalready in Rails but our front
end was in Next.
That migration really took overmy life for quite a few months
lately.
Drew Bragg (01:29):
That's not a quick and easy migration.
So, in your mind at least, whatwould you consider?
The difference between amigration and a rewrite Depends
on how much you're able to reuse.
Adam Fortuna (01:40):
All of our front end was in React within Nextjs,
so we were able to keep thatpiece and move it over to Rails,
so that part was able to reuse.
All of our front end was inReact within Nextjs, so we were
able to keep that piece and moveit over to Rails, so that part
was able to be migrated.
And the part that had to berewritten was all of that data
access layer, because previouslyin Nextjs we were hitting a
GraphQL API and getting our dataand then sending that to React
or sometimes getting it clientside and using that in React.
(02:02):
This pretty much changed it allto just using it in Rails,
getting it from ActiveRecord inthe database, serializing it to
JSON and sending it to React.
So, yeah, it was a bit of acombination of those two.
Drew Bragg (02:16):
And you recently wrote a fairly detailed blog
post or at least a part one blogpost on doing this and you go
into quite a bit of it and theone part that stuck out to me a
bit was the performanceimprovement that you guys saw
and I think that's to a lot ofpeople probably surprising to
hear like, hey, we used Ruby onRails and got better performance
(02:37):
.
It's not surprising to mostRails devs to hear that, but it
could be anyone listening whoisn't familiar enough with Rails
and may just know the oh, itdoesn't scale.
It's not performant nonsensethat people talk about.
Can you talk a little bit aboutthe performance improvements
that you're seeing and any sayspeculations you have onto what
(02:58):
is helping the most with that?
Adam Fortuna (03:00):
So initially, when the project started back in
2021-ish, I really wanted to dosomething that was really
interactive.
So that's kind of why React waschosen as the front end.
I'm a Rails developer for quitea long time, but I didn't
choose Rails for it initiallybecause the server-side
rendering side if you're doing aJavaScript app within Rails
(03:22):
five years ago that had acompletely different way to do
it.
So, like with Nextjs, we wereable to render the server-side,
render all the HTML, so thefirst load gets all the HTML of
the page you need and then it'shydrated with React.
But we weren't able to do thatwith Rails until recently, where
now we were able to do thatusing a combination of Vite and
(03:43):
SSR and Inertia to take this bigReact tree, render it to HTML
and send that as the first load,and so that kind of meant there
was parity there between whatwould be loaded initially from
Next and Rails.
I wasn't expecting muchimprovement beyond that.
Next actually handles a lot ofcases really well, like fonts it
(04:06):
does some really cool thingsfor those where it loads them in
really fast ways, and someother just speed improvements
for Google PageSpeed but I waskind of surprised at how well
Rails was able to do that.
But on top of that we wereseeing startup times for the
initial requests.
That took a little bit longeron serverless functions, with
Next even on Vercel or GoogleCloud Run, and then when we
(04:29):
moved to Rails, even justdeploying on digital ocean
droplets, those time to firstbyte metrics ended up speeding
up significantly and that endedup being the biggest boost to
our Google page speed.
Drew Bragg (04:42):
Right, and you said that actually helps a lot with
how Google ends up ranking youin their search.
So it's an SEO kind of thing.
I don't know if you wouldconsider it out of the box, but
it almost sounds like it was anaccident, that those things like
that wasn't the targetimprovement.
You were just making the moveand then noticed, hey, we're
getting these side benefits thatwe weren't expecting.
Adam Fortuna (05:05):
Yeah, the baseline was really not dropping our SEO
.
Drew Bragg (05:09):
But incidentally, you talk a little bit in the
blog about that actually beingpart of the reason why you chose
Next in the beginning becauseyou wanted to React front end
for the interactivity.
But because React doesn'tactually load up a page right
off the bat, google was going tokind of not be able to pick up
on a lot of your SEO and whatnotand cause a hit to your page
(05:34):
speed.
So you choose Nextjs for thatserver rendering component.
But then it actually improvedeven more when you got to Rails.
Adam Fortuna (05:42):
Right, exactly.
Drew Bragg (05:43):
Yeah, what was it like working with Inertia?
Because I've heard lots aboutit, I know its existence, I've
heard good things about it, butI haven't played with it myself.
So what do you think aboutInertia as part of a Rails
project?
Adam Fortuna (05:58):
So I feel like Inertia was the missing piece
for me for Rails for a long time.
The sanctioned Rails path forgenerating like JavaScript apps
has changed quite a bit over theyears.
We had like RJS for a while andthings like that, and then more
recently it's been likestimulus, or you just use
Turbolinks and just re-renderthe entire page or something
(06:19):
like that.
Drew Bragg (06:21):
Yeah, Hotwire is the new Turbolinks at least, and
that's a follow-up question Iwant to talk more about Inertia,
but then I want to talk alittle bit about Hotwire.
Adam Fortuna (06:30):
So, yeah, carry on with Inertia, I'd kind of spent
so much time learning React Ihadn't learned the stimulus,
that side of Rails.
So when I was thinking abouthow to use this React app on
Rails, there were like threemajor gems that kept coming up.
(06:50):
I think there's like a React onRails and a React Rails one,
and those handle things indifferent ways, but inertia
ended up being kind of the mostlightweight of them all and it
felt the most Rails-y of themall.
So I think about it like in acontroller of them all.
So I think about it like in acontroller you set some instance
variables and those get passedto a view.
(07:10):
Usually With inertia you can dothat exact same thing.
Just set some variables in acontroller and you can either
call render I think it's renderinertia, colon and then a string
to a part, to a template, andthat template is a React or a
Vue component or I think even aSvelte component, and it'll take
in those instance variables, oryou can pass them in as a
(07:33):
separate argument on the render,kind of like render JSON, and
then you pass in some JSON.
That kind of skips all the restof it.
It goes straight from yourcontroller to a React component.
There's no other step there.
So your component at that pointjust takes in whatever was
passed in from the controllerand then you're just straight in
React.
There's no other step.
Drew Bragg (07:54):
So one of the lovely things I think about working in
Rails and I've worked withsplit code bases before a Rails
backend with a it was actually aVuejs front end, but same basic
concept.
But the thing that always gaveme a little bit of a headache
was the routing.
I feel like I would define myroutes in Rails and then I would
sort of redefine them on thefront end and from what I know
(08:19):
of Inertia, it kind of solvesthat problem for you.
Adam Fortuna (08:22):
Yeah, that was one of the biggest differentiators
between Inertia and the otherReact on Rails libraries that I
was looking at.
Where those ones you wouldprobably need to use React
Router or something like thatand kind of maybe have like a
catch-all route in Rails thatrendered something and then
there's a lot of different steps.
With Inertia you can kind ofbypass that because the way that
(08:46):
it works is like within Reactor Vue or Svelte you have a
custom inertia link component, aJavaScript component, and when
you use that component to linkfrom one page to another it
doesn't do a full page load, itkind of does something kind of
more similar to Turbolinks,where it hits your controller.
So maybe you're linking frombooks to show a specific book.
(09:10):
When you click on that link togo to that specific book, it
hits the Rails route for likebooks show like it normally
would.
It renders whatever you wouldnormally render, but depending
on if it's a full html requestor an inertia request, like when
you click on a link, it loadskind of a different version of
(09:31):
that page where it's just ableto download it and then
repopulate the page with it, soit doesn't have to do a full
html reload.
It just kind of loads thecomponents and data it needs for
the new page that you'reloading up and replaces your
current state on the page withit okay, that sounds familiar to
how things kind of work inhotwire, which is kind of the
turbo links replacement.
Drew Bragg (09:52):
But based on the fact that you keep referring to
turbo links, is it safe toassume you're not super familiar
with hotwire, as how rails isyour?
Let's do air quotes here, butpreferred way of handling the
front end now.
Adam Fortuna (10:07):
Yeah, I've only done like the basic turbo links
where you don't even have anyreal JavaScript.
You're just re-rendering thepage.
Drew Bragg (10:14):
Okay, I did want to ask you about why did you choose
to stick with React versusHotwire.
If there was a specific reasonLike, oh, hotwire doesn't do
this well, but React does, so wejust stuck with it.
Or hey, we had React, our frontend was already written.
It was easier to port that inthan learn Hotwire, so we can
(10:36):
skip those questions.
That would be a rewrite insteadof a migration.
Adam Fortuna (10:40):
There you go.
Drew Bragg (10:41):
There's the difference between the rewrite
and the migration.
I hesitate to ask this questionbecause it feels very much like
the second question, but Iswear it's not.
What was the most challengingbit about going from Next over
to Rails?
Adam Fortuna (11:03):
as active record queries and then serializing
them to JSON and then sendingthem over.
I think the most difficult partwas probably just getting all
of the Vite server and Inertiaand Rails and getting all those
to work together in harmony.
Once they were all workingtogether, it was great.
But there were a lot of partswhere I'm like I'm not setting a
specific Vite variable in myDocker config or in my Docker
(11:25):
file.
I think those DevOps side partswhere it's kind of still a kind
of a new combination of thesetechnologies working together
and so relying on thedocumentation helped.
But there were a couple oftimes when I had to join the
Inertia, Slack or Discord andthey helped me out with some
roadblocks.
Drew Bragg (11:43):
That's cool.
That was a follow-up questionright there.
How is the community withInertia?
Is it very similar to the Railscommunity, a little bit
different, more React-focused,JavaScript-focused?
Adam Fortuna (11:55):
I'd say it's still very small and most people that
are using Inertia seem to beusing it with Laravel, because
Inertia started as a Laravelproject and, from what I
understand, it was split offinto its own standalone project
with adapters for additionalframeworks like Django and Rails
.
So Inertia is kind of this highlevel framework that connects
(12:15):
back-end frameworks andfront-end frameworks.
Drew Bragg (12:17):
Very cool.
What has been, for you, yourfavorite part about being back
in Rails, going from Nextjscoming back to Rails?
Other than these, oh cool, itturns out our page speed
improved and Google's ranking ushigher.
Those accidental things aregreat, for sure, but when it
comes to actually working withyour code base, now, what's been
(12:39):
?
Yes, I'm so happy to be back onRails.
Adam Fortuna (12:42):
I feel like it's just a combination of active
record and being able to justuse my models to get the data I
need for a page, rather thantrying to figure it out with
JavaScript libraries and GraphQL, and then kind of on top of
that, one of the really coollibraries we're using is OJ
(13:02):
Serializers, which is thelibrary we're using to serialize
the data that gets passed toReact.
There's this really neat add-onto that serializer that creates
TypeScript objects for thoseserializers, so we're able to
generate TypeScript types forall of our serializers and then
use those on the React side.
Even though Ruby is obviouslynot a strictly typed language,
(13:25):
we're able to strictly type whenyou pass things over to the
client side.
Drew Bragg (13:29):
That sounds very helpful if you're doing
TypeScript on the front end andcoming from Ruby.
Okay, so, as the follow-up tothe, what's been your favorite
part about coming back to Rails?
What's been your least favoritepart about coming back to Rails
?
Listen, we all know that Railsis perfect and no one would
change a thing about it.
Sarcasm aside, it's got itsrough edges.
(13:54):
It's not perfect For you.
This is a safe space.
No one's going to send you hatemail, and if they do, send them
to me and I'll set themstraight.
But, like for you personally orfor your team, especially
coming from next js, where youmight have had these nice
helpers or this way of handlingthings.
Then, coming back to rails,maybe you lost it or rails just
(14:16):
did it differently For you.
What do you think has been abit of a pain point?
Adam Fortuna (14:21):
There was one part that when we moved over, I'm
like oh, I don't even know howI'm going to move this part over
, because there wasn't a goodRails equivalent which was
generating our open graph images.
Because we were like a socialnetwork, we want people to share
everything and we want prettyopen graph images for everything
that are generated based on thecontent of that page.
So you share a list.
(14:42):
We want them to see, like theuser that shared it, some of the
books on that list.
And in Nextjs they have kind ofthis really nice interface for
creating these, where you justkind of write a component, you
actually just return HTML and itcreates a full image with it.
You can pass in fonts.
It's kind of like everything'sencapsulated in one file.
(15:04):
It was not the best to test andit had its quirks with Tailwind,
but it did work.
I tried recreating some of thatin Ruby and Rails using Grover,
which is this library that Ithink it uses, like Puppeteer or
some kind of headless browser,to like get a page and take a
screenshot and use that.
But that killed our entireserver.
The RAM usage of it spiked andI had to like split that out of
(15:28):
the main app and into its ownJavaScript service.
It just takes a URL from theRails app and then it generates
an image for that URL.
The creation of the contentstill happens on Rails, but
taking a picture of that contentand using it as an Open Graph
image happens in JavaScript.
Drew Bragg (15:45):
Interesting.
Okay.
So anyone out there looking fora side project, there you go.
Solve that problem in Rails,make it easy for Open Graph
images.
So we did briefly touch on themigration and what's been a pain
point.
But what kind of blockers doyou have, or did you have that
you want to get into?
I always find the blockersquestion a very interesting
(16:07):
question because sometimespeople will have a current one
and it'll be interesting, orsomeone will say, well, we were
really blocked on this for awhile and here's the cool way we
solved it.
And this is such an interestingproject because you don't hear
about this very often, right, alot more often you'll hear of
someone moving away from Railsinto the JavaScript ecosystem
(16:28):
because JavaScript's eating theinternet.
You kind of almost did it inreverse, but you're getting a
lot of benefits from it.
I'm interested to hear yourblockers story or stories from
this.
Adam Fortuna (16:42):
One that probably takes a little context to go
into.
So one of the reasons hardcoverwas initially started was
because Goodreads was gettingrid of their API and I used
their API to show what books Iwas reading on my blog and I'm
like, oh, I need a new booktracking site that has an API.
So I ended up starting one.
So we've been very API firstsince the start, and for our API
(17:06):
we used Hasura for it, whichgenerates a GraphQL API from a
Postgres database, and you canalso have it create GraphQL
endpoints that will delegate toAPI requests to other servers.
Create GraphQL endpoints thatwill delegate to API requests to
other servers.
So, like our Hasura app would alot of the time just get stuff
from Postgres and return that,but if something is more like a
(17:29):
service layer or something thatrequires a lot of different
changes, it'll hit Rails, railswill do some processing, it'll
return that result to Hasura andthat'll be returned to the user
of the GraphQL request.
So this big Hasura piece we'vebeen generating API keys for it
and we kind of realized thatpeople have started to abuse
(17:49):
this API because we didn'treally have anything in front of
it and we were using the freeversion, which didn't really
allow much in terms of ratelimiting or depth limiting, and
it also provided with a likequery, like a I like, for every
single field in the database.
I don't think we want peoplebeing able to do I like queries
on book descriptions when wehave 30 million books in our
(18:12):
database when we haven't indexedthat column.
So, okay, we need to dosomething with this api layer.
So we ended up creating anotherrails app and this one is a
reverse proxy to hasura.
It kind of just sits in frontof it and does rate limiting,
depth limiting, ip blocking,restricted api keys.
(18:33):
If someone like pushes theirkey up to github, we can like
invalidate it.
So it's kind of just this layerthat sits in front of it and
that one was kind of figuringout.
That solution was a big problembecause it happened because our
servers were going down.
People were hitting ourdatabase so fast and so often
that I kept having to increasethe size of our database every
(18:54):
like month or two.
On Heroku, okay, we just haveto do something about this, and
trying to figure out how to dothat when it's coasted software
with Asura and put something infront of that ended up being the
best solution so far, but we'restill kind of figuring it out
because it only has like oneserver.
It's kind of just running onone DigitalOcean droplet that
(19:16):
forwards to this GraphQL server.
But so far it's been a goodsolution Okay.
Drew Bragg (19:22):
You actually just prompted a thought in my head
about the kind of infrastructureyou have, because you've
mentioned we were having toincrease our Heroku database,
but then you also said it runson a droplet.
What are you using to host anddeploy this new Rails app?
Adam Fortuna (19:43):
using to host and deploy this new Rails app.
Yeah, right now it's prettymuch all on DigitalOcean, except
the production database, whichis still on Heroku, and I think
our Hasura API is still onHeroku and Dino's there, but
those two are scheduled to bemoved over eventually.
Drew Bragg (19:56):
Gotcha, and how are you deploying over to
DigitalOcean?
Moved over eventually, gotcha.
Adam Fortuna (19:59):
And how are you deploying over to DigitalOcean
For the main app and the APIreverse proxy in front of it?
Those are just using Kamal,which I have really, really
liked.
I'm not very good at DevOps,like to be honest.
Chatgpt has been answering alot of my DevOps questions.
Sure, yeah, but it's gotten tothe point where I can at least
deploy something and not feellike it's going to fall down in
(20:20):
five minutes.
Drew Bragg (20:22):
Right, right, I'm sure it's a little more cost
effective than being on Herokuwas also Just anyone who's been
on Heroku knows the pain of thatbill going up very quickly.
So is that Kamal 1 or Kamal 2?
Adam Fortuna (20:35):
that you're using Kamal 2.
Drew Bragg (20:36):
That you're using Small two.
Adam Fortuna (20:37):
Okay so, actually, when we moved over and I
canceled everything on Heroku,one of the services I was using
was Judo Scale, which is, Ithink, one of your sponsors.
Yes, and like Adam emailed methe automatic why did you cancel
?
And I'm like, oh yeah, we'removing to DigitalOcean, we're
canceling.
And he responded like oh yeah,you're running hardcover.
Drew Bragg (21:02):
I use hardcover too, so it's like a funny moment
there.
Judo scale is a sponsor.
Thank you to them forsponsoring the show and thank
you to them for their product,because at my day job podia, we
use judo scale, because we're onheroku also, or still, as it
were, and every month we get anemail from judo Scale like you
saved $3,000 plus, this monthyou saved $4,000.
(21:22):
It's just like, holy crap,that's awesome that we don't, a,
have to manage that scaleourselves and, b, that we can
kind of just set it and savethat money between our downtime
and uptime, because we have alot of that depending on what
our creators are doing.
Adam Fortuna (21:37):
On a similar note, having that on DigitalOcean,
with being able to scale outadditional droplets for the app,
that's something I still anunknown problem for me.
I don't know how we're going todo that yet.
Drew Bragg (21:48):
Okay, yeah, I can definitely see that.
If you're used to having Judoscale which just kind of does
the magic for you, it's very, ina way, hand wave.
You're just like I'm on fly, orI'm on Render, or I'm on Heroku
Help me Obi-Wan and it justdoes it for you.
Moving to that, I don't want tosay it, but isn't that what
Kubernetes is for?
Like?
(22:08):
Oh no, I think so.
Yeah, is that something thatyou guys are actively working on
, or is it more of like a hey,once it becomes a big enough
issue or a big enough cost forus, we'll tackle that problem.
Adam Fortuna (22:21):
Yeah, I think more the later.
For now that performance sidehasn't been an issue, so we
probably have plenty of roomthere.
Mostly because we're relyingvery heavily on solid cache for
so much, Most requests have verylittle in terms of
functionality.
Most of it is able to just beprovided from a single solid
cache request Nice and is ableto just be provided from like a
single solid cache request.
Drew Bragg (22:42):
Nice, and are you also using the other solids,
like SolidQ?
Adam Fortuna (22:45):
We're still using Sidekick.
I still like Sidekick.
Drew Bragg (22:49):
Yeah, we use Sidekick.
I'm still a fan.
I'm just always curious whensomeone is using the new stuff
to get their takes on it.
So we'll at least stick withsolid cache.
How are you liking that cachingstrategy?
Adam Fortuna (23:00):
It on it.
So we'll at least stick withsolid cache.
How are you liking that cachingstrategy?
It's just kind of worked.
I haven't really had to look atit.
I actually should probablycheck if that database is
overflowing or something.
So far it's been fine.
Drew Bragg (23:09):
That's a great sales pitch.
Or just hey, it works is afantastic way of hey, how good
is it?
Well, it just works.
That's really good.
I like it when something canjust be like oh, out of the box,
yeah, it does everything weneed, or so much of what we need
that we can say it just works,Without naming any of the things
(23:30):
we just talked about.
Sorry, to make your life moredifficult what is something cool
, new or interesting that youwant to share?
It doesn't actually have to becoding related.
You can say, hey, I just readthis great book, or I just
started this hobby.
Those are totally answers thatpeople have given and have been
awesome answers.
So I'm not making jokes.
You can pick whatever you want,but what is something cool, new
(23:50):
or interesting that you'verecently discovered, learned
about?
Adam Fortuna (23:54):
I'll kind of try to bridge that with a little
tech and a little non-tech.
So one of the areas I've beentrying to explore more is
recommendation engines, whichare this huge can of worms.
Whenever I see a site that doesrecommendations well, I'm in
awe, because a goodrecommendation engine takes in
so many inputs and for us, likea book site, you're taking in
(24:16):
data about the book, the, thegenres, the description, the
lists, it's on the author, whatother books that author has
written like tons of data andtrying to get a recommendation
out of it.
And initially I was lookinginto using like tensorflowjs and
doing that on the javascriptside.
Lately I've been kind of tryingto look into doing some of that
(24:37):
on the python side.
One of the reasons for that is,like right now one of the top
ways that people find books onhardcover is our trending books
list, which is just a popularitylist.
I kind of think about it likewhen I was a kid I would always
get the Nintendo Power Magazineand I would look at the top 20
games in every month.
I'd be like, yes, link to thePast is still number one, and
(24:58):
the trending list is kind oflike that for books.
Are the books that I am reallyexcited about.
On it.
Book I'm really excited aboutthat I'm reading right now is
the Dungeon Crawler Carl series,which has been really fun.
Definitely recommend it.
It's like RPG mixed withHitchhiker's Guide Just really
fun.
I want to create arecommendation engine for us
(25:19):
that we can use that kind ofinput.
Oh, I liked this book.
What are some books like it?
Or what are some ones that areinspired by it?
And getting an answer to thatquestion has been a lot harder
than I thought, but I feel likeI'm still in the early days of
solving it.
So if anyone has anyrecommendations on things,
especially in the Ruby world,because I feel like I'm looking
(25:40):
outside the Ruby world for itmostly I've looked at some
things in the Ruby world theDisco library, which does
collaborative filtering.
It's a really neat gem.
You can have it createrecommendations for things, but
it's only using a rating.
It doesn't use all the otherdata about a book.
So if anyone has any tips onthat, I'd definitely be open to
some research.
Drew Bragg (26:01):
Yeah, sure, that book name has popped up in my
news feeds or whatever.
I use Android devices, so theyhave this discover feed where
it'll just randomly show youarticles related to stuff you've
probably searched about or whoknows, it's probably listening
to me and I've said somethingdungeon crawlery, and so it was
(26:22):
funny to hear you bring it up.
And now I'm even moreinterested, now that you've kind
of floated the idea, an enginelike that.
Would that be consideredmachine learning, where you're
kind of taking all of this inputand building recommendations?
Or do I not understand machinelearning at all?
Adam Fortuna (26:39):
If I understand it , it's a miracle, but I believe
so.
There's so many terms throwingaround in the machine learning
world and from supervisedlearning to unsupervised
learning, and how those twostructures come together to
create a recommendation.
And yes, as far as I know, it'sstill some kind of machine
learning problem.
Drew Bragg (27:00):
For the longest time , if you wanted to do machine
learning, you weren't using Ruby, you were pretty much just
using Python.
But in recent years there'sbeen a bit of an explosion in
gems that help out with machinelearning.
Andrew Kane has a bunch ofstuff, and Landon Gray sorry if
I got your last name wrong,Landon, I'm so sorry has been
(27:21):
doing a lot of AI and machinelearning adjacent stuff in Ruby,
and so just when you were like,oh, I thought about TensorFlow
and then maybe looking in Python.
But if anybody has Ruby, I willhave to find the gem names that
I've seen pop up recently.
I have not personally used them, but pretty much anything
Andrew Cain puts out is going tobe a solid piece of awesomeness
(27:41):
.
So if he's got machine learningand Ruby gems, you can pretty
well bet that they workawesomely.
So I will give you those.
Adam Fortuna (27:50):
We're using his Disco library, which creates
recommendations, which are theones that are collaborative
filtering, just based on therating.
So, yeah, if he has other onesfor content filtering, that'd be
amazing.
Drew Bragg (28:01):
Something in my head is screaming Andrew Cain, so he
has so many libraries forcontent filtering.
That'd be amazing.
Adam Fortuna (28:04):
Something in my head is screaming Andrew Cain,
so I don't know.
He has so many libraries I feellike I haven't even touched on
half of them.
Drew Bragg (28:08):
I've reached out trying to get him on the show
just because I'm not convincedhe's a human being Like.
I am fairly certain he's acyborg, that his entire purpose
in life is just writeridiculously good gems for the
public and then disappear intonothingness, because I've never
met the man.
But he just puts out such highquality stuff and Saccard's very
lucky to have him.
Andrew, if you happen to listento the show, please come on
(28:34):
because I want to talk to you.
You sound interesting, but,adam, you've also been an
interesting guest and the wholeproject is very interesting, and
your blog post, which we'lllink in the show notes, very
clearly says part one is thislike an ongoing thing where
you're just gonna like as everystep of the way, or is there so
much more that you've donealready that wasn't covered in
(28:55):
part one that you have part twocome in, or and how many parts
do you expect to put out?
Adam Fortuna (29:01):
I end up writing really long blog posts and have
to try to split them up.
Drew Bragg (29:04):
It was great Like there was a lot of awesome
content.
I almost felt a little like,man, I shouldn't have read this
blog post before having you onthe show, just to be like, hey,
could you just read me your blogpost as a podcast episode.
Adam Fortuna (29:16):
But yeah, a lot of good information in it it was
shared on one of the newslettersI subscribe to and it always
has, like the estimated readingtime of all the other ones of
like four minutes, five minutes,and it gets to this one.
It's like half an hour.
Drew Bragg (29:29):
That's a reasonable estimation.
Adam Fortuna (29:31):
The other parts of the blog post that I split up.
I was going to do one just onmoving from cloud to the server,
from Google and AWS and Herokuto DigitalOcean and Kamal, one
for using Puppeteer to generatethose open graph images in
JavaScript, one for speeding upRails with solid cache and
Sidekick and Brick, and one forsecuring and speeding up our API
(29:55):
server.
So quite a few things wealready talked about in this one
are going to be elaborated onin that blog post.
Drew Bragg (30:01):
Yeah, no, those are all great blog posts.
I mean especially some of thoseare not common, just like you
said with the puppeteer onegenerating that.
The fact that there isn't a gem, that kind of does it for you,
means the next time someone hasto run into it.
Having a blog post is a greatway of helping the community
solve the problem, even if itisn't a gem.
I refer to so many differentblog posts that I've bookmarked
(30:24):
and I don't have to memorizethis.
I can refer back to this blogpost or this book, because
there's just so much to learnand to do so, other than your
blog series almost a book'sworth of blog series.
What is next for you and youradventures?
Adam Fortuna (30:42):
We're working on open sourcing hardcover right
now, so we're bringing on someadditional members to the team
and just cleaning it up so thatwe can make it public, probably
with the same GPL3 license thatMastodon and some other software
as a service libraries use.
That's going to be the nextthing for hardcover.
And then, personally, I juststarted a new job at Librofm,
(31:03):
which is also an audiobookcompany, so I'm able to kind of
stay doing fun stuff in the bookspace, which is fun.
Drew Bragg (31:10):
That's awesome.
I don't want to take up toomuch of your time, but if you
have the time, what's themotivation on open sourcing
hardcover, similarly to the way,like Mastodon's open source?
Is it just so that people canhave their own instances or do
you see people using it in otherways?
Adam Fortuna (31:29):
Kind of the main emphasis is that this project's
been running for four years.
It has 30,000 users, 10,000active a month.
It has a user base, but we'renot yet profitable.
Costs are basically coveringthe hosting right now, so it's
not like something that canprovide like an income for
someone working on it.
(31:50):
So that means it's a nights andweekends project for the people
that are working on it, whichmeans it's going to be very
limited just by those few people.
My hope is that we've alreadykind of created this API so
we've kind of gotten a bunch ofdevelopers that are creating
cool stuff with it.
Already People are creatingplugins so that you can track
your reading using like Kobo orlike a device and have it
(32:12):
automatically update yourprogress in hardcover.
So developers are already kindof working on hardcover.
This is kind of giving them away to contribute even more,
especially as I am doing the jobthing and won't be able to be
spending quite as much time onit.
Drew Bragg (32:26):
That makes a lot of sense.
That's cool.
It's nice when you're able toopen source something and get
kind of all that extracollaboration from folks.
I think that's one of thethings that makes Rails so great
is you have so many people ableto contribute to it.
It's not just a small team.
Writing everything would slowdown progress so much.
But because it's open sourceand people have access to go in
(32:47):
and not just report bugs butalso fix them and add features
and whatnot, I think Railsbecomes that much better because
of it, and any project that canbe open source, I think,
benefits greatly from acommunity.
So that's super cool.
Adam Fortuna (33:01):
I'm excited about it.
I've open sourced libraries,but never like an active website
project, so it's going to be anew experience for me too.
Drew Bragg (33:09):
Yeah, yeah, is there anything else that you wanted
to talk about?
Touch on, get out into public.
This is a good way of like, hey, if anybody is listening and
has solutions to any of theproblems that you've already
talked about blockers, that youhave things that are coming up
there's ways of contacting medirectly through the show and I
can hook you up with Adam, oryou'll, at the end, drop,
(33:31):
obviously, ways of reaching outand contacting you, but is there
anything else that you want totalk about before we get to that
?
Adam Fortuna (33:37):
I think we've kind of covered a good broad section
of stuff.
Drew Bragg (33:40):
Yeah, that's been a good episode.
So where can people find?
You find Hardcover, reach outon the internet.
Adam Fortuna (33:47):
You could find Hardcover at hardcoverapp.
Find me at adamfortunacom or onbluesky at adamfortunacom.
I'm most active on Blue Sky andHardcover nowadays.
Drew Bragg (33:59):
Very cool.
I appreciate you spending timeto talk about the cool things
that you guys are doing.
Greatly appreciate the blogpost.
I'm looking forward to the restof the series and next time you
are working on something cool,feel free to reach out and we'll
get you back on the show andwe'll talk again about what
things you're working on andwhat cool, new, interesting
things you have to share.
(34:20):
Sounds good.
This has.
This has been fun, drew.
Yeah, thanks, and audience.
I'll talk to you in the nextone because I still don't know
how to end my own show.
Bye, bye.
Hello everyone and welcome to another episode of
Code and the Code Encoders.
Who Code it?
I'm your host, drew Bragg, andI'm joined today by Adam Fortuna
.
Adam, for anyone who's notfamiliar with you, would you
please give us a little bit ofbackground on yourself.
Adam Fortuna (00:13):
Hey, hey, I'm Adam .
I think maybe some Rails andRuby developers might know me
from working at Code Schooldoing interactive courses.
Some people might know me froma financial blog I wrote for a
couple of years called Minifyyou, minify JavaScript that's
kind of the emphasis of the name.
Lately I've been working onHardcover, which is a social
(00:34):
network for readers to findbooks and get recommendations
from friends, all right.
Drew Bragg (00:40):
So the way this is going to work for anyone new to
the show is I'm going to askAdam three questions.
I'm going to ask him what he'sworking on, what kind of
blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent blocker he had, how hewent about solving it.
And then we'll wrap up the showby asking Adam what's something
cool, new or interesting thathe's recently learned or
discovered.
It doesn't have to be codingrelated, but of course it always
(01:00):
can be so without any furtherado, adam, what are you working
on?
Adam Fortuna (01:13):
I just finished a really big migration for
hardcovers codebase where wemigrated from Nextjs to Ruby on
Rails and that ended up takingquite a bit of time.
Some of our back end wasalready in Rails but our front
end was in Next.
That migration really took overmy life for quite a few months
lately.
Drew Bragg (01:29):
That's not a quick and easy migration.
So, in your mind at least, whatwould you consider?
The difference between amigration and a rewrite Depends
on how much you're able to reuse.
Adam Fortuna (01:40):
All of our front end was in React within Nextjs,
so we were able to keep thatpiece and move it over to Rails,
so that part was able to reuse.
All of our front end was inReact within Nextjs, so we were
able to keep that piece and moveit over to Rails, so that part
was able to be migrated.
And the part that had to berewritten was all of that data
access layer, because previouslyin Nextjs we were hitting a
GraphQL API and getting our dataand then sending that to React
or sometimes getting it clientside and using that in React.
(02:02):
This pretty much changed it allto just using it in Rails,
getting it from ActiveRecord inthe database, serializing it to
JSON and sending it to React.
So, yeah, it was a bit of acombination of those two.
Drew Bragg (02:16):
And you recently wrote a fairly detailed blog
post or at least a part one blogpost on doing this and you go
into quite a bit of it and theone part that stuck out to me a
bit was the performanceimprovement that you guys saw
and I think that's to a lot ofpeople probably surprising to
hear like, hey, we used Ruby onRails and got better performance
(02:37):
.
It's not surprising to mostRails devs to hear that, but it
could be anyone listening whoisn't familiar enough with Rails
and may just know the oh, itdoesn't scale.
It's not performant nonsensethat people talk about.
Can you talk a little bit aboutthe performance improvements
that you're seeing and any sayspeculations you have onto what
(02:58):
is helping the most with that?
Adam Fortuna (03:00):
So initially, when the project started back in
2021-ish, I really wanted to dosomething that was really
interactive.
So that's kind of why React waschosen as the front end.
I'm a Rails developer for quitea long time, but I didn't
choose Rails for it initiallybecause the server-side
rendering side if you're doing aJavaScript app within Rails
(03:22):
five years ago that had acompletely different way to do
it.
So, like with Nextjs, we wereable to render the server-side,
render all the HTML, so thefirst load gets all the HTML of
the page you need and then it'shydrated with React.
But we weren't able to do thatwith Rails until recently, where
now we were able to do thatusing a combination of Vite and
(03:43):
SSR and Inertia to take this bigReact tree, render it to HTML
and send that as the first load,and so that kind of meant there
was parity there between whatwould be loaded initially from
Next and Rails.
I wasn't expecting muchimprovement beyond that.
Next actually handles a lot ofcases really well, like fonts it
(04:06):
does some really cool thingsfor those where it loads them in
really fast ways, and someother just speed improvements
for Google PageSpeed but I waskind of surprised at how well
Rails was able to do that.
But on top of that we wereseeing startup times for the
initial requests.
That took a little bit longeron serverless functions, with
Next even on Vercel or GoogleCloud Run, and then when we
(04:29):
moved to Rails, even justdeploying on digital ocean
droplets, those time to firstbyte metrics ended up speeding
up significantly and that endedup being the biggest boost to
our Google page speed.
Drew Bragg (04:42):
Right, and you said that actually helps a lot with
how Google ends up ranking youin their search.
So it's an SEO kind of thing.
I don't know if you wouldconsider it out of the box, but
it almost sounds like it was anaccident, that those things like
that wasn't the targetimprovement.
You were just making the moveand then noticed, hey, we're
getting these side benefits thatwe weren't expecting.
Adam Fortuna (05:05):
Yeah, the baseline was really not dropping our SEO
.
Drew Bragg (05:09):
But incidentally, you talk a little bit in the
blog about that actually beingpart of the reason why you chose
Next in the beginning becauseyou wanted to React front end
for the interactivity.
But because React doesn'tactually load up a page right
off the bat, google was going tokind of not be able to pick up
on a lot of your SEO and whatnotand cause a hit to your page
(05:34):
speed.
So you choose Nextjs for thatserver rendering component.
But then it actually improvedeven more when you got to Rails.
Adam Fortuna (05:42):
Right, exactly.
Drew Bragg (05:43):
Yeah, what was it like working with Inertia?
Because I've heard lots aboutit, I know its existence, I've
heard good things about it, butI haven't played with it myself.
So what do you think aboutInertia as part of a Rails
project?
Adam Fortuna (05:58):
So I feel like Inertia was the missing piece
for me for Rails for a long time.
The sanctioned Rails path forgenerating like JavaScript apps
has changed quite a bit over theyears.
We had like RJS for a while andthings like that, and then more
recently it's been likestimulus, or you just use
Turbolinks and just re-renderthe entire page or something
(06:19):
like that.
Drew Bragg (06:21):
Yeah, Hotwire is the new Turbolinks at least, and
that's a follow-up question Iwant to talk more about Inertia,
but then I want to talk alittle bit about Hotwire.
Adam Fortuna (06:30):
So, yeah, carry on with Inertia, I'd kind of spent
so much time learning React Ihadn't learned the stimulus,
that side of Rails.
So when I was thinking abouthow to use this React app on
Rails, there were like threemajor gems that kept coming up.
(06:50):
I think there's like a React onRails and a React Rails one,
and those handle things indifferent ways, but inertia
ended up being kind of the mostlightweight of them all and it
felt the most Rails-y of themall.
So I think about it like in acontroller of them all.
So I think about it like in acontroller you set some instance
variables and those get passedto a view.
(07:10):
Usually With inertia you can dothat exact same thing.
Just set some variables in acontroller and you can either
call render I think it's renderinertia, colon and then a string
to a part, to a template, andthat template is a React or a
Vue component or I think even aSvelte component, and it'll take
in those instance variables, oryou can pass them in as a
(07:33):
separate argument on the render,kind of like render JSON, and
then you pass in some JSON.
That kind of skips all the restof it.
It goes straight from yourcontroller to a React component.
There's no other step there.
So your component at that pointjust takes in whatever was
passed in from the controllerand then you're just straight in
React.
There's no other step.
Drew Bragg (07:54):
So one of the lovely things I think about working in
Rails and I've worked withsplit code bases before a Rails
backend with a it was actually aVuejs front end, but same basic
concept.
But the thing that always gaveme a little bit of a headache
was the routing.
I feel like I would define myroutes in Rails and then I would
sort of redefine them on thefront end and from what I know
(08:19):
of Inertia, it kind of solvesthat problem for you.
Adam Fortuna (08:22):
Yeah, that was one of the biggest differentiators
between Inertia and the otherReact on Rails libraries that I
was looking at.
Where those ones you wouldprobably need to use React
Router or something like thatand kind of maybe have like a
catch-all route in Rails thatrendered something and then
there's a lot of different steps.
With Inertia you can kind ofbypass that because the way that
(08:46):
it works is like within Reactor Vue or Svelte you have a
custom inertia link component, aJavaScript component, and when
you use that component to linkfrom one page to another it
doesn't do a full page load, itkind of does something kind of
more similar to Turbolinks,where it hits your controller.
So maybe you're linking frombooks to show a specific book.
(09:10):
When you click on that link togo to that specific book, it
hits the Rails route for likebooks show like it normally
would.
It renders whatever you wouldnormally render, but depending
on if it's a full html requestor an inertia request, like when
you click on a link, it loadskind of a different version of
(09:31):
that page where it's just ableto download it and then
repopulate the page with it, soit doesn't have to do a full
html reload.
It just kind of loads thecomponents and data it needs for
the new page that you'reloading up and replaces your
current state on the page withit okay, that sounds familiar to
how things kind of work inhotwire, which is kind of the
turbo links replacement.
Drew Bragg (09:52):
But based on the fact that you keep referring to
turbo links, is it safe toassume you're not super familiar
with hotwire, as how rails isyour?
Let's do air quotes here, butpreferred way of handling the
front end now.
Adam Fortuna (10:07):
Yeah, I've only done like the basic turbo links
where you don't even have anyreal JavaScript.
You're just re-rendering thepage.
Drew Bragg (10:14):
Okay, I did want to ask you about why did you choose
to stick with React versusHotwire.
If there was a specific reasonLike, oh, hotwire doesn't do
this well, but React does, so wejust stuck with it.
Or hey, we had React, our frontend was already written.
It was easier to port that inthan learn Hotwire, so we can
(10:36):
skip those questions.
That would be a rewrite insteadof a migration.
Adam Fortuna (10:40):
There you go.
Drew Bragg (10:41):
There's the difference between the rewrite
and the migration.
I hesitate to ask this questionbecause it feels very much like
the second question, but Iswear it's not.
What was the most challengingbit about going from Next over
to Rails?
Adam Fortuna (11:03):
as active record queries and then serializing
them to JSON and then sendingthem over.
I think the most difficult partwas probably just getting all
of the Vite server and Inertiaand Rails and getting all those
to work together in harmony.
Once they were all workingtogether, it was great.
But there were a lot of partswhere I'm like I'm not setting a
specific Vite variable in myDocker config or in my Docker
(11:25):
file.
I think those DevOps side partswhere it's kind of still a kind
of a new combination of thesetechnologies working together
and so relying on thedocumentation helped.
But there were a couple oftimes when I had to join the
Inertia, Slack or Discord andthey helped me out with some
roadblocks.
Drew Bragg (11:43):
That's cool.
That was a follow-up questionright there.
How is the community withInertia?
Is it very similar to the Railscommunity, a little bit
different, more React-focused,JavaScript-focused?
Adam Fortuna (11:55):
I'd say it's still very small and most people that
are using Inertia seem to beusing it with Laravel, because
Inertia started as a Laravelproject and, from what I
understand, it was split offinto its own standalone project
with adapters for additionalframeworks like Django and Rails
.
So Inertia is kind of this highlevel framework that connects
(12:15):
back-end frameworks andfront-end frameworks.
Drew Bragg (12:17):
Very cool.
What has been, for you, yourfavorite part about being back
in Rails, going from Nextjscoming back to Rails?
Other than these, oh cool, itturns out our page speed
improved and Google's ranking ushigher.
Those accidental things aregreat, for sure, but when it
comes to actually working withyour code base, now, what's been
(12:39):
?
Yes, I'm so happy to be back onRails.
Adam Fortuna (12:42):
I feel like it's just a combination of active
record and being able to justuse my models to get the data I
need for a page, rather thantrying to figure it out with
JavaScript libraries and GraphQL, and then kind of on top of
that, one of the really coollibraries we're using is OJ
(13:02):
Serializers, which is thelibrary we're using to serialize
the data that gets passed toReact.
There's this really neat add-onto that serializer that creates
TypeScript objects for thoseserializers, so we're able to
generate TypeScript types forall of our serializers and then
use those on the React side.
Even though Ruby is obviouslynot a strictly typed language,
(13:25):
we're able to strictly type whenyou pass things over to the
client side.
Drew Bragg (13:29):
That sounds very helpful if you're doing
TypeScript on the front end andcoming from Ruby.
Okay, so, as the follow-up tothe, what's been your favorite
part about coming back to Rails?
What's been your least favoritepart about coming back to Rails
?
Listen, we all know that Railsis perfect and no one would
change a thing about it.
Sarcasm aside, it's got itsrough edges.
(13:54):
It's not perfect For you.
This is a safe space.
No one's going to send you hatemail, and if they do, send them
to me and I'll set themstraight.
But, like for you personally orfor your team, especially
coming from next js, where youmight have had these nice
helpers or this way of handlingthings.
Then, coming back to rails,maybe you lost it or rails just
(14:16):
did it differently For you.
What do you think has been abit of a pain point?
Adam Fortuna (14:21):
There was one part that when we moved over, I'm
like oh, I don't even know howI'm going to move this part over
, because there wasn't a goodRails equivalent which was
generating our open graph images.
Because we were like a socialnetwork, we want people to share
everything and we want prettyopen graph images for everything
that are generated based on thecontent of that page.
So you share a list.
(14:42):
We want them to see, like theuser that shared it, some of the
books on that list.
And in Nextjs they have kind ofthis really nice interface for
creating these, where you justkind of write a component, you
actually just return HTML and itcreates a full image with it.
You can pass in fonts.
It's kind of like everything'sencapsulated in one file.
(15:04):
It was not the best to test andit had its quirks with Tailwind,
but it did work.
I tried recreating some of thatin Ruby and Rails using Grover,
which is this library that Ithink it uses, like Puppeteer or
some kind of headless browser,to like get a page and take a
screenshot and use that.
But that killed our entireserver.
The RAM usage of it spiked andI had to like split that out of
(15:28):
the main app and into its ownJavaScript service.
It just takes a URL from theRails app and then it generates
an image for that URL.
The creation of the contentstill happens on Rails, but
taking a picture of that contentand using it as an Open Graph
image happens in JavaScript.
Drew Bragg (15:45):
Interesting.
Okay.
So anyone out there looking fora side project, there you go.
Solve that problem in Rails,make it easy for Open Graph
images.
So we did briefly touch on themigration and what's been a pain
point.
But what kind of blockers doyou have, or did you have that
you want to get into?
I always find the blockersquestion a very interesting
(16:07):
question because sometimespeople will have a current one
and it'll be interesting, orsomeone will say, well, we were
really blocked on this for awhile and here's the cool way we
solved it.
And this is such an interestingproject because you don't hear
about this very often, right, alot more often you'll hear of
someone moving away from Railsinto the JavaScript ecosystem
(16:28):
because JavaScript's eating theinternet.
You kind of almost did it inreverse, but you're getting a
lot of benefits from it.
I'm interested to hear yourblockers story or stories from
this.
Adam Fortuna (16:42):
One that probably takes a little context to go
into.
So one of the reasons hardcoverwas initially started was
because Goodreads was gettingrid of their API and I used
their API to show what books Iwas reading on my blog and I'm
like, oh, I need a new booktracking site that has an API.
So I ended up starting one.
So we've been very API firstsince the start, and for our API
(17:06):
we used Hasura for it, whichgenerates a GraphQL API from a
Postgres database, and you canalso have it create GraphQL
endpoints that will delegate toAPI requests to other servers.
Create GraphQL endpoints thatwill delegate to API requests to
other servers.
So, like our Hasura app would alot of the time just get stuff
from Postgres and return that,but if something is more like a
(17:29):
service layer or something thatrequires a lot of different
changes, it'll hit Rails, railswill do some processing, it'll
return that result to Hasura andthat'll be returned to the user
of the GraphQL request.
So this big Hasura piece we'vebeen generating API keys for it
and we kind of realized thatpeople have started to abuse
(17:49):
this API because we didn'treally have anything in front of
it and we were using the freeversion, which didn't really
allow much in terms of ratelimiting or depth limiting, and
it also provided with a likequery, like a I like, for every
single field in the database.
I don't think we want peoplebeing able to do I like queries
on book descriptions when wehave 30 million books in our
(18:12):
database when we haven't indexedthat column.
So, okay, we need to dosomething with this api layer.
So we ended up creating anotherrails app and this one is a
reverse proxy to hasura.
It kind of just sits in frontof it and does rate limiting,
depth limiting, ip blocking,restricted api keys.
(18:33):
If someone like pushes theirkey up to github, we can like
invalidate it.
So it's kind of just this layerthat sits in front of it and
that one was kind of figuringout.
That solution was a big problembecause it happened because our
servers were going down.
People were hitting ourdatabase so fast and so often
that I kept having to increasethe size of our database every
(18:54):
like month or two.
On Heroku, okay, we just haveto do something about this, and
trying to figure out how to dothat when it's coasted software
with Asura and put something infront of that ended up being the
best solution so far, but we'restill kind of figuring it out
because it only has like oneserver.
It's kind of just running onone DigitalOcean droplet that
(19:16):
forwards to this GraphQL server.
But so far it's been a goodsolution Okay.
Drew Bragg (19:22):
You actually just prompted a thought in my head
about the kind of infrastructureyou have, because you've
mentioned we were having toincrease our Heroku database,
but then you also said it runson a droplet.
What are you using to host anddeploy this new Rails app?
Adam Fortuna (19:43):
using to host and deploy this new Rails app.
Yeah, right now it's prettymuch all on DigitalOcean, except
the production database, whichis still on Heroku, and I think
our Hasura API is still onHeroku and Dino's there, but
those two are scheduled to bemoved over eventually.
Drew Bragg (19:56):
Gotcha, and how are you deploying over to
DigitalOcean?
Moved over eventually, gotcha.
Adam Fortuna (19:59):
And how are you deploying over to DigitalOcean
For the main app and the APIreverse proxy in front of it?
Those are just using Kamal,which I have really, really
liked.
I'm not very good at DevOps,like to be honest.
Chatgpt has been answering alot of my DevOps questions.
Sure, yeah, but it's gotten tothe point where I can at least
deploy something and not feellike it's going to fall down in
(20:20):
five minutes.
Drew Bragg (20:22):
Right, right, I'm sure it's a little more cost
effective than being on Herokuwas also Just anyone who's been
on Heroku knows the pain of thatbill going up very quickly.
So is that Kamal 1 or Kamal 2?
Adam Fortuna (20:35):
that you're using Kamal 2.
Drew Bragg (20:36):
That you're using Small two.
Adam Fortuna (20:37):
Okay so, actually, when we moved over and I
canceled everything on Heroku,one of the services I was using
was Judo Scale, which is, Ithink, one of your sponsors.
Yes, and like Adam emailed methe automatic why did you cancel
?
And I'm like, oh yeah, we'removing to DigitalOcean, we're
canceling.
And he responded like oh yeah,you're running hardcover.
Drew Bragg (21:02):
I use hardcover too, so it's like a funny moment
there.
Judo scale is a sponsor.
Thank you to them forsponsoring the show and thank
you to them for their product,because at my day job podia, we
use judo scale, because we're onheroku also, or still, as it
were, and every month we get anemail from judo Scale like you
saved $3,000 plus, this monthyou saved $4,000.
(21:22):
It's just like, holy crap,that's awesome that we don't, a,
have to manage that scaleourselves and, b, that we can
kind of just set it and savethat money between our downtime
and uptime, because we have alot of that depending on what
our creators are doing.
Adam Fortuna (21:37):
On a similar note, having that on DigitalOcean,
with being able to scale outadditional droplets for the app,
that's something I still anunknown problem for me.
I don't know how we're going todo that yet.
Drew Bragg (21:48):
Okay, yeah, I can definitely see that.
If you're used to having Judoscale which just kind of does
the magic for you, it's very, ina way, hand wave.
You're just like I'm on fly, orI'm on Render, or I'm on Heroku
Help me Obi-Wan and it justdoes it for you.
Moving to that, I don't want tosay it, but isn't that what
Kubernetes is for?
Like?
(22:08):
Oh no, I think so.
Yeah, is that something thatyou guys are actively working on
, or is it more of like a hey,once it becomes a big enough
issue or a big enough cost forus, we'll tackle that problem.
Adam Fortuna (22:21):
Yeah, I think more the later.
For now that performance sidehasn't been an issue, so we
probably have plenty of roomthere.
Mostly because we're relyingvery heavily on solid cache for
so much, Most requests have verylittle in terms of
functionality.
Most of it is able to just beprovided from a single solid
cache request Nice and is ableto just be provided from like a
single solid cache request.
Drew Bragg (22:42):
Nice, and are you also using the other solids,
like SolidQ?
Adam Fortuna (22:45):
We're still using Sidekick.
I still like Sidekick.
Drew Bragg (22:49):
Yeah, we use Sidekick.
I'm still a fan.
I'm just always curious whensomeone is using the new stuff
to get their takes on it.
So we'll at least stick withsolid cache.
How are you liking that cachingstrategy?
Adam Fortuna (23:00):
It on it.
So we'll at least stick withsolid cache.
How are you liking that cachingstrategy?
It's just kind of worked.
I haven't really had to look atit.
I actually should probablycheck if that database is
overflowing or something.
So far it's been fine.
Drew Bragg (23:09):
That's a great sales pitch.
Or just hey, it works is afantastic way of hey, how good
is it?
Well, it just works.
That's really good.
I like it when something canjust be like oh, out of the box,
yeah, it does everything weneed, or so much of what we need
that we can say it just works,Without naming any of the things
(23:30):
we just talked about.
Sorry, to make your life moredifficult what is something cool
, new or interesting that youwant to share?
It doesn't actually have to becoding related.
You can say, hey, I just readthis great book, or I just
started this hobby.
Those are totally answers thatpeople have given and have been
awesome answers.
So I'm not making jokes.
You can pick whatever you want,but what is something cool, new
(23:50):
or interesting that you'verecently discovered, learned
about?
Adam Fortuna (23:54):
I'll kind of try to bridge that with a little
tech and a little non-tech.
So one of the areas I've beentrying to explore more is
recommendation engines, whichare this huge can of worms.
Whenever I see a site that doesrecommendations well, I'm in
awe, because a goodrecommendation engine takes in
so many inputs and for us, likea book site, you're taking in
(24:16):
data about the book, the, thegenres, the description, the
lists, it's on the author, whatother books that author has
written like tons of data andtrying to get a recommendation
out of it.
And initially I was lookinginto using like tensorflowjs and
doing that on the javascriptside.
Lately I've been kind of tryingto look into doing some of that
(24:37):
on the python side.
One of the reasons for that is,like right now one of the top
ways that people find books onhardcover is our trending books
list, which is just a popularitylist.
I kind of think about it likewhen I was a kid I would always
get the Nintendo Power Magazineand I would look at the top 20
games in every month.
I'd be like, yes, link to thePast is still number one, and
(24:58):
the trending list is kind oflike that for books.
Are the books that I am reallyexcited about.
On it.
Book I'm really excited aboutthat I'm reading right now is
the Dungeon Crawler Carl series,which has been really fun.
Definitely recommend it.
It's like RPG mixed withHitchhiker's Guide Just really
fun.
I want to create arecommendation engine for us
(25:19):
that we can use that kind ofinput.
Oh, I liked this book.
What are some books like it?
Or what are some ones that areinspired by it?
And getting an answer to thatquestion has been a lot harder
than I thought, but I feel likeI'm still in the early days of
solving it.
So if anyone has anyrecommendations on things,
especially in the Ruby world,because I feel like I'm looking
(25:40):
outside the Ruby world for itmostly I've looked at some
things in the Ruby world theDisco library, which does
collaborative filtering.
It's a really neat gem.
You can have it createrecommendations for things, but
it's only using a rating.
It doesn't use all the otherdata about a book.
So if anyone has any tips onthat, I'd definitely be open to
some research.
Drew Bragg (26:01):
Yeah, sure, that book name has popped up in my
news feeds or whatever.
I use Android devices, so theyhave this discover feed where
it'll just randomly show youarticles related to stuff you've
probably searched about or whoknows, it's probably listening
to me and I've said somethingdungeon crawlery, and so it was
(26:22):
funny to hear you bring it up.
And now I'm even moreinterested, now that you've kind
of floated the idea, an enginelike that.
Would that be consideredmachine learning, where you're
kind of taking all of this inputand building recommendations?
Or do I not understand machinelearning at all?
Adam Fortuna (26:39):
If I understand it , it's a miracle, but I believe
so.
There's so many terms throwingaround in the machine learning
world and from supervisedlearning to unsupervised
learning, and how those twostructures come together to
create a recommendation.
And yes, as far as I know, it'sstill some kind of machine
learning problem.
Drew Bragg (27:00):
For the longest time , if you wanted to do machine
learning, you weren't using Ruby, you were pretty much just
using Python.
But in recent years there'sbeen a bit of an explosion in
gems that help out with machinelearning.
Andrew Kane has a bunch ofstuff, and Landon Gray sorry if
I got your last name wrong,Landon, I'm so sorry has been
(27:21):
doing a lot of AI and machinelearning adjacent stuff in Ruby,
and so just when you were like,oh, I thought about TensorFlow
and then maybe looking in Python.
But if anybody has Ruby, I willhave to find the gem names that
I've seen pop up recently.
I have not personally used them, but pretty much anything
Andrew Cain puts out is going tobe a solid piece of awesomeness
(27:41):
.
So if he's got machine learningand Ruby gems, you can pretty
well bet that they workawesomely.
So I will give you those.
Adam Fortuna (27:50):
We're using his Disco library, which creates
recommendations, which are theones that are collaborative
filtering, just based on therating.
So, yeah, if he has other onesfor content filtering, that'd be
amazing.
Drew Bragg (28:01):
Something in my head is screaming Andrew Cain, so he
has so many libraries forcontent filtering.
That'd be amazing.
Adam Fortuna (28:04):
Something in my head is screaming Andrew Cain,
so I don't know.
He has so many libraries I feellike I haven't even touched on
half of them.
Drew Bragg (28:08):
I've reached out trying to get him on the show
just because I'm not convincedhe's a human being Like.
I am fairly certain he's acyborg, that his entire purpose
in life is just writeridiculously good gems for the
public and then disappear intonothingness, because I've never
met the man.
But he just puts out such highquality stuff and Saccard's very
lucky to have him.
Andrew, if you happen to listento the show, please come on
(28:34):
because I want to talk to you.
You sound interesting, but,adam, you've also been an
interesting guest and the wholeproject is very interesting, and
your blog post, which we'lllink in the show notes, very
clearly says part one is thislike an ongoing thing where
you're just gonna like as everystep of the way, or is there so
much more that you've donealready that wasn't covered in
(28:55):
part one that you have part twocome in, or and how many parts
do you expect to put out?
Adam Fortuna (29:01):
I end up writing really long blog posts and have
to try to split them up.
Drew Bragg (29:04):
It was great Like there was a lot of awesome
content.
I almost felt a little like,man, I shouldn't have read this
blog post before having you onthe show, just to be like, hey,
could you just read me your blogpost as a podcast episode.
Adam Fortuna (29:16):
But yeah, a lot of good information in it it was
shared on one of the newslettersI subscribe to and it always
has, like the estimated readingtime of all the other ones of
like four minutes, five minutes,and it gets to this one.
It's like half an hour.
Drew Bragg (29:29):
That's a reasonable estimation.
Adam Fortuna (29:31):
The other parts of the blog post that I split up.
I was going to do one just onmoving from cloud to the server,
from Google and AWS and Herokuto DigitalOcean and Kamal, one
for using Puppeteer to generatethose open graph images in
JavaScript, one for speeding upRails with solid cache and
Sidekick and Brick, and one forsecuring and speeding up our API
(29:55):
server.
So quite a few things wealready talked about in this one
are going to be elaborated onin that blog post.
Drew Bragg (30:01):
Yeah, no, those are all great blog posts.
I mean especially some of thoseare not common, just like you
said with the puppeteer onegenerating that.
The fact that there isn't a gem, that kind of does it for you,
means the next time someone hasto run into it.
Having a blog post is a greatway of helping the community
solve the problem, even if itisn't a gem.
I refer to so many differentblog posts that I've bookmarked
(30:24):
and I don't have to memorizethis.
I can refer back to this blogpost or this book, because
there's just so much to learnand to do so, other than your
blog series almost a book'sworth of blog series.
What is next for you and youradventures?
Adam Fortuna (30:42):
We're working on open sourcing hardcover right
now, so we're bringing on someadditional members to the team
and just cleaning it up so thatwe can make it public, probably
with the same GPL3 license thatMastodon and some other software
as a service libraries use.
That's going to be the nextthing for hardcover.
And then, personally, I juststarted a new job at Librofm,
(31:03):
which is also an audiobookcompany, so I'm able to kind of
stay doing fun stuff in the bookspace, which is fun.
Drew Bragg (31:10):
That's awesome.
I don't want to take up toomuch of your time, but if you
have the time, what's themotivation on open sourcing
hardcover, similarly to the way,like Mastodon's open source?
Is it just so that people canhave their own instances or do
you see people using it in otherways?
Adam Fortuna (31:29):
Kind of the main emphasis is that this project's
been running for four years.
It has 30,000 users, 10,000active a month.
It has a user base, but we'renot yet profitable.
Costs are basically coveringthe hosting right now, so it's
not like something that canprovide like an income for
someone working on it.
(31:50):
So that means it's a nights andweekends project for the people
that are working on it, whichmeans it's going to be very
limited just by those few people.
My hope is that we've alreadykind of created this API so
we've kind of gotten a bunch ofdevelopers that are creating
cool stuff with it.
Already People are creatingplugins so that you can track
your reading using like Kobo orlike a device and have it
(32:12):
automatically update yourprogress in hardcover.
So developers are already kindof working on hardcover.
This is kind of giving them away to contribute even more,
especially as I am doing the jobthing and won't be able to be
spending quite as much time onit.
Drew Bragg (32:26):
That makes a lot of sense.
That's cool.
It's nice when you're able toopen source something and get
kind of all that extracollaboration from folks.
I think that's one of thethings that makes Rails so great
is you have so many people ableto contribute to it.
It's not just a small team.
Writing everything would slowdown progress so much.
But because it's open sourceand people have access to go in
(32:47):
and not just report bugs butalso fix them and add features
and whatnot, I think Railsbecomes that much better because
of it, and any project that canbe open source, I think,
benefits greatly from acommunity.
So that's super cool.
Adam Fortuna (33:01):
I'm excited about it.
I've open sourced libraries,but never like an active website
project, so it's going to be anew experience for me too.
Drew Bragg (33:09):
Yeah, yeah, is there anything else that you wanted
to talk about?
Touch on, get out into public.
This is a good way of like, hey, if anybody is listening and
has solutions to any of theproblems that you've already
talked about blockers, that youhave things that are coming up
there's ways of contacting medirectly through the show and I
can hook you up with Adam, oryou'll, at the end, drop,
(33:31):
obviously, ways of reaching outand contacting you, but is there
anything else that you want totalk about before we get to that
?
Adam Fortuna (33:37):
I think we've kind of covered a good broad section
of stuff.
Drew Bragg (33:40):
Yeah, that's been a good episode.
So where can people find?
You find Hardcover, reach outon the internet.
Adam Fortuna (33:47):
You could find Hardcover at hardcoverapp.
Find me at adamfortunacom or onbluesky at adamfortunacom.
I'm most active on Blue Sky andHardcover nowadays.
Drew Bragg (33:59):
Very cool.
I appreciate you spending timeto talk about the cool things
that you guys are doing.
Greatly appreciate the blogpost.
I'm looking forward to the restof the series and next time you
are working on something cool,feel free to reach out and we'll
get you back on the show andwe'll talk again about what
things you're working on andwhat cool, new, interesting
things you have to share.
(34:20):
Sounds good.
This has.
This has been fun, drew.
Yeah, thanks, and audience.
I'll talk to you in the nextone because I still don't know
how to end my own show.
Bye, bye.
Popular Podcasts
Bookmarked by Reese's Book Club
Welcome to Bookmarked by Reese’s Book Club — the podcast where great stories, bold women, and irresistible conversations collide! Hosted by award-winning journalist Danielle Robay, each week new episodes balance thoughtful literary insight with the fervor of buzzy book trends, pop culture and more. Bookmarked brings together celebrities, tastemakers, influencers and authors from Reese's Book Club and beyond to share stories that transcend the page. Pull up a chair. You’re not just listening — you’re part of the conversation.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com