Skip to content
This repository has been archived by the owner on Nov 4, 2021. It is now read-only.

New package name proposal: @posthog/processor #86

Closed
Twixes opened this issue Jan 4, 2021 · 4 comments · Fixed by #93
Closed

New package name proposal: @posthog/processor #86

Twixes opened this issue Jan 4, 2021 · 4 comments · Fixed by #93
Labels
question Further information is requested

Comments

@Twixes
Copy link
Member

Twixes commented Jan 4, 2021

This project started out as a worker to only process events received from the main PostHog server with plugins, and then pass them back to the main server, but it's now growing into a much more robust server with greater responsibility in the ingestion pipeline and beyond (possibly processing HTTP requests with Fastify).

Therefore the original name now seems to be somewhat narrow and boring. I suggest we rename the package. My proposal is: @posthog/processor – cool, short, and describing what all this does: data processing central to PostHog, from and into.

Feedback needed and welcome.

@Twixes Twixes added the question Further information is requested label Jan 4, 2021
@mariusandra
Copy link
Collaborator

I brought up this same question right before we decided to implement event ingestion and the conclusion then was :thisisfine:. The argument was that ingestion will (eventually) be just another plugin, and as of such the name is fitting.

While we won't give all plugins access to server.db and other dangerous tools that ingestion will use, we can basically still treat it as just the last step in the plugin/processing pipeline.

Regarding processor, it is a clever choice that does describe what the server does and I'm not against it per se. That said, renaming this now will cause several unintended side-effects. For consistency we'll have to rename the pluginworker heroku dyno and the plugins helm chart worker into processor* as well (plus all the other AWS-related places), which will be a breaking change for users that are not expecting this. It could result in some downtime. Personally I'd also still like to see "server" in the name somehow, to reflect the "it must be deployed and stay running" nature of the project.

All in all, I'm sort of "meh" on this point. I have nothing against renaming posthog- to @posthog/ though, as this changes nothing downstream for users.

@mariusandra
Copy link
Collaborator

So, conclusion from the meeting: @posthog/plugin-server

@Twixes
Copy link
Member Author

Twixes commented Jan 12, 2021

One thing I'm unsure about is, why is does @posthog/plugin-server change less than @posthog/anything-else? At least that's how I understood the last paragraph of #86 (comment).

@mariusandra
Copy link
Collaborator

It's because nobody is really installing posthog-plugin-server from npm, but either running it as part of the main posthog repo or just via docker. In that case the only thing we need to change is this line.

When changing the name from "*plugin*" to something else like /processor, we should also change the name of the dynos, the helm deployments, etc in order to avoid a team <-> project situation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants