How are people handling local development with 8base? Ideally, I wouldn’t want local changes to affect other environments (dev or prod). Having a separate workspace for it would be fine if there’s only one person contributing to the project, but paying for a new workspace for every developer on our team doesn’t seem to make sense.
Is there a way to run the whole setup locally instead of pointing to a remote workspace?
Great question. Currently we do not have a local/offline database functionality, so any developer writing functions locally (if those functions use the API) would be connecting to the same Dev workspace.
For teams, I’d recommend that you set up a project repository on GH with a CI/CD script that handles the deployment. This way developers will contribute to the single repo and not overwrite each other’s work.
Hail Mary here… But @GavinRay at one point had a really cool solution for mocking API calls locally so that the API wasn’t called!
Thanks for the answer!
For things like editing the schema, what’s the recommended way to test changes before pushing them to source control? Have a dedicated “local dev” workspace knowing that everyone could change stuff at the same time?
Hey @emroussel - part of the CI/CD can be using the import and export commands on the CLI to update the workspaces. That said, I wouldn’t consider it a full blown migration solution (which were working on).
In regards to having multiple devs editing schema at the same time, 8base really does treat that almost like a Google Doc. It’s the curse of convenience 
What I’d recommend is creating different Developer roles (with schema permissions, without, etc…) that you assign only to team members working on your projects. This way, only developers that should be able to tinker with the schema can.
Sounds good, thanks!