Open lorensr opened 1 year ago
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?
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.
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.
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".
Safer in what sense?
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.
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'
)
:+1: 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.
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: https://github.com/temporalio/temporalite/issues/139Describe 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