Using slugs instead of dashboard id in url's.

cparsons · 06-23-2020 06:45 AM

I have read in a couple places about using a dashboards slug instead of its id in a custom url. I have not been able to find any examples of this. We are wondering if using the slug could help us in our deployment process. If so, where are some examples of this?

Our current setup is we have a dev instance and a production instance. When moving a dashboard from dev to production the id changes. The dashboard then has a different id in dev then it has in production. Thusly, all the urls to that dashboard have to be updated. We are semi working around this by having constants for dashboard id’s in the url so the id’s only have to be updated in one spot.

Because the dev to production process is so complex our thought is to change to one instance. Then the use case becomes how to update a dashboard. 1. Copy to a new space. 2. Make changes. 3. Replace dashboard in production folder. This whole process seems to break down because the id and slug would be different.

IanT

Take a look at a tool called gazer which you can force an overwrite to keep the ID so long as the db name is the same.

cparsons

We do use gazer to deploy dashboards from dev instance to prod instance. Not sure if we are using force. So you are saying that if we use force and create a new dashboard on dev when we deploy to production, it will have the same dashboard id.

IanT

No not a new one u less by coincidence or you have stayed in sync since the start. If you update a dash on dev and promote it to prod the prod dash ID will remain the same as it was before the edit.

cparsons

So is creating url’s using the dashboard slug a solution to that? Is it even a thing? Trying to not have to update dashboard id’s in our url’s after we push to production.

IanT

I get your point here and agree it would be useful. Might be tricky to manage the slug in the backend because any minor minor change should mean a slug change, it’s only really useful for this specific use case.

Steve_Maier

Chad,

I think you are on the right track regarding moving to a single instance and solving for content governance (i.e. prod dashboards not breaking) via process. We made a similar leap with our instance, and it has proved to be the right call since:

As you point out, generating Slugs then migrating dashboards from Dev to Prod requires substantial overhead, and is prone to bugs (formatting changing when the port occurs, Gazer quirks, etc).
Looker’s feature set allows for a single environment with minimum risk since:

*As you point out, you can build Looks/Dashboards in a sandbox folder then simply edit the governed copy when ready.

*All LookML development occurs in a separate git branch, and you can mitigate risk of bad code making it to Prod via Content Validator, mandatory auto-UAT, and pull requests.

*Shared development can occur via a Shared Branch in git (i.e. code fork w/ multiple users).

There is a bit more risk to having a single environment, but in my opinion the benefits of having a single dev flow and speed of continuous deployment outweigh the concerns.