Voice of the DBA

Category: Blog

Removing the REST Endpoint in the Data API Builder

The more I work with the Data API Builder (DAB), the more I lean towards GraphQL instead of REST. Rest isn’t bad, but it’s tough.

This is part of a series of posts on DAB that I’ve written. I also have articles at SQL Server Central about DAB.

Checking the Endpoint

In my first article and DAB, I set up things with defaults and exposed a table. As you can see, my REST endpoint is live and running.

I can also see this in Postman.

Wht if I want to remove this and only look at GraphQL? Let’s see what I need to do.

Removing the REST Runtime

In the config file, there is this section for the REST configuration at runtime.

I can remove this, but I’d hope I didn’t mess up the JSON. This is hard to read. Certainly this is something I can delete, but is there another way?

There is. In the DAB CLI reference, one of the parameters is –rest.disabled. Let’s try that.

That doesn’t work. Hmmm, OK, let’s add the database type

Apparently init only creates new files.

There is an update verb, but that doesn’t work either.

I guess I’m editing the file. I remove the highlighted section above and the API starts.

Let’s check the REST endpoint. It appears to still work:

In the runtime, I see this log:

Weird. I see an error, but data is returned.

Looking down, I see this in my config for an entity. The REST is enabled.

I’ll change that to false and restart the DAB service. Now I see this. REST is still there, but this path is broken.

If I go to the root for /api, I get a 404. There’s still a response, as there is a service here running GraphQL, but the REST path for /api is gone.

Summary

I’m not sure this really works, as if I enable this for any entity, then the REST call works. If I add any entity without using the –rest: false parameter, the REST path is added by default, so my guess is this is likely to be randomly added back by developers if they don’t have a wrapper around the CLI that ensures no REST paths are enabled.

January 15, 2025
T-SQL Tuesday #182: Personal Integrity
It’s time for the first T-SQL Tuesday blog of 2025, with an invite from the first non-founder to host a party, Rob Farley. I reached out to Rob and he graciously agreed to host. His invitation this month is on integrity, leaning towards data integrity.

I still manage the T-SQL Tuesday list, and I’m always looking for hosts. I have a few scheduled for 2025, but I can use more. If you’re interested in hosting, hit me up at one of these places:
- Twitter/X (@way0utwest)
- Blue Sky – way0utwest.bsky.social
- Github Issue – open a new one
While data integrity is important, I think personal integrity really matters as well.

Integrity at Work

I used to work for a large corporation, which I won’t name here. This was a 10,000+ person organization and I helped manage part of the data group for the company. I had a number of reports, 10 or 11, that handled different aspects of production operations across a variety of database platforms.

It was a busy job, and our environment was far from stable. As is the case, things get cobbled together, become popular, and then limp along for years. This happens in small companies and large ones, but in large ones, I think it continues because when there are problems, we can throw people at the problem. We could throw resources and fix chronic issues, but that wasn’t the case at this company.

At the time I worked at this company, we had a stacked ranking system for reviews. Microsoft used to do this (and stopped), but think about ranking everyone in your team from 1-5, 1 being underperforming and 5 being outstanding. The “stacked” part comes from the need to have a certain number of 2s, 3s, and 4s. 1s and 5s were rare (5s more rare). Essentially a 1 meant you were on a performance plan and on the way to termination.

I had to rank my staff, who worked hard and kept our systems running, despite lots of incidents. We performed some large migrations and upgrades of systems where my staff worked multiple weekends, with no comp time, just meals covered.

My first integrity stand was that even though I wasn’t officially allowed to give comp time, I did, working through my staff with extra days off that were unrecorded anywhere. This might be more of a violation, and if my boss’s boss had caught wind of this, I would have been terminated. However, I felt my staff deserved something, as a few of these long weekends weren’t adding business value; they were things executives wanted to do for optics.

Near the end of the year, we had to rank our workers for annual reviews. I had most of my staff at 4s, with a couple 3s. I put in one person as a 5 for some great work they did. Justifying a 5 is hard and I thought I had a good case.

In a meeting of our IT department, the VP of Operations told us that we had too many 4s and that each director (1 level above me) would get an allocation of rankings and that each manager had to work to fit their staff inside that allocation. Anyone ranked a 1 would be outside the allocation.

