Moving my Serverless project to Ruby on Rails

100% agree - Coming from a non-engineering background but falling in love w/ developing I was always amazed on how easily smart engineers fall for hyped up useless tech.

Like, you can literally do anything using Ruby on Rails or Django or Laravel - proven, reliable, boring stuff that powers the internet. Yet, somehow people decide to build stuff that puts food on the table on some brand new hyped tech with 0 track record.

If you want to learn, learn. If you want to build, build with things with a track record.

I heard sometime on FunFunFunction (the YouTube channel) that etymological origin of “complex” means braided—as in many parts woven together.

Now I think about simplicity and complexity as a sliding scale of the number of moving parts. The higher the number of moving parts, the more time you spend on glue code coordinating the system.

Really, I think RoR or Laravel are some of the best options today for IndieHackers. Almost all JS development gets complex fast and hard to maintain as a solo-dev.

If you're willing, I'd be super curious to hear from @jakeprins who has recently done a lot with serverless...

Nice write-up. I'm a big fan of both server less and RoR. In fact, my last job was a RoR project, but we had a few components that were in Lambda.

I know if I was starting a fresh side-project I'd probably pick RoR for the reasons you did. Having strong opinions can save you a lot of decision fatigue which is exhausting when you are just trying to launch a product.

Rails just solves so many initial problems. Being and "indie" anything makes Rails a great choice since you can worry more about the product rather than the tech. It's fun to play with the latest and greatest but at the end of the day we're after some means of financial gain. I think Rails is a perfect supplement for that goal.

I'm not saying serverless is good/bad/right/wrong. But just to pick up on some of the points from the article...

Some of those complaints are perhaps just a lack of practical knowledge of AWS. Some of the questions equally apply to a RoR-built application.

Q: How would system recover?
A: You have to build it to be robust in face of failure. But you should do that in a RoR application too.

Q: Can I rollback and try again?
A: Maybe. Depends on how you build it. (Same answer with RoR)

Q: Where do the logs go?
A: AWS CloudWatch

Complaint: Hard to follow information flow
Rebuttal: Is the flow any different to the RoR version? Or do you mean "it's all in the monolith so it's easy" (but then couldn't you equally say "it's all in AWS")

Complaint: Impossible to replicate production environment locally
Rebuttal: Impossible is a bit of a strong word. For the compute side of things (Lambda) there's AWS SAM. For DynamoDB there's DynamoDBLocal. For S3 there's serverless-s3-local. More generally for a 'local AWS' there's LocalStack.

Complaint: Slow iteration speed
Rebuttal: In my own serverless app I make a code change, it detects the change, 'recompiles' and I have a new working endpoint available locally - this often happens faster than I can even alt-tab to my browser to try it out.

Complaint: Lack of end-to-end testing
Why?

Complaint: Immature documentation
Rebuttal: It's all relative. Compared to RoR you may have a point.

Complaint: No conventions
Rebuttal: There are some. TBH not sure what kind of conventions you mean or want.

While Serverless is relatively new and still has it's problems it makes some things easier and cheaper. You can build small sites and systems using S3, Lambda and Dynamo that are super robust/highly available and cost $0. My startup (cloud based video editing) would not exist without Serverless, sure you could build it with Kubernetes or Docker but you'd go broke pretty fast. Any non-scaling architecture just would not work. It depends what you are building I guess, but once you embrace the mindset shift to Serverless it is hard to go back.

Really good article.
I’m currently developing a side project with Firebase.
Serverless is awesome and ugly at the same time.
I had to extract a microservice into Cloud Run for some specific reasons, I choose NestJS.
A well-architectures nodejs framework

This a great writeup and one that could save a lot of indies a lot of pain.