jjanyan

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.

Stallman being reinstated?

https://www.theregister.com/2021/03/30/fsf_mass_resignation/....

"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.

Nice being able to A/B test from the backend, without using javascript.

I've gotten some really click through rates from A/B testing religiously.

Thanks for the feedback.

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!

Thanks!

Yep. You can keep an eye on the market without doing anything!

Awesome, glad you like that aspect. We think it's pretty important to users.

Concurrent development with maximum flexibility:

It might be a bit hard to follow, but this is the branching strategy we follow. http://tinypic.com/view.php?pic=15wi351&s=7

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.