JakeUrban
commented
3 years ago Hello @Samrose-Ahmed , thanks for the feedback.
Polaris is definitely an opinionated project. Its primary purpose is to reduce the technical work necessary when starting an anchoring business, and attempts to provide all functionality that isn't specific to a given anchor.
Creating a core library that this project utilizes is an interesting idea, but when I try to think through what could be extracted and put into such a library, it doesn't sound very compelling.
Essentially, the library would consist of a set of request & response schema validators. In rare cases Polaris is able to provide functionality beyond this without input from the anchor, such as SEP-10 challenge validation, but I'm not convinced such a library would be widely used given the limited scope and simplicity of the functionality it would implement.
Addressing the points you brought up specifically,
it ties you to a specific web framework (Django)
True, but given that Django is the most comprehensive framework that exists the Python ecosystem, I don't see any problem with this other than personal preference & familiarity. It doesn't lack functionality that other frameworks offer, maybe other than async IO, which is being developed in 3.0+.
assumes and brings in dependencies for your database
If you're talking about the psycopg2 library, I agree that this shouldn't have been included in the project's requirements, and will be removed in Polaris 2.0. cryptography is an unfortunately hefty package as well, although its the most reputable and well maintained.
Everything else is related to Django and relatively lightweight.
update: psycopg2 has been removed from Polaris dependencies in v2.0.
has UI components (outside the Stellar SEPS)
It does, but using it is completely optional. Polaris provides users mechanisms to use a completely independent application for SEP-24 interactive flows and doesn't require you to compile the static assets included in the package if you don't need them.
If you think I'm missing something that changes the value prop of a 'core' library we can discuss further.
What problem does your feature solve?
Users, i.e implementing anchors or parts of the Stellar protocol, value the abstractions in this library. However, this library is quite opinionated, it ties you to a specific web framework (Django), assumes and brings in dependencies for your database, has UI components (outside the Stellar SEPS), etc. Users who have a different architecture cannot easily use this library.
What would you like to see?
Extract the platform/db/backend agnostic portions of the library into a new less opinionated library so users can benefit from the abstractions herein. This shouldn't affect this library as it can depend on the new library internally without changing its interface.
What alternatives are there?