Start using app.json for Fourchette instead of forking?

[jipiboily]

I think it would make more sense (at least to us) not to fork an app but instead use app.json to create a new app, and seed our database ourselves.

I am not sure how many people rely on Fourchette and the fact that it is forking apps vs the number of people who would be fine using app.json?

Yes, we could support both, maybe it's not worth it though.

Thoughts?

/cc @smathieu @ukd1 @markpundsack @friism @bdarfler

[bdarfler]

As long as generating an app.json is trivial I'm fine either way. The benefit of forking in my mind is that its super easy to get started since you probably already have a staging/demo app that you can fork. At least we did. I would hate to have creating an app.json file as a barrier to entry.

[friism]

I'm +1 on this!

Internally at Heroku, we're not happy with the fork implementation, and looking to supplant it with exactly what you're proposing here.

[ukd1]

Hmmm I think we should support both, or not bother. Whilst app.json is good, it adds another barrier to entry like @bdarfler mentioned.

[jipiboily]

@bdarfler & @ukd1: good point.

I think we should support both unless it's a total mess, but it shouldn't be TOO bad actually.

@friism: did you/someone start working on this? Anyone who would be willing to implement this or part of this in Fourchette? What's your plan?

[ukd1]

@friism any way of making there be no barrier to entry to generate one? If you remember heroku.json had a describe mode, where it would generate the file for you - is that possible via api for an existing app on Heroku with app.json?

[jipiboily]

Free idea for you @friism: an "app to app.json" app? :)

[friism]

@ukd1 If you don't want, you can use an empty app.json in the repo (we're contemplating allowing not having an app.json file in the repo). You can call the app setup API directly, overriding any ENV you need in the new app: https://devcenter.heroku.com/articles/setting-up-apps-using-the-heroku-platform-api

There are various efforts at app.json and button makers, but really, the files a so simple. Here are some resources:

• https://www.expeditedssl.com/heroku-button-maker
• https://github.com/app-json/app.json#creating-a-manifest

I'm very interested in your feedback on this, please keep it coming!

[ukd1]

@friism imho this isn't seamless enough compared to fork to replace it for this usecase (i.e. where the target app is unknown until you find fourchette).

app.json is great for things like this project, where set up of the app is difficult for a beginner - as the maintainers can write the initial file.

I'd like an API you could call which returns a app.json file.

[jipiboily]

Agree with @ukd1, having an API to create an app.json from a running app would be awesome. That said, it might be useful to have a place in the app settings to get it? So it would be an easy step to setup Fourchette.

The idea I think is to keep it as simple as possible for new users (to Heroku and/or Fourchette) but also flexible for more advanced users/those who have a more complex use case.

The app-setup looks interesting. I am wondering how we/if could leverage that for even easier "Getting Started with Fourchette". I would see a deploy button getting you through all the basic steps on Heroku (creating account if required, new Fourchette app, etc), then with a callback/redirect or something to get to a setup workflow, maybe using Heroku's oAuth to be able to configure Fourchette, using a web UI on Fourchette itself? This is obviously not clear in my head right now, just throwing ideas...

[markpundsack]

FWIW, I'd prefer to keep using fork for our use case. For the main app I use it for, we can't use app.json for a variety of reasons, so we'd only be creating and maintaining it for the purpose of fourchette. That and we don't sufficiently seed the database to be useful. So ultimately, it's just a lot easier to fork from a known-good dev app and update the dev app as needed and automatically get those changes.

[jipiboily]

@markpundsack that's interesting. Two different use case @ Heroku then?

So I guess that supporting both is just making more and more sense...

[friism]

@jipiboily It'd be great if you guys could add a Heroku Button to your README, should make setting up fourchette way easier.

[jipiboily]

@friism there's actually an issue for this with a list of what is required, it just needs to be done: https://github.com/rainforestapp/fourchette/issues/35 :)

[jipiboily]

I am contemplating this again as the database transfer is failing in most cases and it's been the case for a little while now...anyone having issues with the database transfer not working consistently?

[friism]

Hey @jipiboily, the Heroku Postgres team is working on some new copy features that should make this more fun. The CLI functionality is documented here: https://devcenter.heroku.com/articles/heroku-postgres-backups#direct-database-to-database-copies

You can probably reverse engineer the APIs used for this: https://github.com/heroku/heroku-pg-extras/blob/master/lib/heroku/command/pg_backups.rb#L7

[friism]

Oh, I guess you already noticed: https://github.com/rainforestapp/fourchette/issues/42

[jipiboily]

Yeah, I tried this, it's also unreliable sadly...I have ticket already opened for that. I've put all my efforts on hold for today.

[jipiboily]

Well, it's unreliable, in my case, I guess it probably works for most people :)

[seanknox]

I vote for app.json. The main drawback against forky/forking is that it's unable to accommodate any type of post-deploy operation. Example:

1. Developer pushes up feature branch with migrations.
2. forky forks a Heroku app (say, some app running master) to create the new acceptance/testing app
3. A new slug is built using the feature branch tarball. At some point it finishes, but there's no callback to know when.
4. Without a callback or synchronous build process, there's no way to run post-deploy tasks like rake db:migrate.

[jipiboily]

@seanknox there is a hacky way to do that though, you can watch for the build and as long as it's not done, sleep X seconds and try again. This is hacky, but this is what I did...it's awful, but here it is: https://github.com/rainforestapp/rf-ourchette/blob/master/lib/fourchette/callbacks.rb#L80

[jipiboily]

FYI, we just decided to deprecate Fourchette. You can (and probably should) use the Heroku review apps instead which was inspired by Fourchette.

https://devcenter.heroku.com/articles/github-integration-review-apps

Thanks!

[seanknox]

:crying_cat_face: @jipiboily We did the same thing with our project that was inspired by Fourchette. Thanks for providing this in the first place, it's been an incredible help!

[friism]

Thanks also from Heroku!

Fourchette showed us what could be done and was a great inspiration. Michael

[ukd1]

@friism @seanknox <3

[jipiboily]

Much :heart: @friism & @seanknox. Was a fun ride :grinning: