Design architecture and establish requirements

[danrminds]

• [x] Design API structure.
• [x] Decide what to be developed in services and what in API
• [x] Decide if SERVICES should be on PHP or NodeJS?

[jamalv]

API: I think to keep the API simple, and to assure that the functionality can be fully decentralized, we should initially focus it on providing the functionality for the app. So that’s transactions and validation.

Services: I think it will initially be the majority of the system. When we’re confident, we can start moving parts over to the API. We should take our time for this since I think architecting for blockchain and self-sovereign identity works a bit different than having a traditional database where we hold all the information. I also think since transactions in smart contracts are expencive and computers are getting faster and cheaper, in a decentralized world more processing will happen on the front-end vs. on the blockchain backend.

PHP/NodeJS for the services: a pro of using php is that we already have a lot of the functionality we need in kindpakkket 1.1 and we can use the native bunq php sdk (there is no nodejs sdk yet). The cons are that it might be harder to move the functionality from the services to the api or the frontend. Jusing javascript/json everywhere can be an advantage in the future.

I don’t know how much work it will be to move from php to nodejs, but it does seem like a good investment for the future, I think @danrminds should decide together with @dev-weget

[jamalv]

For forus.io I think a good initial reference for the functionality that should eventually go in the API is: https://github.com/teamforus/forus/blob/master/docs/forus.io.md

[danrminds]

So, we had couple of variations possible:

1. Monolith development architecture (traditional way0
2. Micro-services development architecture

After researching the micro-service approach me and Valentin came with a conclusion / proposal.

Here you can see an architecture 100% built on micro-services:

That supposes a following structure in our case (1 core application with services to handle the rest of the functionality):

core [PROXY]

identities

medias

records
funds

validators
providers
sponsors

categories
products

offices
transactions

[pros]

• each service is smaller and easier to test (as individual)
• easier to combine sql/nosql dbs, with future migration in mind
• teams can work in parallel on different services
• easier ulterior to switch to smart contracts and blockchain (but don't confuse easier with easy!)

[cons]

• application speed will go down in case we develop this on PHP. Each service will mean a separate PHP application - that needs to start at every call
• stability (one died service cand break the application and you will not even notice) - means more work on the interconnectivity of services and following the flow of the application
• testability (as whole system) - harder to track where issues come from
• much more time needed for research and development. Could cause a delay and not be in time. Could consider allocating one more developer from Rocket Minds (as it is possible to work on services in parallel)
• much more RAM and server resources (testing environments with 500mb or 1gb of ram will not work anymore) The production version will also require more resources.

Building a monolith version is also not a good idea, because of our plan to extend and migrate to blockchain / nodejs in time. That is why we come with a proposal of building a hybrid system using services and divide the core application in repositories (modular, not github repositories):

Proposal:

1) Develop mvp on repositories and few services

Repositories:

            - IdentityRepository
            - MediaRepository

            - RecordsRepository
            - FundRepository

            - ValidatorRepository
            - ProviderRepository
            - SponsorRepository

            - CategoryRepository
            - ProductRepository

            - OfficeRepsoitory

            - TransctionRepository

        Services:
            - Push notifications service
            - Bunq service 
            - Sponsors/validators server applications

2) all MVp services will be accessed through proxy repositories

        - BunqRepository
        - PushNotificationRepository
        - Other

3) Then MVP is ready, start building services to move business logic from repositories to service applications one by one. 4) Keep using repositories as a proxy for services.

[maxvisser]

Something like this for the repository names:

• api.forus.io-media (IPFS implementation)
• api.forus.io-identity (ERC-725)
• api.forus.io-records (ERC-735)
• api.forus.io-funds (ERC-20)
• api.forus.io-transaction-cache (transactions cache)
• forus.io-ext-validator (validator dashboard)
• forus.io-ext-provider (provider dashboard)
• forus.io-ext-sponsor (sponsor dashboard)
• forus.io-ext-requester (requester dashboard) Services:
• services.forus.io-push-notifications
• services.forus.io-bunq
• services.forus.io-digid
• services.forus.io-zuidhorn

[jamalv]

I would maybe add a -front- tag to the dashboards e.g:

• forus.io-front
• forus.io-front-ext-validator (validator dashboard)
• forus.io-front-ext-provider (provider dashboard)
• forus.io-front-ext-sponsor (sponsor dashboard)
• forus.io-front-ext-requester (requester dashboard)

[danrminds]

    Repositories:
        - IdentityRepository
        - MediaRepository

        - RecordsRepository
                    - mysql
        - FundRepository

        - ValidatorRepository
        - ProviderRepository
        - SponsorRepository

        - CategoryRepository
        - ProductRepository

        - AssetsRepository

        - VouchersRepository - PHP
        - TokenRepository - PHP
        - TransactionRepository - PHP

    Services:
        - Transaction service - BLOCKCHAIN
        - IPFS Records service
        - IPFS Media service
        - Push notifications service
        - Bunq service 
        - Sponsors/validators server applications
                    - DB connection
                    - DigiD