one thing i’m curious about — is that uncommon? this might be a wild coincidence but every product i’ve worked on was running against prod data in dev
Reposted from
Eric Clemmons
Running a frontend locally against a prod backend is the 🐐ed DX
Now I want to make the Follow/Following states visually different in dark mode 🖤
Now I want to make the Follow/Following states visually different in dark mode 🖤
Comments
I guess it depends on the complexity of running backend service locally
Slack BE usually develops against dev environment but FEs often use prod.
Since you’ve been working on Social Media apps it makes a lot of sense you’d use prod data.
For other use cases, there is at least an argument for doing it differently.
Sorry, I couldn't resist sharing my experimental tool: https://github.com/kerematam/sahne-js (thanks to Puppeteer and Chrome DevTools Protocol).
Usually you're either pointing at a deployed development instance or running everything locally via Docker.
I prefer the deploy approach as your machines resources aren't zapped, but that means CORS settings need updating per deployment 😂
So I wonder: How often are seeders used at all for large/growing apps?
No Laravel app would do or recommend this either. Seems like a big anti pattern there
but when using frameworks like next.js, remix, sveltekit, etc.. it's not really doable
we use sveltekit and i wish we didn't have to run the database locally
My experience has been using separate company-wide dev DB (for both frontend and backend).
We had tooling to generate dummy data if needed.
Every fintech product I’ve worked with has strict rules against this 😂
Local FE/BE - Prod DB
Local FE - Prod BE/DB
Local FE/BE/DB
I think it has to do with the risk of mutations and coupling of backend/frontend (Stripe)
🦋 client seems cleanly separated from the backend product.
It's very easy to run and dev locally.
It makes debugging & fixing issues 10x easier cuz u have a comparable dataset, warts and all.
It’s definitely my preference over running a backend/server locally.