I delivered a talk last week at the Future Data Driven summit. It’s one I’ve done a few times, but I really enjoy it. It’s on the Future of Database Development, where I present a view of where I think, and hope, database development goes.
Visual Studio Code and F5
The demo is in Visual Studio Code. I can git clone a repo and then open it in VS code. I authenticate to the spawn service and then press F5 to compile and start debugging. When I do this, I see as part of the output, this text:
This indicates that my database containers, 2 in this case, already exist and are being used. This app has some startup code in it so that any developer who clones the repo can just start running the app and writing code without worrying about what database software is installed on their machine.
If I check the Spawn service from the command line, I see my two database containers. In this case I am using these containers from the main branch. Hence the images (demo-todo and demo-account) get the branch added to the end.
In application software, we often create a branch to start doing our own work. With databases, this might involve either re-using the same database(s) in the new branch, or doing a copy (rebuild, restore, etc.) to have a clean version of a database.
With Spawn, I just create a new branch in VS Code. Then I click F5 again. Now I see that I need new containers. These are created with the branch name. Therefore I see demo-todo-demosteve and demo-account-demosteve as the new containers.
Coding in the project setup gets the credentials and ensures the app just works.
I think the future of better database development, especially for those “full stack” or application developers, means provisioning new databases as needed. This likely requires containers, and hopefully, a service.
We’ll see if we get there, but I do think a lot of the trends in software development are there to try and ensure we can reduce the hassles of building new environments on developer machines.