How can Servable help your teams be more flexible?

Servable can help your team spread the features your app needs. Imagine you are creating an application with different teams and that provide different features that you can use across the platform or across the entire organization. Usually developers will try to refactor every feature. This does not happened naturally and most of the most of the time it gets engulfed in a technical depth that is hard to resolve because finding the proper time to allocated alongside the new features that should be developed is tough. This is the readon why choosing the right architecture right from the beginning is crucial in order to have a clean, future-proof development.

Extreme refactoring

Coined by Don Wells, Extreme refactoring is a designing rule of the Extreme Programming which is a movement itself, often shortened to its XP acronym. This principle entices teams to refactor whenever and wherever possible:

Refactor mercilessly to keep the design simple as you go and to avoid needless clutter and complexity. Keep your code clean and concise so it is easier to understand, modify, and extend. Make sure everything is expressed once and only once. In the end it takes less time to produce a system that is well groomed.

Image credit: Philippe Bourgeau

Furthermore protocol composition will ease the interdependencies between team, let's say the commentable feature team needs the reviewable protocol, the inline declaration in commentable/target/protocols.json is straightforward.

A clear delimitation of teams concerns

By giving the responsibility of a protocol to a team, you are enforcing a pattern of a team owning a feature in its entirety, at least on the server side. Another architecture that enables this delineation is microservices.

Get the infrastructure out of the feature code

The unique Servable API was built around letting the developers actually provide value to the customer through a feature. It extracts some of the usual concerns when dealing with a server framework at scale:

• Database connection
• Database querying API
• API routes caching and rate limiting routines

A unified API for protocols

#TODO

Servable System Design

#TODO