Apidays India

Discover the benefits of CDD in your organization

Embrace CDD with confidence. Our 2-week Proof of Concept lets you experience how it fits your business, removes bottlenecks, and accelerates your time to market.

Here's what your business will gain

The consultation aims to address any questions while demonstrating the potential of independent development and deployment with CDD to empower your business to achieve faster, more confident, and efficient software development practices.
Sign me up Now →

Increased Pace​

Embrace parallel development, slash cycle times, and deliver products to market faster than ever before.

Enhanced Confidence​

Integration issues are minimized as the project goes through integration testing, ensuring a smoother and more reliable process.

Ease of Implementation

Our Proof of Concept simplifies the process, allowing you to grasp CDD’s implementation intricacies with ease

In-Depth Understanding

Our hands-on experience equips your business with insights to navigate the world of Contract Driven Development effectively

What we offer

A proof-of-concept implementation of CDD, at both a code and practice level. Over 2 weeks (10 working days) your team will be guided through the fundamentals of implementing CDD. This includes:

Contract Test

The provider using their OpenAPI Spec and stubbing out provider’s dependencies using OpenAPI or AsyncAPI specs of the dependent services. Also, if required we can stub out Redis, ElasticSearch and database via JDBC.

Intelligent Service Virtualization

Of the provider using the same OpenAPI spec, so that we can component test the consumer.

Central Contract Repo

With pull/merge request process to enforce necessary backward compatibility checks and linting to ensure high quality specs.

Continuous Integration

Pipelines setup with hard-gates on provider, consumer and central contract repo

What will you need to get started

Definition of Ready: A few components / services / APIs that are representative of your overall technology stack. A few members of your team (part time) who are SMEs on these services to help drive the proof of concept with us. Following is the criteria for selection of components and services.

Representative Functionality

Select a functionality that cuts across your view.js front-end and Spring Boot backend as a representative functionality of your technology stack.

Multiple Dependencies​

Backend service should have one or more http service dependencies, database dependency, etc. so that we can demonstrate all the concepts clearly.

Keep It Simple​

Not overly complex so we can ensure we are able to complete the POC within the stipulated timebox.
Sign me up Now →

POC Programme Overview

Meet our hosts and check out the schedule for this two-week hands-on workshop

Naresh Jain

Founder, CEO
Headshot of Hari Krishnan

Hari Krishnan

Co-founder, CTO
Headshot of Joel Rosario

Joel Rosario

Co-founder, Chief Scientist
Headshot of Jaydeep Kulkarni

Jaydeep Kulkarni

Principal Architect
2 Week Overview
  • Get applications running locally with / without mocking dependencies
  • Complete functional overview and rough architecture diagrams
  • Get applications running on local machine
    • Isolate dependencies – Dockerise, In-memory DB, Queues, etc.
    • Switch off cross cutting concerns – Authentication, Caching, etc.
  • Automated inventory of routes, routes in API specifications, correctness of API specifications with actuator integration
  • CI pipelines and version control overview
  • Record observations, challenges faced
  • Select a route that has API specification / can be generated with Specmatic
  • Provider
    • Run the specification for that route as a test on the Provider on local machine
    • Run generative tests and observe any breakages
  • Consumer
    • Run existing UI Component Test / Write one for the related interaction
    • Stub the backend with the same API specification that was run as contract test
  • Attempt running both of the above test setup on their respective CI pipelines
  • Create a fresh Git Repository
  • Push the API specification we used above into this repository
  • Reference the same on both Consumer / FE and Provider / BE applications and make sure they are working in CI pipeline also
  • Pre-merge hook setup
    • API Specification Linter Setup – Standard OAS ruleset with minor upgrades where necessary
    • Specmatic Backward compatibility testing setup
    • Merge policies
      • Block until linter and backward compatibility pass
      • Test the setup with breaking changes in both syntax and content
  • Branch policies
    • Disallow direct merge to master
    • Require minimum number of reviews
    • Pre-merge checks to pass
  • Generate / Record API specifications with Specmatic
  • Review and update the recorded API specifications with respective service owners
  • Strive to reach 80% plus branch coverage independently with Contract Tests alone
  • Agree on API conventions – naming, response codes, headers, etc.
  • Automate the same with Linter that we setup earlier on central contract repository with custom rules
  • Take stock of API design improvements
  • Provider – Analyze Specmatic generative test failures and prepare detailed report
  • Consumer – Fault simulation (empty & error state, timeouts, etc.) with Specmatic stub
  • Analyze asynchronous interaction such as Kafka, JMS, etc.
  • Stub these with Specmatic AsyncAPI support to verify schema compatibility and more
  • Run the AsyncAPI specifications as test where application
  • Examples: Redis, JDBC, etc. wire compatible stubbing to improve isolation of application in local and CI while running tests
  • Detailed demo with your team members themselves presenting the work they have been able to do
  • Specmatic team sharing their observations and recommendations with detailed action plans
  • Decide on next steps

Sign Up for a 2-Week POC Consultation