{"id":19423193,"url":"https://github.com/make-software/casper-dao-middleware","last_synced_at":"2025-10-11T04:24:42.898Z","repository":{"id":63452322,"uuid":"560871299","full_name":"make-software/casper-dao-middleware","owner":"make-software","description":"A mono-repository that consists of two apps. Handler is used to listen to event from the network, process them and store them in DB and API for exposing stored data.","archived":false,"fork":false,"pushed_at":"2024-07-08T11:11:09.000Z","size":1349,"stargazers_count":3,"open_issues_count":4,"forks_count":1,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-04-03T07:21:47.102Z","etag":null,"topics":["blockchain","blockchain-technology","casper-network","dao","golang"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/make-software.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-11-02T13:04:42.000Z","updated_at":"2024-07-08T11:11:13.000Z","dependencies_parsed_at":"2024-03-08T14:44:42.748Z","dependency_job_id":null,"html_url":"https://github.com/make-software/casper-dao-middleware","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/make-software%2Fcasper-dao-middleware","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/make-software%2Fcasper-dao-middleware/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/make-software%2Fcasper-dao-middleware/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/make-software%2Fcasper-dao-middleware/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/make-software","download_url":"https://codeload.github.com/make-software/casper-dao-middleware/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250663544,"owners_count":21467366,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["blockchain","blockchain-technology","casper-network","dao","golang"],"created_at":"2024-11-10T13:37:10.523Z","updated_at":"2025-10-11T04:24:37.865Z","avatar_url":"https://github.com/make-software.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Casper DAO Middleware\n\nCasper DAO Middleware is a mono-repository that consists of two apps. Handler is used to listen to event from the\nnetwork, process them and store them in DB and API for exposing stored data.\n\n## Build\n\nCheck various build options with:\n\n```\nmake help\n```\n\n## Run local migrations\n\n- Install [go-migrate](https://github.com/golang-migrate/migrate/tree/master/cmd/migrate)\n- Run local migrations\n\n```bash\nmake sync-db\n```\n\n## Testing\n\nEach component could be tested via unit or integrations tests.\n\n## Unit tests\n\nTo run unit tests for the component, make sure you are in the root of the component:\n\n```\ncd internal/dao/{component} \u0026\u0026 go test ./...\n```\n\n## Integration tests\n\nSetup database command:\n\n```bash\nmake sync-test-db\n```\n\nAfter your environment is ready, make sure you set up required env variables.\n\nRun integration tests:\n\n```\ncd internal/dao/{component} \u0026\u0026  go test -tags=integration ./...\n```\n\n## Run apps locally\n- Install [docker](https://docs.docker.com/compose/install/) and [docker-compose](https://docker-docs.netlify.app/compose/install/)\n\n- Run local [docker-compose.yaml](./infra/local/docker-compose.db.yaml) file\n```bash\ndocker-compose -f ./infra/local/docker-compose.db.yaml up -d\n```\n\n- Prepare .env files\n```bash\ncp ./apps/handler/.env.example ./apps/handler/.env \u0026\u0026 cp ./apps/api/.env.example ./apps/api/.env\n```\n\n- Run local migrations\n```bash\nmake sync-db\n```\n\n- Run application\n```bash\ncd ./apps/{app} \u0026\u0026 go run .\n```\n\n## Tools\n\n### Swagger\n\nTo generate swagger from the code comments `swag` should be installed locally:\n\nInstallation instruction could be found [here](https://github.com/swaggo/swag#getting-started)\n\nTo run swagger regeneration:\n\n```bash\n  make swagger\n```\n\n### Linters\n\nThe following tools should be enabled in your IDE:\n\n- ```goimports```\n- ```golangci-lint```\n\n\n#### Other systems\n\nCheck [this link](https://plantuml.com/graphviz-dot)\n\n## Architecture\n\nThe project should be readable, extendable, and flexible. In order to achieve it will follow the layered architecture\napproach with the following layers:\n\n```\n┌────────────────────────────────────┐\n│  Application/Infrastructure layer  │\n├────────────────────────────────────┤\n│           Service layer            │\n├────────────────────────────────────┤\n│        Domain objects layer        │\n├────────────────────────────────────┤\n│          Data access layer         │\n└────────────────────────────────────┘\n```\n\nThe approach above is a modification of\nthe [Fowler's multilayer presentation domain application layering](https://martinfowler.com/bliki/PresentationDomainDataLayering.html):\n\n![presentation domain layering from Fowler's post](https://martinfowler.com/bliki/images/presentationDomainDataLayering/all_more.png)\n\nwith the following differences:\n\n- Presentation layer is renamed to Application/Infrastructure layer to better reflect its nature\n- Data mapper layer is absent because data mapping is done by Go's ```sqlx``` library with struct tags\n\nIt is important to follow Fowler's advice and split the project into domain-oriented sub-modules:\n\n![domain oriented sub-modules from Fowler's post](https://martinfowler.com/bliki/images/presentationDomainDataLayering/all_top.png)\n\nIt is important to keep a finite number of building blocks used in the codebase on the lower level of abstractions. The\nmost typical examples are:\n\n- entities\n- repositories\n- services (Ihor: I want to try using commands as service actions because they provide a high level of isolation and are\n  easy to maintain because there is no order for input parameters)\n- errors (we should make sure to properly map them in the API, each error should have its own human-readable code,\n  see [Stripe API](https://stripe.com/docs/error-codes) for example)\n- validations (should be as granular as possible)\n- events (should be used to link pieces of code where the lowest level of coupling is expected)\n\nIn order to make project-level communications easier, the codebase should be built with domain-driven design principles\nin mind.\n\n## Structure\n\nIn order to satisfy the architecture outlined above, the project structure should be the following:\n\n```\ncasper-middleware\n├───apps                          The apps directory contains applications    \n│   └───sample-app                An application is a piece of code that has a single function. \n│       ├───resources             It can have its own resources like configuration, secret keys, etc. \n│       │   ├───config.go         \n│       │   └───etc                  \n│       ├───etc                   It can contain infrastructure code in subpackages or files.\n│       ├───etc.go                It can use one or more domain packages defined in the internal directory\n│       ├───main.go               It always has an entry point\n│       └───README.md             It always has a README file\n│   \n├───infra                         The infra directory contains infrastructure-related files\n│   ├───docker                    It can be Docker files\n│   ├───terraform                 or Terraform scripts\n│   └───etc\n│\n├───internal                      The internal directory contains domain logic packages. It could be called \n│   └───sample-domain-package     domain or business-logic, but internal may be a better name for a Go project\n│       ├───entities              A domain package has an entities directory that contains managed domain entities\n│       ├───events                It can have an events directory for domain-specific events\n│       ├───errors                It can have an errors directory for domain-specific errors\n│       ├───repositories          It has n repositories directory with, well,  repositories\n│       ├───resources             It can have a resources directory with database migrations, etc\n│       │   └───migrations\n│       ├───services              It has a services directory with services that describe available \n│       │   ├───service-one       domain-specific actions. Which can be grouped by a service name or \n│       │   ├───service-two       can be listed directly in the directory for smaller packages\n│       │   ├───...\n│       │   └───service-n\n│       ├───validations           It can have a validations directory with validations that return domain errors\n│       ├───etc\n│       └───README.md             It always has a README file\n│\n├───pkg                           The pkg directory contains \"third-party\" utilities needed by the project\n│   └───sample-utility-package    Such packages don't expose any domain logic and theoretically can be open-sourced\n│       └───README.md\n│\n└───Makefile                      Makefile represents singe entry for the project-related commands\n```\n\nPlural names were used for higher-level packages to have a possibility to reuse singular names in the code.\n\nThe structure shouldn't be considered final and should evolve together with the project.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmake-software%2Fcasper-dao-middleware","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmake-software%2Fcasper-dao-middleware","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmake-software%2Fcasper-dao-middleware/lists"}