use DbClient to implement business logic

[djudjuu]

closes #40, #18 , #17

• [x] DbClient to write to DB, can initiate a simple loan-request and fetch basic info for lender & borrower from the dashboard (I just looked at the frontend mockups and ran with what was there)
• [x] tests on a local test-db

we still need to do a lot of things, e.g. making sure the balances of lenders-are reduced, creating a set of transactions, creating loan-history,... but this thing is too big already

Also the AI is still just a mocked up, creating a simple offer

[gparuthi]

(Copied from slack) Great work. I agree that the first version needs to be super simple form based UI and hacky is fine. I feel we have spent just enough time on business logic and it's important now to get the MVP running in some shape and form.

This should do this (Check #26 for borrower mockups.):

• register users
• borrower create loans
• optimization works
• lender, borrower confirm
• simple dashboard

Other stuff can be implemented later. e.g.:

• Add edges interface and interaction

[djudjuu]

copied for reference:

• adds a bunch of helper funciton to the DbClient() that can be used to do the user interactions DIRECTLY FROM THE FRONTEND
• I decided that there are some helper functions that are useful, but which should never be called from within the frontend. those are defined in *_helper.js and they take the gqlClient as an argument. Thus the DbClient can use them by passing its client as an argument
• Also add a bunch of mutations and queries in queries.js that are the closest to the metal in terms of the actions that we want to do in our user-journeys. (some structure as to what needs to be built would be very helpful though (see (5) below)

TODOs

1) Codestyle

we should decide on how to camelcase stuff and when to snakecase... I am going crazy already. the graphql-client is using snake_case for all the variables (hasura-GraphiQL interface), but everything is in javascript so far....So my proposal would be: keep all the functions names in camelCase (js style)... and all the stuff we need to interact with db can be snakeCase....Well actually, I want a linter to make all those decisions for me :) (see WIP-PR #35

2) Typescripting!

To be fast, I went with js.... but I already see how it's getting confusing. Also I think we can generate all the types from the graphql-schema ( I linked a library I found in a comment in the types.ts. It would be cool if you could take the lead on this, I started it, but then took way too long just looking up how to define the network. I'll see whether I can take some time to properly read the docs... I know I'll like it once I am more fluent in it..

3) AI Container interaction

On a high-level I get it. The FE puts stuff in a container, the container does it's thing and calls into our api. I wrote a helper function storeAiResult that will write the necessary changes to the DB, but I was unsure how to do the endpoint. I guess, I need to write a handler function, like you did in the other files in pages/api. But probably thats something for another PR. For now I think its fine if we mock the AiModule.

4) Subscriptions

We probably want to have some stuff in the frontend that listens to changes in the DB. Therefore gql's subscriptions are the way to go. Will be nice ot build a prototype to that end

5) Overall planning

This is the core-business logic of arboreum. I feel all of this needs to be way better documented. e.g. flows of what happens if a loan is accepted. state-diagrams for all enums (loan-request states, guarantors-status, encumbrance/payable-status). I am making these up as I go along, but there should be a better way.

This is the most important point, i think. We need to get these flows out of my and @gsVAM 's head and onto paper.

6) Overall planning again

what are we building. specifically? I feel it's a good place to look at the frontend, but are we set on the user-journey-flows for we did for financePeer? or should we dom something simpler? or slightly more complex? Also, what exaclty happens in the risk-module when we are using the corpus model. Do we need to update it? How? Let's do a sync on that.

I think we are making rapid progress, so to keep momentum, we need to re-enter into planning mode and map out the terrain/waters ahead :pirate_flag:

7) smaller chunks

This pr is pretty big already. I am down to break it into smaller chunks...It was more intended to get some end-to-end thing done, even if its hacky.....thinking ahead, we will need to think how we process payments, for example. Should we have an admin-view, where we can look at all incoming payments and manually check them. then mark them as good and invoke some special function on an adminClient (similar to the DbClient).... hmmm...let's make it really small, i'd say, there is still a lot to do. I will be grateful for some perspective on that

[djudjuu]

Looks great. Minor thing but I am not sure why the helper functions that take gqlclient are separate from the DBClient? I think storeAiResultToDB and getNetwork can be within DBClient?

previously I

decided that there are some helper functions that are useful, but which should never be called from within the frontend. those are defined in *_helper.js and they take the gqlClient as an argument. Thus the DbClient can use them by passing its client as an argument

but now I think otherwise. moved it into DBclient for now