I’ve noticed a pattern among even very strong development teams that I believe costs them more than they realize: they are so accustomed to always running both the frontend and the backend together in development that they haven’t stopped to notice all the unnecessary tight coupling they’re tolerating, and how much it can slow development and (especially in the case of open source apps) new contributors.
Given the security model of the web, there’s no reason it shouldn’t be easy to run your local ember-cli against your production backend. If that’s hard for your app to do, consider fixing it. You’ll end up with a cleaner architecture, and lots of day-to-day development tasks get faster and easier.
I know CORS can be a mystifying topic until you get a chance to learn it, but it’s not deep and it’s not hard. It rarely takes more than a few minutes to enable cors on a server, and you should have already been following the security best practices that make CORS safe to enable – like authenticating all API requests with a token in an HTTP header.
A nice pattern is to have the default dev settings in the ember app pointing at the production server, so if you do nothing but ember s you get a fully working development experience. Then if you want to point at a local server instead, you set one environment variable like API_URL=http://localhost:3000.
100% agree. I do a good chunk of my front-end work pointed at our staging environment, and occasionally at production (helpful for bugfixes, stuff with complex data, etc). Much nicer than having to make sure API infra is running locally all the time.
Isn’t running against a production back-end a bomb waiting to go off, though?
I know developers can just use their silo (their user account) to protect against unwanted, destructive actions but I still feel like it’s just a matter of time before someone deletes customer data.
But how though? Running this way, you don’t have any privileged access to the server that a normal user doesn’t have.
You can’t accidentally run a database migration for example. That’s why this is different from, for example, connecting a local server to the production database, which would indeed be dangerous. The difference is your server is still enforcing its security and consistency rules.
Putting it another way — if it’s possible to make your application unsafe by only changing the ember app, then you have a security vulnerability because anybody can change the ember app running in their browser.
Developers and QA often test out features, or try to replicate a bug by logging in as a specific user, or as an admin user that has –potentially destructive– access to “simple” user accounts.
If they are not aware they are working with production data, they might do something which is irreversible and can be very costly.
Or is there another way to do those kinds of scenarios?
Developers and QA often test out features, or try to replicate a bug by logging in as a specific user, or as an admin user that has –potentially destructive– access to “simple” user accounts.
If your app is designed to let admin users do destructive things or masquerade as other users on production, then that is already a fundamental risk built into your app, so you’ll need to build those features with safeguards that make it very clear to those admins what they’re doing.
Making it easy to point your ember-cli build at production doesn’t add anything new to that risk. Anything destructive you can do while running a locally built copy of the ember app, you could have just as easily done by logging directly into production.
But also, using production as the target was just an example. As a matter of policy, you can maintain a deployed staging environment instead and use that.
The point is to make it trivially easy to switch between different backends while developing the ember app. Sometimes you’ll be working on a backend feature, so you’ll need to point at your own server. But often you are not, so you can point at staging or prod and save yourself a lot of setup, and making it easy to switch backends tends to push you toward healthy architectural decisions.
I agree as well - and the other handy benefit of this approach is that, when prod issues do occur and you are configured this way, you can debug easily from your local env without having to go to extreme measures (except for highly user-specific issues and a few other special cases, but those in practice seem to be few and far between).
Overall, for us, the closer we hold ourselves to develop against what “real life” will look like, the more efficient we seem to be across the process.
I agree that it should be possible to point the front end easily to a different back end, but in all non-trivial scenarios i know the developer has not enough permissions on production to perform any serious development.
That’s an interesting point because I was thinking mostly of multi-tenant applications where it’s very easy to make extra accounts on production, and those accounts don’t need to be visible to any real users. But yes, I can definitely imagine scenarios where everybody sees everything, so you wouldn’t want any developers playing with data. For that you really need a separate staging environment instead.