Want to build your next SaaS in Go, I'm writing a book on that

Show Bootstrapped
#1

Hi everyone,

I thought some here might be interested in a book I’m currently writing - Build a SaaS app in Go.

The two last startups I built uses Go as back end Roadmap and LeadFuze.

There’s some pretty compelling reasons to consider Go for a startup:

  1. Tiny memory usage, so your servers can run your app on the smallest configuration. DigitalOcean’s starting $5/m droplet for example are more than enough for medium-high traffic apps in Go.
  2. Simple deployment via a one file binary. No more scp’ing code to your production servers.
  3. Highly performant and new comer are productive in less than a week.
  4. Safe to refactor and change core part of your application. Great for micro-services.

Note: I’m not saying or implying that Go is better or the only solution. I’m writing this to present alternative to other things. Learning new language is energizing and increase overall programming skills.

In any case, I’ve built and run SaaS for the last 10 years and it is hard (for me at least). I wanted to publish a book. SaaS and Go are two things I’m passionate about. Hopefully that picked your curiosity a little.

Any feedback always appreciated :slight_smile:

1 Like
#2

Oh good, this is totally for me. I signed up for your email CTA thingy.

Right now I’m building a SaaS in Go & Python. The ‘S’ part in Go, and the ‘aaS’ part in Python. I’m using Go because I need the speed and lower memory footprint, but Django for everything other than the actual core app because that’s my traditional stack and I want:

  • user accounts
  • session management
  • admin interface
  • receive email for internal errors
  • banning too many failed access attempts
  • the convenience of Django Rest Framework including complex logic in serialization, throttling…
  • cron-invokable periodic management commands
  • url routing system that doesn’t resemble a laundry list
  • the readability and concision of ORMs (because 99% of my queries don’t require raw SQL)
  • database schema migrations

… in the context of something a little more substantial than hello world. Go’s docs and tutorials are not as good or complete as python, and I suspect the target audience are more knowledgeable, better programmers who can figure these things out quickly, leaving people like me to rely on opinionated frameworks where you’re told “here’s the right way to do X”.

So yeah, it would be great if you could cover the Golang alternatives to all those points :smiley:

I haven’t actually pre-ordered though because in your list of chapters you haven’t completed any of the content that I actually want to read. BTW your code on p28 exceeds the page width. Also, I’d question the wisdom of working first on the content I assume is in Ch1-3, as there are already plenty of online resources for those subjects (which, as someone trying to use Go, I’ve already read). I’m not trying to buy a complete textbook “as an engineer”, but rather a recipe/roadmap to enjoying all the benefits of Go and knowing how to do all the essential business stuff I listed above “as a business owner who happens to write the code too”.

2 Likes
#3

I have bought the ‘pre-order’ book and just got the latest chapter. not read it yet but 1 to 3 validate stuff that I’ve learned online and also open my eyes a bit to a different way of looking at things.

Only just getting into Golang as the backend for my new product (WebsiteWatchdog.io) and I’m looking to Dominic’s book to fill in the gaps for a production-ready API that most online tutorials don’t have.

IMHO if you’re fairly new to Golang and want to peek behind the curtain of what it takes to put something in to production then you can’t go wrong shelling out the few $ on the pre-order

1 Like
#4

Thanks for the reply. I understand your points. Most of the points you listed will be addressed minus:

  • admin interface -> the book scope is regarding API and related backend stuff, no UI, no frontend. I’m thinking of writing a book on Elm next year (maybe).

  • the convenience of Django Rest Framework including complex logic in serialization, throttling… => I haven’t used Django, I cannot compare, but the tiny engine we build on chapter 2 (no dependencies, no opinionated framework, a simple 100 lines router, read JSON, write JSON and decoupled architecture feels really good (to me at least). Throttling will be addressed in chapter 7

  • cron-invokable periodic management commands => In chapter 9: Email and background tasks, we build a package similar to Ruby’s sidekiq, but not as comprehensive of course, so cron-less.

  • the readability and concision of ORMs (because 99% of my queries don’t require raw SQL) => Chapter 4 that I just released two days ago demonstrate how to handle PostgreSQL and MongoDB from one data package. From there your SQL package can use an ORM like gorm it’s up to you. I’m trying to not enforce choices in my book. Those choices should come from your experiences and what you want to use. The end result API should be agnostic enough of those choices and reader that implement their web app should not have difficulty to add those on top of what the book is building.

  • same for data migration, it’s out of scope of the book and is a choice you make for yourself.

I understand and also would love to have those chapters written yet, but it is 4x harder than what I thought to write a book. I did lots of screencasts (mostly in French) from 2014-2016 and that was easier even with 2 hours editing. I’m writing it as fast as I can and prefer to make sure the content will survive and is interesting.

The choice of working 1-3 first was required. The web engine we built in chapter 2 is different than what I thought was going to be the web server in the preview chapter 8: Billing when I launched this preview chapter in December. I’ll need to rewrite a good portion of the chapter sadly.

That being said, I like the comment and I’ll keep that in mind.

Thank you for the feedback, this is highly appreciated.

#5

Thanks Dean for the comment :slight_smile: - One thing I could do is let pre-order buyers vote for which chapter they would want next. That’s a crazy idea but that’s what my SaaS Roadmap is built for, so maybe I’ll try this :slight_smile:

#6

Hi Dominic, I’m not bothered about that, I want the book chapter by chapter.

I think because this isn’t a golang reference book it’ll be hard to do later chapters ahead of the earlier ones as each chapter builds on the code from before as you’ve found with chapter 8.

I’d just keep going until it’s written then you can focus 100% on the marketing