I've been wanting this for years and have been tempted to write it myself.
I've imagined a way to create your graphql query in a UI then "bookmark" it.
After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.
So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.
One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features.
The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.
If anyone is familiar with something along these lines I'd love to hear about it.
The proposed solution does exactly what you describe in the first part. By turning GraphQL Operations into an RPC endpoint, we've essentially whitelisted the Operation. We've not only whitelisted the Operation but added a whole lot more but obviously I don't want to repeat the article. If you're interested discussing this further, find my contact information at the end of the blogpost.
"Sagas", or distributed transactions, are what you're looking for.
These are APIs/functions/methods that know how to complete every step of your atomic operation and how to roll it back if any step fails. They more or less recreate what would have been a single database transaction pre-microservice.
The salary matching isn't an issue. When a recruiter/employer creates a job listing, there is a maximum and minimum salary.
We look for jobs where you're desired salary falls within the max/min range of the job.
Again, love the feedback. Please share with your friends!
We use jira for managing our code changes and requests. Each ticket has its own branch. Everyday we merge the tickets we want to go out into a release branch, as you can see in the image. Release, then merge into master once we are satisfied with the release.
The benefits of this strategy is having maximum flexibility in releasing any code change. A request can be made, completed, and released in the same day, often in combination with changes that have been in progress for weeks.
The draw back is managing which branches are going out when, more so with teams greater than 20. It takes knowledgeable team leads and release managers.
After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.
So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.
One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features. The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.
If anyone is familiar with something along these lines I'd love to hear about it.