[Feature Request] Include service in Homebrew formula

[lorensr]

Is your feature request related to a problem? Please describe.

I have to rerun temporal server start-dev every time the terminal gets closed or I restart my machine. It also takes up a terminal window while it’s running: temporalio/temporalite-archived#139

Describe the solution you'd like

brew services start temporal

https://docs.brew.sh/Formula-Cookbook#service-files

Additional context

https://temporaltechnologies.slack.com/archives/C045W6P0GCB/p1666388357948369?thread_ts=1666379438.289719&cid=C045W6P0GCB

[josh-berry]

I don't think the dev-server is intended to be run continuously as a service—it is ephemeral and loses state on every restart. I'm curious how it would help to have it running continuously? Is it just a convenience thing or is there a more specific reason you want to keep it running all the time?

[lorensr]

I think it's run in persistent mode by some in dev as well as prod hobby or single-machine use cases (I think DD has the latter), so potentially could be useful.

But I was just thinking for convenience during dev, regardless of whether it's in persistent mode or not. I guess it makes sense to give the user the choice of which mode. For default, I guess persistent mode is what users would expect from a brew service? OTOH would expect ephemeral if have been using the CLI. If default persistent, it could be:

brew services start temporal
brew services start temporal-ephemeral

which seems easier than the alternative, a config file (I don't think you can pass arguments?). But I guess config file gives more flexibility, like db file location and other options like dynamic config.

[lorensr]

Alternative for getting your tab back is temporal server start-dev &> /dev/null & disown but is missing functionality that brew services fixes (see discussion in #66).

But sending to background doesn't address my pain point that workflows I run keep failing to start because I haven't manually started the server yet.

[cretz]

I don't think the Temporal dev server should be consider a "service" in the OS sense (whether brew service, Windows service, Linux init.d, etc) at this time because I think it's safer to fail users that chose not to start a server. But if we wanted the ability to have "Temporal dev server" as a service, we definitely should explicitly called it "temporal dev server" and not just "temporal".

[lorensr]

Safer in what sense?

[cretz]

Safer to know that they need to start a dev server w/ whatever configuration they need to do dev things instead of rely on an existing one. But I don't have strong objection so long as 1) we make it clear the service is for a dev server and not just "temporal", and 2) we're don't discriminate platforms by only treating as a service for macOS.

[lorensr]

Not knowing that they need a server for their Temporal code doesn't seem like a large risk to me. Even for the small percentage of new devs who get through learning Temporal without knowing & remembering that, the risk is they try deploying their client & worker for the first time and see server connection errors, and will realize clients & workers need to be able to access a server.

I'm pro docs or integrations for getting it running as a service on other platforms.

For making clear dev server, maybe:

brew services start temporal-dev
brew services start temporal-dev-persistent

(Atm thinking default ephemeral, because when you want to clear your workflows, maybe it's easier to do brew services restart temporal-dev than eg temporal workflow delete --query 'HistoryLength > 0' --yes --reason 'clear')

[cretz]

👍 Probably don't even need a -persistent form, and I am guessing we're not really going to worry about configuration at this time. Works for me, but again, would request it's done for all platforms at the same time.