Hacking SaaS #2
The SaaS Basics Edition - Authentication, Authorization and APIs
We are all building SaaS and all SaaS is multi-tenant. Therefore, you should learn how to ship multi-tenant SaaS using Postgres Row-Level Security.
From previous experience, we’re familiar with multiple multi-tenant SaaS architecture options. We decided to store everything in a single Postgres schema since it provides a balance of scalability, cost optimization, and flexibility. However, this requires serious investment in database authorization to guarantee that we never leak customer data… We needed a solution that would allow us to add features quickly and confidently
The first SaaS feature anyone writes is signup and login. This can get a bit overwhelming - lots of options, terminology and standards are involved. But the two protocols every SaaS ends up using are OAuth2 and OpenID Connect. And I found the ultimate explainer blog with everything you need to know about OAuth2 and OpenID Connect protocols.
OAuth 2.0 is designed only for authorization, for granting access to data and features from one application to another. OpenID Connect (OIDC) is a thin layer that sits on top of OAuth 2.0 that adds login and profile information about the person who is logged in.
If you are still confused, don’t worry. You are not the only engineer who finds authentication challenging - even the best in the business have bugs: AWS posted an advisory regarding an authentication bug in IAM and EKS.
Workday published a blog post about their observability architecture. It is a standard pipeline that every SaaS company builds, with some variation on the exact technologies used for each service. Worth reading if you don’t have observability built yet and are interested in a boring tried and true observability architecture.
observability is emerging as a key capability of modern distributed systems that uses telemetry data collected during the runtime for debugging and maintaining complex distributed applications to ensure their quality of service.
Oldie-but-goodie review of lessons in designing software libraries. It is a good reminder of annoying facts, such as “people will not read the docs” and “it should just work”. Writing a library that just works for someone who copy-pasted some example code and didn’t read the docs is hard - which explains why very few libraries meet this standard.
Docs are almost useless. Nobody reads them. They'll read a one page quick start, and then they want to just start digging in writing code. Keep the intros very minimal and very focused on getting things working.
Also be aware that if you feel you need to write a lot of docs about something, that's a sign that maybe things are too complicated.
API’s that “just work” can be very high stakes. Read this amazing thread about a small API change that lead to free food in India. We discussed this story in the SaaS Developer Slack, where the another payment processor offered his perspective.
Clickhouse published a controversial benchmark, and the SaaS Developer Slack (join us!) discussed the methodology and results and shared a good video about benchmarks:
New SaaS Community Videos:
Thats it for this week! You can join the conversation on the SaaS Developer Slack or subscribe to this newsletter.