Hacker News Reader

You should solve this by making one request to a db api layer (use GraphQL!) And have that layer do the back and forth with the db, from right next to it.

Holding transactions open for long distance round trips is going to get you into trouble in a myriad of ways. It does not scale.

View on HN

This is exactly what we do! We have a Rails app exposing a graphql api for our cli and web app. The web app is a React SPA monster that we're replacing with another Rails app that runs at the edge and serves the customer UI, docs, marketing pages, and some other things. It's really pleasant. We love graphql.

Why not just have the rails app exposing GQL also expose the customer UI/etc?

Mostly because the path to here was not a straight one :)

Our main Rails app does a bunch of things that can't run globally and it takes a long time to build while the customer facing app is a lightweight Rails app that consolidated several static and single page react apps into one less gross place.

That's actually the plan! The Ruby Graphql gem lets you resolve queries directly so the app can have an "edge" or "core" mode and make the right call (edge over HTTP, core direct to DB).

Reply on news.ycombinator.com