Why Use a Permission Library?

[00:00:00]
>> Kyle Cook: So, the next thing that I want to talk about is how we can get some of these benefits, especially of the complex, more advanced attribute-based access control, without managing all of the TypeScript complexities ourselves, and that's by using a third-party library. Essentially with permission-based libraries, there's a few different types of libraries you can use, and when it comes to using a library or not, you have to really weigh the pros and cons.

[00:00:21]
If you build your own permission system, this makes the most sense when you want maximum control. There are certain trade-offs you make anytime you use a permission library, so if you want maximum control, writing your own library maybe isn't the worst case scenario. Also, if your permissions aren't too overly complex, using a third-party library may add extra complexity rather than solve that complexity for you.

[00:00:42]
A library makes the most sense though, when you just want to plop something in place that has these advanced features and you can just deal with them right away, or you want to follow easily established patterns, or maybe you're working on a team because your team knows what this library works like, so it's easy to onboard people cause it's a common library in your library or you're in your language or framework of choice.

[00:01:00]
Now, as I mentioned, there are two main types of permission libraries you're going to work with. The first is going to be an in-code library. This is what we have written up to this point. All of your permissions are defined directly inside your code using the language of your choice. So JavaScript, TypeScript, whatever language you're using, that's what your permission system is built entirely in.

[00:01:19]
There are pros of this is that you get full IDE support, you get autocomplete type checking, you get great type safety. It's easy to debug cause you only need to learn one language instead of multiple. You don't have to context switch between languages. And you can use all your application logic directly inside of this. Now the cons is that it's difficult because your policies for all your permissions are now embedded in your code, and that means if you want to change your permissions, you have to redeploy your application, unless you use some type of third-party data storage like you're storing your data in a JSON file that gets ingested into your project, but then again, that adds more complexity to do that.

[00:01:55]
It's also harder to share your policies. If you're on a really large enterprise scale team, you may have one team working in Go, one team working in Next.js, one team working in Rust, and if you want to share permissions between all of these three teams, you need something that is external to these languages that you can share between each of these different teams. So, really, what you're going to want to do is move over to a domain specific language if you have that particular situation where you have multiple different teams on multiple different languages.

[00:02:22]
Now, some popular in-language libraries would be CASL, that's what we're going to be covering in this course. That's going to be for JavaScript, TypeScript, or anything like that. Pundit is a really common one in Ruby and same thing with CanCan, another Ruby gem that you can use. Now DSL or domain specific language is essentially a language built entirely around a specific thing. In our case, it's entirely built around defining policies in our code.

[00:02:44]
And here is an example of what those files may look like. So you can see here, we have a file that defines our permission structure, and then this file is actually defining the permissions that our user has access to. Now, if you've never used this type of permission system before, you're probably looking at this and thinking it's entirely a jumbled mess, and that's perfectly normal because this is very different than, you know, JavaScript or TypeScript or Node or whatever language you're particularly working in.

[00:03:08]
Now, there are some pros to this system though. First of all, your policies are entirely separate from your application code. This is great again in that situation where you want to share between different teams using different languages or frameworks. You can also easily update your policies without redeploying, because again, they're entirely separate from your actual application code. And it's easier to audit to a degree.

[00:03:29]
If you are someone that's very familiar with like the languages that these are written in, it's easier for you to read because you don't have to dive into source code. You can just look at these policy files to handle everything. Now, some of the cons, biggest one by far, you have to learn a brand new language, whether it's a specific language for this policy language or a different policy language, you have to learn some other new language.

[00:03:50]
You also have relatively limited IDE support, for the most part because it's separate from your actual language, which means there's a barrier between the language you're writing your code in and the language you're writing your permissions in. And generally when you have two languages like this, the bridge between them is not as ideal as if everything is in one single language. This also sometimes makes it harder to debug, and you usually need extra infrastructure to manage where your policy files are hosted and shared between your different applications.

[00:04:14]
Probably one of the more popular ones out there is Casbin. That is going to be something that supports multiple different languages, and that's kind of like the alternative that I would use instead of something like CASL for an in-programming language. So it depends on your specific use cases and needs, but Casbin is a good option for something that's going to be in that domain specific language category.

[00:04:34]
Now, like I mentioned, we're going to be using CASL, and the main reason we're using CASL is cause it's an easy drop-in replacement for what we've written so far. You actually will notice that a lot of the code that I have written is based pretty similarly on how CASL does things inside their code. They do some things slightly differently, but it's built on the same exact attribute-based access control system that CASL uses.

[00:04:54]
So we're able to see some of the benefits you get from using a library and also some of the drawbacks that you get from it as well. And this is kind of what CASL's code may look like, and when you look at this, you may think if you squint your eyes a little bit, it's pretty much the same stuff that we wrote in our project as well. There's just a few differences on the order of certain things and how you define things, but for the most part, this code is pretty much exactly the same as our code with a few minor changes.

[00:05:18]
Now Casbin, since it's a domain-specific language, you can see it is much more complicated and difficult in how you write it because it's entirely different from what you're maybe already used to.