Launched ValheimServerHosting.com on Lucky

[xaviablaza]

👋 Hello everyone! I wanted to share my latest project that recently launched into production a couple of days ago.

I noticed that Valheim was gaining popularity and I wanted to launch a server hosting website after being inspired by this post on Indiehackers. Just had to scratch that entrepreneurial itch and actually build something.

I built Valheim Server Hosting using Lucky over the course of four weekends. Coming from a Rails background, it wasn't so easy to find the shards that I needed for the site to work. There were lots of times where I had to write something from scratch as opposed to using a shard for it. For example, I did run into some bumps in the road while integrating:

Connecting to a CMS for i18n integration
We used Editmode.com's API for this, and had to write a custom integration that stores content in cache using the redis shard. This spawned makisu/editmode.cr. In Rails, you'd use something like the Rails cache and its magic -- Lucky strips away that magic since it doesn't have that feature. So, I was forced to think at a much lower-level on how you want to cache data.

ActiveStorage-esque file uploads
Shrine didn't work so well for me as I wanted something interactive to show file upload progress, so I decided to go with React + Dropzone.js to achieve this, and just maintain S3 keys on my Avram models to generate presigned urls to those files

Asynchronous workers
I actually use both mosquito and sidekiq.cr in my Lucky project. I mainly use Mosquito::PeriodicJob to schedule cron jobs and sidekiq.cr to schedule the rest of my jobs. Hopefully we get to see a client that attaches to faktory -- I've tried that shard and it seems like it's broken.

Emails
I'm subscribed to a Postmark plan, so naturally I wanted to use Postmark. I created makisu/carbon_postmark_adapter that has a rudimentary API to send Postmark templates on top of sending plain HTML.

Experience Building with Lucky

Overall, my experience building with Lucky was pretty good. I didn't have to write much tests because the compiler handled the testing for me. It's interesting to go back to working in typed languages, and as a Ruby developer, I think some of us have been too coddled around doing things the "Rails" way. One thing I also miss about Rails that I wish was in Lucky is something similar to the Rails Console. For me to take a look at the state of the database, I had to connect DataGrip to my production database to check for any data inconsistency issues (mainly due to the way that I code).

I'd love to discuss anything related to Crystal & Lucky and building apps for production on here, on my Twitter, or on IndieHackers. Feel free to connect with me!

[matthewmcgarvey]

This is great! Keep up the good work @xaviablaza!

[robacarp]

@xaviablaza I'd love any feedback you have on mosquito and how sidekiq met your needs better.

[xaviablaza]

In my particular use case, I needed scheduled jobs. I found sidekiq's perform_at and perform_in interface to work perfectly. I also like Sidekiq's Web UI which allows me to look at jobs that have failed and which are currently retrying

[jwoertink]

This is awesome! I haven't played that game yet, but just started hearing about it.

I feel your pain points with missing shards, but that sort of comes with the territory, right? As where Rails is a high school teen learning to drive, Lucky is starting kindergarten this year. 😂 I think a lot of people tend to get scared off from the lack of security blanket from not as many libraries, so I want to stress how huge and amazing this is that you took Lucky all the way to production. Your insight and experience will really help others to take that leap, and as more people take that leap, they will build those shards we need to further launch this to the next level!

I didn't have to write much tests because the compiler handled the testing for me.

☝️ this is really what makes Lucky different ❤️ Of all the projects I've launch to production, our team says the same thing. We have tests to handle the tricky bits, but not nearly the suite size that we had in Rails, and our confidence that the app is stable went up 10x