My second integrity stand was to argue with my boss on why my staff deserved their rankings. According to their job descriptions and performance, I’d ranked then well, even though his quota meant he wanted me to move a couple 4s to 3s and 1-2 people to a 2 ranking. I refused, arguing with other managers whose staff I had seen underperform through the year. I told a few others they needed to absorb the 2s and 3s and not the data team.

I lost that battle and had some uncomfortable reviews (and the accompanying bonus/salary numbers), but I acted like an adult and told people I had ranked them a level higher and upper management lowered their ranking, not because of performance, but because of a quota.

As we went through the next year, management decided they needed to cut costs. They had managers compile a lot of numbers that were sent to outsourcing companies in an RFP to essentially remove IT from the company’s books. In a meeting, our CTO tried to spin this as good for workers as the winning company would hire our IT staff. The framing was that this outsourcing would save the company money.

My third integrity stand was when I questioned the way this worked in a large meeting of IT management and eventually got the CTO to admit that:
- a) everyone would have to re-apply for their job
- b) they might not get the same salary (higher or lower, you decide which is more likely)
- c) not everyone would be hired
This might work out for some people, but likely those who got jobs at a new company were risking their salary and workload in a new situation. I questioned this as being good for the company overall as we would likely lose lots of knowledge.

I left shortly thereafter, voluntarily, but I’m sure I would have been let go at a layoff that occurred near the end of that year.

I hated that job in many ways and was glad to eventually leave. I decided I would never work for a stack ranking company again.
January 14, 2025
Grinding Away: Mary Spender

A few years ago I stumbled on this video and loved it.

That led me to Mary’s page and this cover of John Mayer’s Stop This Train:

Since then I’ve been following her, watching this musician build a life around her music, her videos, and more. Her site is at https://www.maryspender.com/ and I was sad that I wasn’t in the UK during her tour last fall. However, I still follow her videos, where she describes how she approaches the music business, or song writing or her craft, etc.

Making a living as a musician has been her dream and while that slightly pivoted, she still works in and around music. She is making it, though I’m not sure she’s getting rich or living the easy life. My view from the outside is she grinds away every week at producing content and music that will allow her to continue doing so.

This might be a treadmill of sorts, but it’s also the one she chooses and enjoys. Music is her passion and finding a way to make a living doing something you love is admirable.

However this takes work. It’s a grind. Maybe an enjoyable one for her, but still regular work.

January 13, 2025
Friday Flyway Tips: Chaining Commands for State-based Deployments
One of the cool things I’ve seen with the new Flyway CLI is that I can combine multiple actions together in one call, which can make the process of writing automations streamlined.

I’m not sure I love this, but I’ll show how this works.

I’ve been working with Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.

Making a State-Based Deployment from the CLI

In a previous post, I showed how to use the new prepare and deploy verbs to create a deployment script and then apply it to a database. This is a great way to handle simpler deployments if you want to work in a state-based fashion with Flyway.

That post showed two different CLI calls, which are shown below:
```
flyway prepare -prepare.source=schemaModel -prepare.target="env:qa" -prepare.scriptFilename="deployments\FWState__deployment.sql"flyway deploy -scriptFilename="deployments\FWState__deployment.sql" -environment=qa -executeInTransaction=true
```
Easy enough, and I like this structure as I’d likely build a pipeline that looks like this, where I prepare the script, then have a manual approval step to check this before deployment:

However, you might argue that someone would check the script in a QA or other deployment, so maybe you streamline things later, or you use this as a QA/test deployment and want everything to run smoothly after a PR.

In that case …

Chaining Commands

I can run this code instead.

flyway prepare deploy …

Let’s see this work. If you look, I have a couple of changes that I can see in Flyway Desktop. There is a table alter and a new stored procedure.

I can streamline the automation of these two changes in the CLI with the code style above with this code:

flyway prepare deploy -prepare.source=schemaModel -prepare.target=”env:qa” -environment=qa -executeInTransaction=true

Here is the pre-execution look at my database:

The execution, which didn’t use a transaction. I’ll have to figure that one out:

And the post database view with the table and proc changes deployed.

I built and deployed the script in one command, and it also appeared to have added my script to the deployments folder. No idea why that happened either.

If you want commands chained, you can do it.

Summary

This post showed how you can chain your prepare and deploy commands together in one command, which might be preferable in some situations.

I don’t know if I like this, or would do it, but it’s not a bad idea. Ultimately, I’d really like this deployment script to be saved back to the repo so I could track it, but that’s going to be some work, and likely that means not chaining commands.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today.
January 10, 2025