github.com/simpleiot/simpleiot@v0.18.3/docs/ref/vision.md (about)

     1  # Vision
     2  
     3  This document attempts to outlines the project philosophy and core values. The
     4  basics are covered in the [readme](../../). As the name suggests, a core value
     5  of the project is simplicity. Thus any changes should be made with this in mind.
     6  Although this project has already proven useful on several real-world project,
     7  it is a work in progress and will continue to improve. As we continue to explore
     8  and refine the project, many things are getting simpler and more flexible. This
     9  process takes time and effort.
    10  
    11  > “When you first start off trying to solve a problem, the first solutions you
    12  > come up with are very complex, and most people stop there. But if you keep
    13  > going, and live with the problem and peel more layers of the onion off, you
    14  > can often times arrive at some very elegant and simple solutions.” -- Steve
    15  > Jobs
    16  
    17  ## Guiding principles
    18  
    19  1. Simple concepts are flexible and scale well.
    20  1. IoT systems are inheriently distributed, and distrbuted systems are hard.
    21  1. There are more problems to solve than people to solve them, thus it makes
    22     sense to collaborate on the common technology pieces.
    23  1. There are a lot of IoT applications that are
    24     [not Google](https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb)
    25     scale (10-1000 device range).
    26  1. There is significant opportunity in the
    27     [long tail](https://www.linkedin.com/pulse/long-tail-iot-param-singh) of IoT,
    28     which is our focus.
    29  1. There is value in custom solutions (programming vs drag-n-drop).
    30  1. There is value in running/owning our [own platform](https://tmpdir.org/014/).
    31  1. A single engineer should be able to build and deploy a custom IoT system.
    32  1. We don't need to spend excessive amounts of time on operations. For smaller
    33     deployments, we deploy one binary to a cloud server and we are done with
    34     operations. We don't need 20 microservices when one
    35     [monolith](https://m.signalvnoise.com/the-majestic-monolith/) will
    36     [work](https://changelog.com/posts/monoliths-are-the-future) just
    37     [fine](https://m.signalvnoise.com/integrated-systems-for-integrated-programmers/).
    38  1. For many applications, a couple hours of down time is not the end of the
    39     world. Thus a single server that can be quickly rebuilt as needed is adequate
    40     and in many cases more reliable than complex systems with many moving parts.
    41  
    42  ## Technology choices
    43  
    44  Choices for the technology stack emphasize simplicity, not only in the language,
    45  but just as important, in the deployment and tooling.
    46  
    47  - **Backend**
    48    - [Go](https://golang.org/)
    49      - simple language and deployment model
    50      - nice balance of safety + productivity
    51      - excellent tooling and build system
    52      - see
    53        [this thread](https://community.tmpdir.org/t/selecting-a-programming-language/98)
    54        for more discussion/information
    55  - **Frontend**
    56    - Single Page Application (SPA) architecture
    57      - fits well with real-time applications where data is changing all the time
    58      - easier to transition to Progressive Web Apps (PWA)
    59    - [Elm](https://elm-lang.org/)
    60      - nice balance of safety + productivity
    61      - excellent compiler messages
    62      - reduces possibility for run time exceptions in browser
    63      - does not require a huge/complicated/fragile build system typical in
    64        Javascript frontends.
    65      - excellent choice for SPAs
    66    - [elm-ui](https://github.com/mdgriffith/elm-ui)
    67      - What if you never had to write CSS again?
    68      - a fun, yet powerful way to lay out a user interface and allows you to
    69        efficiently make changes and get the layout you want.
    70  - **Database**
    71    - SQLite
    72      - see [Store](store.md)
    73    - Eventually support multiple databased backends depending on scaling/admin
    74      needs
    75  - **Cloud Hosting**
    76    - Any machine that provides ability run long-lived Go applications
    77    - Any MAC/Linux/Windows/rPI/Beaglebone/Odroid/etc computer on your local
    78      network.
    79    - Cloud VMs: Digital Ocean, Linode, GCP compute engine, AWS ec2, etc. Can
    80      easily host on a \$5/mo instance.
    81  - **Edge Devices**
    82    - any device that runs Linux (rPI, Beaglebone-black, industrial SBCs, your
    83      custom hardware ...)
    84  
    85  In our experience, simplicity and good tooling matter. It is easy to add
    86  features to a language, but creating a useful language/tooling that is simple is
    87  hard. Since we are using Elm on the frontend, it might seem appropriate to
    88  select a functional language like Elixir, Scala, Clojure, Haskell, etc. for the
    89  backend. These environments are likely excellent for many projects, but are also
    90  considerably more complex to work in. The programming style (procedural,
    91  functional, etc.) is important, but other factors such as
    92  simplicity/tooling/deployment are also important, especially for small teams who
    93  don't have separate staff for backend/frontend/operations. Learning two simple
    94  languages (Go and Elm) is a small task compared to dealing with huge languages,
    95  fussy build tools, and complex deployment environments.
    96  
    97  This is just a snapshot in time -- there will likely be other better technology
    98  choices in the future. The backend and frontend are independent. If either needs
    99  to be swapped out for a better technology in the future, that is possible.