Arch is a set of microservices that work together and offer generic functionality for the closed and secure network that is your distributed application. It is effectively a user control suite for the world of microservices.

Each API is its own vertical and offers a specific generic function:

• Application Api: Secures the network and authenticates each microservice in it, including your application and any custom APIs.
• Keys Api: Provides secure storage for secret data such as encryption keys, connection strings, and so forth.
• Tokens Api: Manages temporary tokens that can be delivered and referenced outside the application. Useful to prevent leaking of actual ID values.
• Email Api: Communicates with the configured transactional email provider through a consistent interface.
• Users Api: Manages user accounts and facilitates the zero-knowledge authentication protocol. Supports registration, login, logout, authorization, primary email management, email verification, email abuse reporting, password changes, password recovery and resets, and account deletion.
• Comments Api: Provides a facility for threaded conversations on an arbitrary entity.
• Entity Api: A generic API for storing entity data. Supports versioning and archiving.
• Files Api: A generic API for storing files. Supports encrypted stream delivery for all files and caches small files in memory for fast delivery.

The above set of APIs support common functionality in most applications and are available as the starting set of APIs in Arch.

A common stack of functionality is supported by each microservice. That stack offers very important features and feedback that allow each microservice to deliver the robust service that is expected of it in a distributed world.

This horizontal functionality is available to every API where it makes sense:

• Microservice: Supports the development of a microservice on Arch.
• Authentication: Allows each microservice to authenticate with the Application Api.
• Encryption: Allows each microservice to use encryption techniques that are available in Arch.
• Enveloping: Allows each microservice to use enveloping techniques that are available in Arch.
• Database: Presently only Sql Server is supported. In the future, as additional databases are supported, each microservice will be able to use them instead.
• Logging: All actions are written to a structured log that you may send to a logging system for viewing, tracing, and alerting.
• Resilience: Communication across microservices can experience temporary faults. Resiliency allows for automatic recovery in the case of a transienet fault.

In the world of distributed applications and microservices, all of the above functionality would be written again and again and again for each new application. Arch has all of this built to high quality production standards already so that you don't have to waste time on what is effectively a development chore. When you develop on Arch, you save time and money on the basics, and can therefore focus on what truly matters -- your application.

Saga patterns allow for management of distributed transactions across the network. They can also be used to shape traffic paths and manage flows, including branching flows, and this itself is a form of valuable business logic and architecture.

Arch is being designed to support saga patterns out-of-the-box. Although there is no transaction code as yet, each API does offer full CRUD functionality, allowing you to write your own orchestrator. In the future, we aim to support orchestrated and choreographed transactions across each microservice with event bus and pub/sub support.