Skip to content

Instantly share code, notes, and snippets.

@Igmat

Igmat/TASK.md

Last active October 20, 2021 13:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Igmat/0a4e9ae7748472fb2a83af019f3d5f76 to your computer and use it in GitHub Desktop.
Save Igmat/0a4e9ae7748472fb2a83af019f3d5f76 to your computer and use it in GitHub Desktop.
Download ZIP
Task for cheqd
Raw
TASK.md

Task 1

Node data

  1. Moniker: ghash-cheqd-test-node
  2. Node ID: e9e5ce55ab734e96f9f1523757f7349c97bb2beb
  3. IP address / DNS name: 213.134.163.234
  4. Using screenshots (5 max.) one two three

Questions

  1. I would like to understand architecture better. What are the parts of cheqd-node code, how do they relate to each other, third-parties and what are their responsibilities. May be even visualize dependecy tree for that matter.
  2. Can we create output stream of data that provides meaningful information about what is going on in node. In combination with existing jsonrpc data it could be used to create UI app with live updates and abilities to manage node or even pool of nodes.

    Even developers love fancy UIs;)

Suggestions

  1. Even though Windows isn't commonly used as an OS for this type of software it might be useful in a scenario when developer just wants to quickly check cheqd-node. But, unfortunately, WSL doesn't start with systemd by default which causes some problems with using it. Docker also uses WSL by default on Windows. So it might be useful to make some adjustments into code and/or documentation.
  2. Installation guide for docker distribution doesn't include any information about commands and args. It probably should point to step from deb package installation guide as it is done in Binary installation manual.
  3. You might consider adding command/script for having one-liner for setting up and running node in testnet. It might be useful for newcomers that just want to try cheqd-node before deeper dive.

    Developers are lazy too;)

  4. It also might be useful to have an ability to see is node idle or it tries to check existing blocks (and how many).

    Checking latest_block_time and latest_block_height isn't so convenient

  5. cheqd-noded often stops/crashes silently. It'll be better to have meaningful feedback, especially for cases like No disk space available.

Task 2

1. Describe an overview of how you would architect and build a web/mobile app that satisfies the criteria.

For this task I'm assuming web application to simplify answers, but mobile app won't differ much: mostly in front-end technology stack, while basic principles will stay the same.

1.1 What architectural components/modules do you imagine this app would need?

  1. Frist of all, we need actual blockchain network. We can assume that end-user will install local cheqd-node or be able to connect to existing node that isn't provided by us, but it seems to dramatically narrow user-base. So we should deploy "central" cheqd-node at least. It'll be better to have some cloud-based pool of such nodes for better scalability and reliability. Actual architecture of such infrastructure with load-balancers, VMs, storages, etc. is another big topic. For simplicity let's assume that we have publicly available central node.
  2. We need something to deliver our web app (which consist of some static files). It could be as simple as GH pages, S3 bucket or Azure Storage. At the end we have static file web server.
  3. Since we already use some cloud-like (it can use our own servers if needed) infrastructure, it might have sense to have application server there too in order to perform some more complex work or provide additional features that don't use blockchain directly. Proxies, DBs, cache, buses, etc. should be added according to needs.
  4. Client application parts:

    1. Domain models: Blockchain State, Transaction (+ Collection of), Account (+ Collection of), Delegator (+ Collection of), Validator (+ Collection of), Block (+ Collection of), etc.

    2. Layer for reactive synchronization of models with actual blockchain state (could be FRP or OORP)

    3. App composer: could be as simple as component that includes needed parts, or as complex as IoC-container. Anyway its only responsibilite to compose full app from parts.

    4. Reactive router: selects proper self-contained component based on browser location

    5. Actual self-contained components:

      1. Dashboard (depends on Blockchain State)
      2. Transaction Search Page/Bar (depends on List of Transactions)
      3. Transaction Page (depends on Transaction)
      4. Account Page (depends on Account)
      5. Delegator Page (depends on Delegator)
      6. Validator Page (depends on Validator)
      7. Block Page (depends on Block)

      and others

    6. Building blocks without dependecies on domain models (or UI-kit):

      1. Generic Chart component
      2. Link
      3. Button
      4. Input

      and others

    7. Some other parts if needed for other features

