Combine frontend and backend applications

[benlangfeld]

The current state of Flaredown is that the backend API server (a Rails application) and frontend browser application (Ember) are distinct applications stored in a single git repository. The mobile (iOS and Android) applications are simple wrappers around a web view of the browser application.

The frontend and backend applications are deployed as distinct Heroku applications in both staging and production. Heroku review apps are not enabled, and QA of the content of pull requests relies on test coverage, testing in a local development environment or a post-merge test in the staging environment, rather than simple pre-merge testing in ephemeral review environments.

There are several downsides to this:

• The obvious additional difficulty in pre-merge QA of changes.
• Higher cognitive overhead juggling multiple deployments.
• Frontend and backend deployments to staging and production are uncoordinated.
• Local development relies on several layers of forking to spin up everything required to test the application locally.

I have been unable to identify any benefits to this robust separation of the distinct applications. I had read somewhere that there was interest in splitting these applications into multiple repositories, but this appears to only make the identified difficulties worse, and not better. The backend and frontend elements of Flaredown are conceptually inseparable.

I propose that instead we combine these applications using https://github.com/thoughtbot/ember-cli-rails, serving the Ember front-end from the Rails backend application, and collapsing down to a single deployed application. This will additionally unblock the use of review applications and reduce the complexity of the local development tooling.

See also:

• https://github.com/rubyforgood/Flaredown/pull/474
• https://github.com/rubyforgood/Flaredown/pull/430#issuecomment-904351074

[lucasfeijo]

Agreed with keeping the single repo.

[compwron]

from slack

that is a correct description of current state. I don't see why this would cause problems for testing in CI though but on a technical level if you want to split the repos that is fine, I don't foresee problems with the prod deploy change.

Frontend and backend deployments to staging and production are uncoordinated. this was useful previously as we deployed frontend upgrades without different delicate backend upgrades for easier smaller debugging, but we don't need it anymore because we are back up tot date

https://github.com/thoughtbot/ember-cli-rails looks like an mediocre mid-tier solution last updated in Aug 2020 more than a year ago. What are the chances that it will never be maintained again and leave us stranded?

to summarize - yep go for it :)

[benlangfeld]

I don't see why this would cause problems for testing in CI though but on a technical level if you want to split the repos that is fine, I don't foresee problems with the prod deploy change.

I really don't want to split the repos. I want to do precisely the opposite, eliminate the current harmful and useless separation between backend and frontend and produce a single deployable artefact which serves the full application.

https://github.com/thoughtbot/ember-cli-rails looks like an mediocre mid-tier solution last updated in Aug 2020 more than a year ago. What are the chances that it will never be maintained again and leave us stranded?

I'm not sure I follow. Why mediocre and mid-tier?

As for maintenance, I can't guarantee anything. When working on Kubernetes I would typically serve the static frontend content from a distinct Deployment, combining both at the Ingress tier, but modelling the whole combination with a unified deployment pipeline. Heroku doesn't allow building multiple slugs for a single application, or any control over path-based routing, nor do they much like multiple processes in a single dyno, so having Rails serve static assets and fronting that with a CDN if necessary seems like the best way forward given all the restrictions imposed by Heroku.

[benlangfeld]

Heroku's advice (distilled here) is to use a heroku-postbuild script in package.json (invoked by the nodejs buildpack) to compile the frontend application and copy its assets to Rails' public/ directory to be served by Rails, and http-proxy-middleware in local development to invert the way in which things are served. That rather unfortunately reduces environmental parity.

[compwron]

This is done