Senior Software Engineer at a consultancy with 51-200 employees
Real User
Top 5
Oct 23, 2026
I don't like the whole paradigm change at all. We are seasoned object-oriented programming developers, and Styra's Rego paradigm is close to SQL declarative language, so it's been a very hard adaptation. One of the biggest issues we have is that if you don't currently code in it and take a break for two or three weeks or a sprint where you do object-oriented programming in Java, when you go back to Rego it's a learning curve all over again. We don't have very good tooling for testing our code. Styra provides us with a playground where we can copy-paste code snippets and test bits of the code. The problem is that we rely on internal common libraries that we built ourselves, and we have no way to drag and drop a file and import the whole library. If I want to touch a piece of code that has something to do with our common libraries, which is 80% of the time, there's no clean way to test it in the Rego playground. We basically have to do coding gymnastics for each piece of code we test. Styrå's Rego is a tool best used for authorization and authentication purposes—quick checks like whether someone is an admin, a user, or has special requirements. What we're using it for evolved into business-oriented code where data is parsed through Rego and checked alongside the authorization and authentication purposes. It became very big, very fast, and very hard to maintain. Although this is not necessarily Styra's problem because it was our company's choice to use it for business purposes, it evolved very badly. We still have ongoing discussions with the architects about two to two and a half years after we started doing that, and we're still debating if it's the best place to do things. We're still promoting searching for other technologies to replace it, but after two years, it's become a monster. Many teams have onboarded and it's basically impossible to change it now. We're just waiting for the architects to find the next technology and migrate towards that. Regarding the pre-built policy libraries, we are using Rego's built-in mechanisms such as YAML validation, and that's one of many problems we have. Our business solution in our department covers API documents, specifically Swaggers and OpenAPI specifications, so we need to do parsing and processing on JSON files and YAML files, and the support is quite bad. We have an outstanding bug with the library that OPA is publishing—a basic interaction bug. We use the YAML is valid function built-in, which for our use case gives us false positives and clashes with the other validations done inside our organization. For the past two years, there's been no change on that. We even opened issues to their tracking system. We don't have any support for that, and we don't have enough time to make a contribution ourselves to the model.
Container Security involves protecting containerized applications from potential threats throughout their lifecycle, ensuring integrity, authentication, and visibility. It offers robust measures to safeguard applications in a constantly evolving environment. This approach focuses on securing containers to prevent unauthorized access while maintaining application performance. Businesses can use Container Security solutions to detect vulnerabilities, monitor processes, and manage compliance...
I don't like the whole paradigm change at all. We are seasoned object-oriented programming developers, and Styra's Rego paradigm is close to SQL declarative language, so it's been a very hard adaptation. One of the biggest issues we have is that if you don't currently code in it and take a break for two or three weeks or a sprint where you do object-oriented programming in Java, when you go back to Rego it's a learning curve all over again. We don't have very good tooling for testing our code. Styra provides us with a playground where we can copy-paste code snippets and test bits of the code. The problem is that we rely on internal common libraries that we built ourselves, and we have no way to drag and drop a file and import the whole library. If I want to touch a piece of code that has something to do with our common libraries, which is 80% of the time, there's no clean way to test it in the Rego playground. We basically have to do coding gymnastics for each piece of code we test. Styrå's Rego is a tool best used for authorization and authentication purposes—quick checks like whether someone is an admin, a user, or has special requirements. What we're using it for evolved into business-oriented code where data is parsed through Rego and checked alongside the authorization and authentication purposes. It became very big, very fast, and very hard to maintain. Although this is not necessarily Styra's problem because it was our company's choice to use it for business purposes, it evolved very badly. We still have ongoing discussions with the architects about two to two and a half years after we started doing that, and we're still debating if it's the best place to do things. We're still promoting searching for other technologies to replace it, but after two years, it's become a monster. Many teams have onboarded and it's basically impossible to change it now. We're just waiting for the architects to find the next technology and migrate towards that. Regarding the pre-built policy libraries, we are using Rego's built-in mechanisms such as YAML validation, and that's one of many problems we have. Our business solution in our department covers API documents, specifically Swaggers and OpenAPI specifications, so we need to do parsing and processing on JSON files and YAML files, and the support is quite bad. We have an outstanding bug with the library that OPA is publishing—a basic interaction bug. We use the YAML is valid function built-in, which for our use case gives us false positives and clashes with the other validations done inside our organization. For the past two years, there's been no change on that. We even opened issues to their tracking system. We don't have any support for that, and we don't have enough time to make a contribution ourselves to the model.