1.2 What tech stack would you use and why?

It depends on a lot of factors, including familiarity with tech stack of existing developers and amount of developers that could be hired with such knowledge, including their cost, availability and length of onboarding process. Since I'm not aware of existing constraints I'll follow with widely spread, up-to-date and preferably OpenSource solutions.

  1. Kubernetes - to avoid vendor-lock on cloud provider.
  2. AWS/Azure/Others - doesn't matter in terms of technical solutions, so should be selected by price.
  3. If needed Rust/Go for App Server, since it's already used in other cheqd products or node.js+TypeScript, since developers familiar with technology anyway will lend into company sooner or later for developing web applications. Each technology has their own pros/cons in this field, that should be taken into consideration before making final decision.
  4. If needed Swagger (OpenAPI) or GraphQL for App Server to provide better documentation and use code-generation tools.
  5. TypeScript - typechecking reduces amount of bugs with tiny overhead and allows to create better API for other developers.
  6. babel - for compiling JS, faster then TypeScript default compiler and has better interoperability with other tools, like webpack/parcel/etc.
  7. React - one of the most popular frameworks nowdays. Has its own downsides, but there are no objectively better solution with comparable community. (Angular or Vue aren't worse but also they aren't better).
  8. MobX - good and popular tool for designing Domain Models.

    Could be replaced with thin wrapper around RxJS if FRP is preferable.
    Could be replaced with home-grown tool like metaf-react. It may allow easier and more efficient implementation of reactive synchronization layer, but will require a little bit more maintenance.

  9. Code generation tools like swagger-codegen to avoid mistakes/typos/bugs when interacting with node from browser.

    Could be easily replaced with fine-tuned homegrown script. In this case it also could be used for autogenerating mocked node with mocked responses - very useful for testing purposes.

  10. LESS/SASS + React scoped CSS - for encapsulated and reusable styling.

    Could be replaced with something more popular like styled-components/CSS modules.

  11. Jest for testing. Existing popular test-runners doesn't differ much, probably except Jest support for snapshot testing which proved to be very useful in certain scenarios.

    I would love to suggest my own testing library:) But it doesn't have community, so not an option at the moment.

  12. (Optionally) some UI library like material-ui
  13. (Optionally) libraries for charts like react-charts or d3.js
  14. (Optionally) libraries for grids like ag-grid

1.3 What would be the simplest way to test out a proof-of-concept of your approach?

  1. Run local cheqd-noded and CRA dev-environment that points to is as back-end.
  2. Create actual UI app.
  3. Deploy one node to cloud and configure public address to it.
  4. Deploy static built UI app that point to node from previous step to cloud or even GH pages.
  5. Proceed with configuring infra by Kubernetes.
  6. Proceed with App development.

2. Additional questions (you can choose to answer all or only select ones you have thoughts about):

2.1 What questions or considerations would you investigate to test the viability of your approach (even if you didn’t have all the answers/context at this stage)?

  1. Existing team-members' knowledge of selected tech-stack
  2. End-users constraints
  3. End-users existing preference for such software
  4. Possible caveats of node depolyment to cloud or some Kubernetes constaints
  5. Actual need for App Server and/or some Proxy
  6. Ability to generate client code for interacting with a node

2.2 What assumptions did you make in your answer above?

I tried to point my assumptions in answers themselves.

2.3 Given more time, do you have any ideas already on how you would improve your idea?

  1. It requires more details for infrastructure architecture.
  2. UI app architecture could also be deepened by making more precise and granular description of components needed, which also coud be visualized as wireframe.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment