diff --git a/www/_blog/2021-11-30-supabase-studio.mdx b/www/_blog/2021-11-30-supabase-studio.mdx index 3f1fa4744be..1a45ebe70cd 100644 --- a/www/_blog/2021-11-30-supabase-studio.mdx +++ b/www/_blog/2021-11-30-supabase-studio.mdx @@ -21,12 +21,12 @@ and [Self-Hosting](https://supabase.com/docs/guides/hosting/overview). ## Background -Let's get the obvious question out of the way first - why wasn't it already open source? +Let's get the obvious question out of the way - why wasn't it already open source? -When Ant and I started Supabase the code-base was one large monorepo which contained everything from the dashboard to cloud infrastructure code to experimental code. -This is our our preferred strategy - we like to keep all code in one place so that we have a single source of truth and tightly coupled CI workflows. +When Ant and I started Supabase the codebase was one large monorepo which contained everything from the dashboard to cloud infrastructure code to experimental code. +This is our our preferred development setup - we like to keep all code in one place so that we have a single source of truth and tightly coupled CI workflows. -The original Dashboard really wasn't much except a couple of button which allowed our Alpha users to start and stop a Supabase project. +The original Dashboard really wasn't much except a couple of button which allowed our Alpha users to start and stop a Supabase project - back then only a PostgreSQL connection string. Then time went on, and we started gaining traction - a lot faster than expected. The nice thing about building for developers is that they are very vocal about the features they want to see next. @@ -38,48 +38,51 @@ But as feature requests kept rolling in it became a Sisyphean task to maintain s After the last Launch Week, we decided to prioritize the Studio. -## Approaches for managing shared code-bases +## Approaches for managing shared codebases -We investigated a few different approaches used in the open source world. There are three popular strategies that we found among OSS projects and some of our YC alum: +We investigated a few different approaches used in the open source world. There are three popular strategies that we found amongst OSS projects and some of our YC alum: - Maintain separate code bases. Pluck changes from one to another. -- Keep two repos in sync using some mixture of git submodules or a tool like `[copycat](https://github.com/atomix/copycat)` -- Use the same code-base, abstracting platform-specific code behind an API and feature flags +- Keep two repos in sync using some mixture of git submodules or a tool like [`copycat`](https://github.com/atomix/copycat) +- Use the same codebase, abstracting platform-specific code behind an API and feature flags. Our frontend team experimented with the first two approaches where they plucked (injected, merged, and wrangled) code for our Platform. Time-to-production become a lot slower, an unacceptable outcome at Supabase. -Eventually we decided to open source all the frontend code, so the code for both the Platform and Self Hosted is completely public, sharing the same code-base. +Eventually we decided to open source all the frontend code, a shared codebase for both the Platform and Self Hosting. -- Special shout out - - Sentry do a fantastic job of [documenting their strategy](https://develop.sentry.dev/sentry-vs-getsentry/) for managing a shared code-base and served as a great model for Supabase. +
+ +Special shout out + +Sentry do a fantastic job of [documenting their strategy](https://develop.sentry.dev/sentry-vs-getsentry/) for managing a shared codebase and served as a great model for Supabase. +
## Build in public -For the past week, the dashboard you've been using on the Platform has been deployed from our [main repository](https://github.com/supabase/supabase), -the one you might also be using for Self-Hosting. +For the past week, the dashboard you've been using on the Platform has been deployed from our [main repository](https://github.com/supabase/supabase/tree/master/studio). -This fits one of our core philosophies at Supabase: do less. Less code to manage means less bugs. Fewer code-bases means faster shipping. +This fits one of our core philosophies at Supabase: do less. Less code to manage means less bugs. Fewer codebases means faster shipping. It also fits the development philosophy of every other part of Supabase: building in public, "warts and all". This is a huge step forward for the community. Supabase users can now spot a bug, fix it in the open source repository, -and have it shipped to both the Platform and Self-Hosted environments - all in a single day. +and have it shipped to both the Platform and Self-Hosted environments - all in a few hours. ## Technical details -Let's jump into some of the technical details. +Let's jump into some of the technical implemetation for Supabase Studio. ### Tech stack -Studio is built Javascript application with a few key pieces. +Studio is a Javascript application with a few key pieces of technology: - [Next.js](https://nextjs.org/) - A frontend Javascript framework built with React. - [Tailwind](https://tailwindcss.com/) - A utility-first CSS framework. - [Supabase UI](https://ui.supabase.io/) - Our own component library. - [MobX](https://www.mobxjs.com/) - A state management library. +- A host of other [useful libraries](https://github.com/supabase/supabase/blob/master/studio/package.json), including [Radix UI](https://www.radix-ui.com), [Lottiefiles](https://lottiefiles.com/), [react-grid-layout](https://github.com/react-grid-layout/react-grid-layout), and [zxcvbn](https://github.com/dropbox/zxcvbn). ### What's included @@ -88,17 +91,13 @@ It is not intended for managing the deployment and administration of projects - The features exposed on Studio for existing deployments are limited to those which manage your database: -- Table & SQL editors - - Saved queries are unavailable -- Database management - - Policies, roles, extensions, replication -- API documentation -- Settings - - Project settings are managed outside of the Dashboard. If you use docker-compose, you should manage the settings in your docker-compose file. If you're deploying Supabase to your own cloud, you should store your secrets and env vars in a vault or secrets manager. +- Table & SQL editors. (Saved queries are unavailable for now) +- Database management: Policies, roles, extensions, replication. +- API documentation. -Over time we'll migrate a lot more of the code-base into the self-hosted Dashboard, this was as much as we could migrate for this Launch Week! +Over time we'll expose a lot more of the codebase in the self-hosted Dashboard, this was as much as we could do for this Launch Week! ## How to contribute? -Check out the full instructions in our [Studio Readme](). +Check out the full instructions in our [Studio Readme](https://github.com/supabase/supabase/tree/master/studio).