kylef
commented
4 years ago That makes sense to me, I have no problems with that. I'm also happy to point people to a community buildpack instead of this solution.
To be honest, I am not sure I'd use this approach if I were to operate a serious Swift web application on Heroku. While it may have been an easy way to run Swift on the server in the past, today I would use Heroku's container based deploys with the official Swift docker images (now that they are available in the Swift project). I think that gives a lot more flexibility and reproducibility of the builds and environment. It's also less coupled to the individual provider so if you need to move it is less of a jump.
As an example of how it works, you can see another project I've worked on. Although it is a different language, the approach is the same:
- https://github.com/apiaryio/polls-api#deploying
- https://github.com/apiaryio/polls-api/blob/master/Dockerfile
We don't operate the example service in Heroku anymore (had to move that out), although the image works on Heroku.
Hi Kyle,
Thanks so much for a lot of the early support and work on this.. at one point this project was forked to support vapor specific considerations here: @vapor-community/heroku-buildpack/
since then, some of those considerations (things like ssl or other linking) aren't necessary and the community buildpack supports swift more generally, has a few maintainers, and satisfies a lot of the sswg qualifications
We are in the process of putting together some projects that are more broad to swift, you can read more about mission etc. here: https://swift.org/server/
Anyways, we are looking to propose the vapor-community buildpack, it satisfies a lot of the requirements and is well maintained.
I wanted to see if you had intentions to maintain this library or would like to be a part of the process, or would feel somehow slighted that we might submit a fork to the work group and want to work out a better solution for things.
Thanks again
Logan