Additional ideas for jCasbin

[seriouszyx]

In the process of development and communication, some issues for jCasbin still needed to be addressed. I would like to focus on these during GSoC '22 if I have the opportunity to attend.

Additional ideas

jCasbin Ecosystem

For some historical reasons, casbin-spring-boot-starter and some middlewares such as jdbc-adapter and redis-watcher are inconsistent. For jCasbin users, these components are confusing. And for jCasbin developers, multiple components have to be maintained at the same time to keep them consistent, which will generate a lot of redundant codes inevitably.

The basic idea is to compare the features of casbin-spring-boot-starter and other middlewares, and the implementation of features will be done by middlewares. The casbin-spring-boot-starter can easily integrate these middlewares.

Benchmark

It seems jCasbin have some benchmark but didn't list them in the official documentation. And in practice, most users will persist policies to the database. It makes sense to benchmark the system performance. In addition, well-established benchmarks help to compare performance after resolving performance bottlenecks.

Large-scale Scene

Casbin docs provide performance optimization advice. Especially for the high number of policy rules, users can use some strategies such as Policy Subset Loading. But this places greater demands on the users.

We can take full advantage of the powerful Java ecosystem. For example, use ShardingSphere to implement a middleware named (maybe) ShardingSphere-jdbc-adpter, provide users with a simpler alternative for the large-scale scene.

Summary

Assuming they make sense, I drafted updated ideas list as below.

1. More features support

• Sync more features about "in" special grammar from Go-Casbin: https://casbin.org/docs/en/syntax-for-models#special-grammer
• Make a default implementation of WatcherEx and migrate Watcher to WatcherEx : https://github.com/casbin/casbin/issues/943
• Fix the bug about ClassCastException for Strings within grouping fucntions: https://github.com/casbin/jcasbin/issues/254

2. Continuous maintenance of the surrounding ecology

• Optimize casbin-spring-boot-starter and other middlewares dependencies.
• Provide more offical adapter/watcher like Golang: https://casbin.org/docs/en/watchers.
• Make a Play Framework middleware: https://github.com/casbin/jcasbin/issues/104
• Help solve issues for the 1st-party and 3rd-party middlewares.

3. Benchmark and performance optimization

• Benchmarking jCasbin and the integrations with main middlewares.
• Find and resolve performance bottlenecks.

4. Explore the alternative in large-scale scenarios

The above are just my personal rough ideas, some of which have not been strictly researched. This requires mentors to assess feasibility and workload. Welcome to discuss.

@hsluoyz @fangzhengjin @tangyang9464

[casbin-bot]

@tangyang9464 @closetool @sagilio

[rahul3002]

can i solve this issue??