puma-dev is the golden path for developing multiple Rails applications locally, if you’re not using Docker. Let’s suggest how to get that setup for apps with bin/setup.
Since I do develop multiple Rails apps locally without Docker, this phrase catched my interest. However, I’ve never heard of puma-dev before. So I opened puma-dev’s README.
There, it says:
a tool to manage rack apps
the successor of pow
easy startup and idle shutdown of rack/rails apps
supports Rails 5 actioncable
and some claims about custom domains (.test etc.)
Unfortunately, this still gives me no idea what’s the puma-dev use case.
“a tool to manage rack apps”: What does it mean to “manage a rack app”?
“the successor of pow” - since I’ve never used pow neither, I don’t know what that means. “easy startup”: I just start a rails app by rails server, what would be easier? “supports Rails 5 actioncable”: I’ve never used ActionCable, but I’ve always assumed the built in puma server would support ActionCable too?
“custom domains (.test etc.)”: For this point, I can see there’s something plain puma cannot provide. I always start multiple Rails apps locallly under localhost using different ports.
Could anybody give me a brief idea what problem puma-dev solves?
I normally run apps on localhost like you, but use puma-dev when something requires https (commonly OAuth / SSO services).
I prefer not to have puma-dev run the server process itself (how can you access binding.break in that case? honest question) but puma-dev allows you to route traffic through a manually started process (via app_root/.env config).
I used Pow a few times back in the Rails 2.3 era, not because I was having difficulty running more than one app, but because at the time I was freelancing for up to a dozen different long-term clients, and the context switching was a noticeable drag. Being able to run client1.dev and client3.dev at the same time, in two tabs of the same browser was a fun party trick. I have not looked at this particular execution in any depth, but this may be useful in the same way. As Dan mentioned, if you are working on a SSO type thing, where you need to federate between several apps during click-testing, that might be another reason to do this. It’s very much (in my mind) like turning Kubernetes inside-out, rather than running multiple containers, you’re running multiple apps and the app server is orchestrating them and managing hostname resolution.
We use puma-dev as our application supports multiple sites with differing subdomains. So we have customer1.example.test, customer2.example.test etc. Puma-dev allows us to use https with multiple subdomains locally and proxies all requests to the app server running on a specific port.
Although DHH mentions running without docker, we use it for both dockerized services and locally running services. We just add the localhost port to a file in ~/.puma-dev/example and then *.example.test will be routed to the port on localhost specified in the file.
That’s exactly how. By using domains instead of http://localhost:3000 for all apps you can easily run them simultaneously as app1.test and app2.test - though I haven’t used puma-dev myself so I can’t speak to downsides like being unable to attach a debugger.