/
Atria - Development Strategies

Atria - Development Strategies

Compartmentalize

The Hardware Platform Atria will be an extensible application used at all levels of the Milvian Hardware Team’s install, monitoring, and provisioning processes for Aqueduct or the LoRaWAN Platform.

This means that consideration of homogenaity from one application to another functionally should be a low-priority consideration.

If there is a question about how we might refactor an existing element to support new functionality, but doing so would complicate the process of updating and supporting both use-cases, we should instead duplicate and comparmentalize the functionality of the former product and mold it into what suits the needs of the new use-case so that there are no interuptions of secured functionality, and the new functionality can be maintained on its own.

General rule: treat the different Apps within the Platform as sister applications, but separate applications. Do not tangle them.

Keep it Simple

We’re going to keep the infrastructure pattern simple in most use-case scenarios. This will mean that we stage the following pattern in the majority of cases.

Client > API Gateway > Lambda > [Resource]

The [Resource] can be DynamoDB, S3, Cognito, literally anything in AWS. This will be the general rule for how infrastructure is compartmentalized and relates to the Front-End

Follow the Flow

UserFlow should always take the user thusly:

Login → Landing Page with App Selection → Page of Purpose

Frontend-First

The User of the Platform is the highest priority, so when we begin our work on a new feature, we must consider the functional experience of the end-user, ad plan our infrastructure to meet the needs of the client.

Do not expect the client to care about how the backend functions.

UX/UI

  • Follow the Style Guide to make applications look similar.

  • Always build from the mobile view first.

  • Use WaveLoading.jsx for pages that take over 300ms to load.

Code Quality Guidelinesuidelines

  • Avoid unnecessary comments; write self-documenting code.

  • Do not log internal errors to the client. Use secure and private server-side logging instead.

  • Use clear and descriptive variable names.

  • Do not use reserved keywords.

  • Avoid generic names like temp, foo, bar, unless contextually appropriate.

  • Always address deprecation warnings in code and documentation.

  • Run npm audit fix --force to address vulnerabilities.

  • Fix syntax and linting issues before committing.

  • Keep files < 1000 lines.

  • Refactor large files into modular components, grouped by purpose.

  • Use clearly named directories to organize related functionality.

  • Keep the workspace tidy and logically organized.