Business-friendly library for inter-service communication
Pivorak meetup, Lviv, September 6
Business-friendly library for
- Lead software engineer
at Matic Insurance Services Inc
- We are hiring!
- Contact Iryna Sulatska
- GitHub: antomi
- Medium: @anton.mishchuk
- Share our thoughts about the approaches to
- Discuss in details the library we designed
for the communication
- A little bit of history:
- How did we create a technical dept
- Approaches to inter-service communication:
- API-gateway vs Service Mesh
- REST vs Messaging
- Business-friendly library (BFL):
- One library for the whole platform
- Matic is an insurance agency
- We integrated with ~20 insurance companies
- There are several inter-connected applications
(servicers) inside the Matic platform
- Almost all the services are written using Ruby
Synchronous communication via HTTP REST (JSON)
Sync and Async Communication via HTTP REST (JSON)
More and more services
- Lots of services with heterogeneous API:
- No client libraries (plain JSONs)
- Naming collisions
- Data duplication between services
- It’s hard to make changes and introduce new services
Or a least to make a plan for payments
It’s time to pay the debt
Decisions we had to make
- 1. Topology
- Single communication hub (API Gateway)
- Service Mesh
- 2. Protocol:
- HTTP (sync)
- Messaging (async)
- 3. Client libraries:
- Do we really need them?
- One place for the Platform level
- “Facade” API - API built on top of
- Simple services discovery and
- One single point to integrate with
- Single point of failure
- Hard to debug failures
- Part of business logic is here
- Who is responsible?
- No single point of failure
- All the business logic is inside the
- Easy to debug
- Looks much more complex
- Services discovery and
configuration is in every project
- “Facade” API is not possible
Service Mesh with API Gateway for external requests
- Services discovery and conﬁguration
- “Facade” API
We decided to implement them on “library” level
What about API gateway features?
- One recipient
- Fire and forget
- Many recipients
Final decision - use both
- When you GET smth and expect immediate response
- When you DO smth and expect immediate result
- When you INFORM about smth and
don’t need a feedback
3. Client libraries
- General rule - you must have them!
- No error-prone plain JSON
- The same team develop endpoints and library
- Responsibility of request formation and validation goes
to the team that supports an endpoint
- Documented by code
- There are no drawbacks at all!
- If there are 10 services, there are 10 libraries
- It’s ok, in general
- But what if we put all of them into one single gem?
Single client library. Naive approach
- Just put all code into one gem
- Namespace functionality for each project
- And that’s it
Naive approach problem!
Existing abstractions in our APIs
don’t always correspond to business abstractions!
Single client library. Correct approach!
- Deﬁne platform-level models
- models that reﬂect domain and are common for every (most) service
in the platform: customer, property, lead, quote, policy.
- Deﬁne platform-level actions
- actions that reﬂect domain: “create customer”, “request quotes”
- operate with platform-level models
Сhallenge #1: Proper naming
Some entities have the same name in projects but
actually maps to different domain models:
- Our examples: policy/prior_policy, etc
Think carefully about names for your entities!
Rename them properly.
Сhallenge #2: Data duplication
Some entities are stored in different projects:
- Our examples: customer, property, quotes, etc.
Find a proper place to store entities
Create a separate storage for entities that are used by
Сhallenge #3: API redesign
Redesign API endpoints for most of the projects
- After all changes mentioned above existing API becomes obsolete
- Just do it!
- Data structures with validation and serialization
- Deﬁnes attributes
- The way of validation (include ActiveModel::Validations)
- The way of serialization (include ActiveModel::Serializers::JSON)
- Can be reused in the projects
- Validation before actual request
- Wrap HTTP GET requests
- For fetching information from services
- Examples: GetProperty, ListPeople, etc.
- Wrap POST/PUT/DELETE requests
- For data creation and modiﬁcation
- Examples: CreateProperty, RequestQuote, etc.
Actions. Statements (events)
- Wrap asynchronous communication
via Message queue
- Information messages that are broadcasted
on the platform level
- Consumed by any interested subscribers
- Example: PropertyChanged, QuoteFound