feat: product folders

[mariusandra]

Problem

Read the internal RFC.

PostHog is growing. We've doubled our engineering headcount in a year, and will soon double it again and again. This means soon hundreds of hands will be adding to the PostHog/posthog codebase every day. If you think CI is slow/flakey now, imagine it in a year.

Team DevEx was formed to proactively get ahead of problems with developer velocity. Our goal is to clean up the common layer between projects and products, including code, communication and UI, so that you could focus on your task at hand. We want to make it easier to build the next 50 products, than it was to build the last 10.

Changes

products/ folder

Here's the first PR in a bunch to come that splits products into their own folders/apps, starting with messaging (unreleased product), easy access features (small and lowish risk) and LLM observability (new product). The new/moved files in this PR are:

products
   llm_observability
      __init__.py
      manifest.json
      frontend
         urls.ts
         LLMObservabilityScene.tsx
         llmObservabilityLogic.tsx
         llmObservabilityLogicType.ts
   early_access_features
      __init__.py
      manifest.json
      migrations
         __init__.py
         max_migration.txt
         0001_initial_migration.py
         0002_alter_earlyaccessfeature_options_and_more.py
      backend
         models.py
         test
            test_early_access_feature.py
         api.py
      frontend
         urls.ts
         InstructionsModal.tsx
         earlyAccessFeaturesLogic.ts
         earlyAccessFeatureLogicType.ts
         earlyAccessFeaturesLogicType.ts
         EarlyAccessFeature.tsx
         EarlyAccessFeatures.stories.tsx
         EarlyAccessFeatures.tsx
         earlyAccessFeatureLogic.ts
   messaging
      __init__.py
      manifest.json
      backend # empty
      frontend
         urls.ts
         providersLogicType.ts
         broadcastsLogic.tsx
         Broadcasts.tsx
         functionsTableLogicType.ts
         messagingTabsLogic.ts
         functionsTableLogic.tsx
         FunctionsTable.tsx
         messagingTabsLogicType.ts
         MessagingTabs.tsx
         providersLogic.ts
         broadcastsLogicType.ts
         Providers.tsx

Product manifests + codegen

Each product has a manifest.json (will be manifest.ts for better typing in the future), which provides all django and esbuild need to assemble the whole hog. This is done via code generation for the frontend, including some TypeScript AST merging to make a combined urls object. The python/backend parts require manual wiring and don't yet come with a codegen.

Backend apps

We want to move backend/django code into product folders as well. Django supports multiple apps, however migrations are tricky. Check the code for an example. We need to delete the model's metadata in the main app, and recreate it in the product. It's a bit of work we'll have to do once per product. I think it's worth it.

Dependency graph

This PR adds a tool called toch which maps dependencies between django apps. We can use it to help us untangle apps in the future. Its output will be merged with the graph generated by nx once we get that up and running (one will generate the other).

TODO, outside this PR, but sooner rather than later

• Kea typegen adds "..", ".." in front of the path. Remove "frontend" from within the path as well.
• Support gathering imported typescript types in urls.ts files
• Do we want to add some global product enum? Product scene enums now changed to strings which is a bit of a downgrade.
• manifest.json to manifest.ts for better autocomplete support

To investigate later

• Move backend routing into product folders + codegen
• Other places in django we should inject into?
• Common home for hogql_queries
• Shorter frontend imports than products/early_access_features/frontend/earlyAccessFeatureLogic
• Everything else in this big list

How did you test this code?

Works on my machine

[timgl]

I’m on the fence on having each product be a separate django app (see this article. Basically Django doesn’t guarantee execution order of migrations I think so it potentially could be a bit of a nightmare. However, not having different product have merge conflicts when doing migrations is definitely a + for productivity so maybe it is worth it

[mariusandra]

In the article they mention fixing it with a homegrown migration manifest: https://gist.github.com/084ef47c4f68922c587bf1252e2d6d89

What I'd do is to have a text file with the order in which migrations are run, globally for all apps. If there's a merge conflict, you just make sure all migrations are in a logical order in this file, and that's that.

[daibhin]

From what you showed me of this on Friday this seems to cover all the toil creating various scenes on the frontend for a new product. That certainly took some time for Error Tracking so maybe a scaffold would be nice but it was also a one time cost so not the most painful.

I wonder if similarly there is something we could do when creating a new service. Hooking it up to Argo for auto deploys, some basic charts / metrics / alert configurations. We didn't or still don't have a lot of that setup.

Taking that idea even further - there was a bunch of stuff involved in setting up a new product team that right now just gets added to the handbook (maybe). I'm thinking updating the website & roadmap, team Slack channels (and user group), Support inboxes & SLA alerts, standups, adding an in-app support option. It's probably not worth the investment but feels quite cookie cutter when creating a new team. Perhaps it can begin life as a Github issue template like we have for onboarding new hires.

[timgl]

@daibhin on your last point, we have a template issue for ops to deal with creating a new team: https://github.com/PostHog/company-internal/issues/new/choose

[posthog-bot]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.

[posthog-bot]

This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.

[posthog-bot]

📸 UI snapshots have been updated

1 snapshot changes in total. 0 added, 1 modified, 0 deleted:

• chromium: 0 added, 1 modified, 0 deleted (diff for shard 1)
• webkit: 0 added, 0 modified, 0 deleted

Triggered by this commit.

👉 Review this PR's diff of snapshots.