Basic REST and JSON RPC are very simple to start with, but have common problems when application gets bigger. How do you represent relations, pagination, filtering etc? My go-to specification for structuring JSON documents is https://jsonapi.org/ It covers most basic needs of a standard API.
Operating a blimp on Venus would be a bit tougher than on Earth, partly because the density of Venus atmosphere is only 95 % of our air (less lift per lifting gas volume), and also because of the incredibly violent 100 m/s winds, 93 bar pressure and a temperature of 470 °C.
Schema(or data in a database) in your release N should be compatible with release N-1, so you can revert your code to previous working version with new schema. That's the only way to ship new releases without stopping service for maintenance.
A lot of replies talks about schema migration and tools like Liquibase etc. But as I understand the question, it's about running update / delete queries in production environment, not DDL.
In my opinion such queries should be subject of established development process:
1. Commit your query to a repository
2. Send to code review
3. After successful review and merge it should be deployed automatically by ci/cd
It may be necessary to run query directly via console in some cases, though. But such query should be committed to the repository latter any way.
And of course you should use proper tools like comments suggest.
Correct. We use Flyway and have it setup through GitLab CI/CD pipelines. We used to have a bottleneck on one of two people with permissions. Now, if data needs to be pushed to the production system for some reason through a script, an Issue/MR in GitLab gets the Flyway script, it must be approved by two people on the team (other than the person who did the work), it must make it through the test system, and then can be pushed to production directly through GitLab. It increases the process but is safer and reduces the bus factor.
reply