Saasify Developer Experience (DX)
πŸ‘©β€πŸ’»

Saasify Developer Experience (DX)

Β 

Overview

Saasify's maker DX will likely be the most important limiting factor in determining our adoption and traction as a platform.
Β 
Our current DX is great for quickly building internal products and showcasing the power of the platform's abstractions, but there are a lot of issues for external developers. Some of these issue are due to poor docs and the difficulty of getting started with the CLI-based workflow, but some of these issues will require re-thinking the DX more holistically.
Β 
The ideal DX workflow needs to be dead simple to start onboarding, quick to get to your product's personalized "AHA" moment, and frictionless as you continue iterating on your product.
Β 
  • This thought process applies to both frontend and backend DX.
  • Production concerns such as analytics, custom domains, customer management, etc are all significantly less important in terms of prioritization than the early DX at the top of the funnel.
  • We want developers to think of Saasify as the Ultimate SaaS Boilerplate.
  • Saasify needs to help you feel empowered every step along the way with what you're able to accomplish β€” we must absolutely avoid scenarios where devs feel encumbered by Saasify.
Β 
Saasify's core value proposition is to allow you to focus on your product's core value proposition and in order to do so, the DX has to feel very natural. You should be able to develop your product without ever worrying about user accounts, subscription billing, usage tracking, analytics, or most other production concerns. And the DX needs to feel as frictionless as possible along the way.
Β 
Β 

Β 

Saasify's 0:1 Core Value Proposition

  • Ability to build your product without worrying about auth, subscriptions, or production concerns
  • JSON-based Stripe billing
  • JSON-based third-party OAuth integrations
  • 95% of production concerns handled for you
    • Security
    • Performance
    • Analytics
    • Monitoring
    • CRM
    • etc
Β 

Saasify's 1:N Core Value Proposition

  • (in the future) for successful products that grow past saasify's initial go-to-market momentum
  • Fuel growth with a built-in referral model via Saasify's marketing & sales team
    • Saasify takes a 20% cut of revenue only for customers we bring in
  • Saasify will offer additional product add-ons focused on growth (tbd)
  • Easy third-party integrations & add-ons marketplace
Β 
Β 

Β 

Frontend Use Cases

  • Default SaaS webapp - "API only"
    • Maker can customize the default SaaS webapp, choose theme, etc
  • Embedded webapp - "API-First"?
    • Maker can embed a standalone webapp in the default SaaS webapp's auth'ed dashboard
    • This is how I built twitter-search.io and simplecron.dev
    • The DX and iframe constraints are less than ideal
    • TODO: Do we actually want to support this use case? Or would just focusing on the ejected "Custom" use case be simpler and more natural?
  • Ejected webapp - "Custom"
    • Maker can completely customize the default SaaS webapp
    • Will initially be a cleaned up version of our React app
    • In the future, we'll support default webapps for all the popular frameworks
  • Embedded blocks - "External"
    • Maker can embed Saasify blocks on any external webapp
    • Allows full customizability and integration with existing webapps
Β 

Backend Use Cases

  • Externally hosted
  • Serverless hosted by Saasify
  • Serverful hosted by Saasify - in the future
Β 

Backend Characteristics

  • OpenAPI vs no OpenAPI
  • REST vs GraphQL
Β 
Β 

Β 

Current Flow - April 2020

  • saasify init β‡’ local config
  • saasify deploy β‡’ remote webapp
  • saasify publish β‡’ live saas webapp
  • manage admin from maker dashboard
Β 

Pros βœ…

  • allows us to quickly build out full product demos internally
  • works via CLI
  • API and authenticated webapp are nicely encapsulated
  • will work reasonably well with remote maker webapp
  • future-facing interop is enabled via required openapi spec
Β 

Cons ❌

  • SaaS product use cases are very constrained by API-first mentality
  • no ability to test proxied API locally
  • no ability to test and edit saas webapp locally
  • difficult to work on and test embedded webapp
  • conceptually difficult; lots of moving parts for even a basic saas webapp
  • difficult to customize generated saas webapp
  • openapi requirement is confusing and makes it more difficult to get started
Β 
Β 

Β 

Ideal Flow - Future

  • Comprised of 3 options across the maker webapp (GUI), the CLI, and embedding blocks on external sites
Β 

1. Ideal Flow - Future - Maker Webapp

(visual project management from a web wysiwyg editor)
  • create project from maker webapp β‡’ remote saas webapp
  • connect backend API once you're ready
  • connect github repo for auto-updates
  • dev
    • TODO
Β 

2. Ideal Flow - Future - CLI

(improved version of the current CLI flow)
  • saasify init β‡’ local config
  • saasify dev β‡’ local api and local webapp
    • should support hot reload as you edit your saasify.json
    • we may only need to serve the local webapp which will forward API requests to your local dev server transparently via the saasify JS sdk / service worker
    • in this case, we can't test the local api directly which isn't that big of a concern
    • can always add local backend proxying to saasify dev later
    • { dev: { api: "http://localhost:4000" } }
  • saasify eject
Β 

3. Ideal Flow - Future - Embedded Blocks

(most flexible / extensible flow where you want to embed saasify functionality onto an external site)
  • create project from maker webapp or cli
  • disable auto-generated saas webapp
  • manage project settings from webapp and/or cli
  • saasify powered backend
  • JS embed on the frontend to get currently auth'ed user info
    • will look similar to userbase js sdk
    • should be the same js embed the default maker webapp uses
  • saasify dev β‡’ local backend proxy
    • also run your local backend server
    • also run your local frontend webapp
    • mehh requiring 3 / processes is a lot...
    • could saasify dev be accomplished locally by JS embed performing proxy via service worker?
      • would saasify dev be simpler for MVP of this flow?
Β 
Β 

Β 
Β 
notion image
Β 

Β 

Thoughts

  • Instead of referencing your SaaS API, refer to it as your app's backend?
  • Possibly use service workers to proxy your backend calls automatically via Saasify πŸ€”
    • msw - may be useful for inspiration
  • "soft eject" vs "hard eject"
    • the memes will surely write themselves πŸ˜‚
    • soft eject = ejecting from saasify webapp, still using saasify backend
    • hard eject = ejecting from saasify webapp and backend
  • Once you can edit your project's config from the maker webapp and locally via the CLI & JSON config, we'll need to intelligently sync changes between the two, presenting the user with appropriate feedback when there are conflicting changes
    • The same could be said today for multiple checkouts of your saasify.json config
  • ZEIT now's ability to deploy webapp + lambdas in api/ is perfect for our use case
Β 
Β 

Β 

Next Steps

  • Discuss this doc with a few peeps
  • Consider dropping OpenAPI requirement (done βœ…)
  • Support ejecting from SaaS webapp
    • Will require lots of refactoring and cleanup
  • Experiment with backend proxying via service worker
    • on prod, these calls target ssfy.sh
    • on dev, these calls target your normal localhost backend
  • Design Saasify JS SDK
    • saasify-client-sdk
      • on prod, deployment is loaded async?
      • on dev, deployment is loaded locally from saasify.json
      • handles auth
    • saasify-server-sdk (currently saasify-provider-sdk)
Β 
Β 

Feedback

AVOID magic
πŸ’―TODO: investigate similar services / flows and how they handle the DX πŸ’―
Β