Add support for postgres wallet type

[TimoGlastra]

No description provided.

[ghost]

Hi @TimoGlastra I am working on adding support for Postgres
My approach is the same as this postgres-plugin/nodejs

[TimoGlastra]

That's great @sairanjitAW!

[swcurran]

Not that I want to discourage any efforts in building the platform, but is this a good use of time? This implies using AFJ on the server-side. AFAIK there is a fair amount still to add to AFJ to make it useful/scalable for operation on a server platform. Is there a reason not to push that effort into ACA-Py for server-side uses and focus AFJ efforts towards mobile functionality?

[TimoGlastra]

I strongly disagree with this, and we're really interested in building out AFJ as a platform for both mobile and server side use cases. ACA-Py has had A LOT more investment for server side applications, but there's multiple reasons why we're interested in using AFJ for the server side (Being able to share the same codebase and protocols between environments, AFJ is more strictly typed which is a big + IMO, TS is a very popular language, a lot more libraries available in TS for SSI/Blockchain related projects than python, etc...).

So I'd definitely say this is a good use of time!

[swcurran]

Sounds good! Happy with that answer. :-)

[genaris]

I strongly disagree with this, and we're really interested in building out AFJ as a platform for both mobile and server side use cases. ACA-Py has had A LOT more investment for server side applications, but there's multiple reasons why we're interested in using AFJ for the server side (Being able to share the same codebase and protocols between environments, AFJ is more strictly typed which is a big + IMO, TS is a very popular language, a lot more libraries available in TS for SSI/Blockchain related projects than python, etc...).

So I'd definitely say this is a good use of time!

+1 to Timo's words. For small teams it could be very beneficial to be able to share the same code base and use a single language/toolchain, especially when implementing custom features such as specific protocols over DIDComm. Also I like the 'framework' approach in terms that Agent class can be easily embedded within an existing application instead of using a separate module for handling Aries stuff.

[TimoGlastra]

Fixed