Introduction

Tramway adds a level of abstraction when it comes to data source with the aim of making it plug and play.

The persistence layer is generic thanks to the introduction of a Provider class. This means a Tramway application can exist with or without one on the basis that an application that doesn't have a database could still call another API and treat the data in the same manner.

The way the application models the data is handled by a Repository class, which won't necessarily know the implementation details of the provider, making it relatively simple to change data providers as needed.

One common application of this abstraction would be the introduction of a Provider that balances between 2 databases such to have a primary and a cache. The underlying implementation of this Provider will try to get an item from the cache and fall back to the primary data source. As far as the Repository is concerned, the data returned by the Provider is the same raw data it needs to model and create entities. As such, if the need for a caching layer arises later in the lifetime of an API, it will just require a basic toggle logic that can then be injected via Dependency Injection - as opposed to rewriting the Repository and trying to re-do data logic for the sake of adding a caching layer.

Another application of this abstraction is in a more sophisticated application wherein there is a microservice architecture and the persistence layer of one a business-tier API makes more sense to be abstracted to its own data-tier API that can be used by multiple business-tier services. Instead of sharing a database between these microservices which risks the integrity of your data, your business-tier services would make an API request to the data-tier API that manages the data - this way you can keep a strict control over the data model without starving your front-line services or compromising its integrity.