Tech stack, conventions, environments
Languagesβ
To have consistent experience across code repos and due to limitations of teams, we want to limit possible tech stack (at least for now) to these languages:
- Javascript (Typescript)
- React / TSX for frontend
- NodeJS (for low-load BE services)
- Go (for high-load BE services)
- Rust - for embedded devices that need high efficiency and memory reliability
- C++ - for embedded devices, if go & rust are too hard, donβt have good system support etc.
- Rust - for embedded devices that need high efficiency and memory reliability
- Python
- for ML and data-science models. Ex. using
- for early prototypes of a service where ease/speed of integration is important, can be copy-pasted. Ex. video-processing with opencv
Storageβ
For Databases and persistance we use
- MySQL β maybe we could switch to Postgres in the future, but atm lets stick to this
- Redis β for caching & pub-sub
- SQLLite β for edge devices if something needs to be stored for a longer time, but no willingness to mess with a dedicated service
(Cloud) API limitationsβ
For public API we rely on graphql federation, so if you create a microservice, make sure that language and framework supports that.
GraphQL federation allows us to declare schema in a strictly typed format, while keeping services independent.
If youβre worried about standardization of GraphQL schema variations, like pagination standard or global ID pattern then use simple pagination first, complicate it later. For UUID
Frontendβ
We use urql because
- we do not use apollo-client because its heavy in filesize
- we do not use Relay because its very opinionated on types, makes queries too dynamic with its fragments
Edge Devices OSβ
But, you should not care about it that much, because you should write service as a docker container.
- Ubuntu 18 for Jetson Nano with NVidia GPU
- Ubuntu 20 for Jetson Orin Nano with NVidia GPU
Edge devices APIβ
Its not yet fully clear yet.
- Use Protobuf & GRPC. Mostly because youβre not dealing with serving external customers and efficiency is the most important issue
- Use REST API / graphql if service is a hybrid. For example if its a model that runs both on the edge and in the cloud.