Overview

• 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 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

• 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

• 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

• 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?

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

• kong quick start