Working with APIs Challenge
Flatten the Cost-of-Change Curve in Software Development!
"Has this ever happened to you?
You need to interact with an online store through APIs.
To do that, you create a new module, and new code to connect, get authorized, interact, validate responses, handle exceptions, etc.
Then, you need to interact with a payment server through APIs.
To do that, you create a new module, and new code to connect, get authorized, interact, validate responses, handle exceptions, etc.
After that, you need to interact with another payment server through APIs! And guess what...
To do that, you create a new module, and new code to connect, get authorized, interact, validate responses, handle exceptions, etc.
Are you ready to stop this form of primitive programming?" —Francesco Cirillo
In this four-session software design challenge, Francesco Cirillo shows how to develop a real use case by interacting with different APIs of various services.
Challenge Content
This Challenge is organized in four sessions.
SESSION 01 - INTERACTING WITH THE FIRST API IN TDD
Interacting with an online service through its APIs.
- Presentation of the User Stories, Scenarios and Requirements.
- Definition of criteria to evaluate the effectiveness of software design.
- Development of the software feature to retrieve orders for a certain group of "products" on the online store.
- Assessment of alternative and exceptional cases.
- Generate a simple list of booked dates.
Session 02 - NEW ABSTRACTIONS EMERGE TO DEAL WITH THE SECOND API
Finding abstractions that enable access more than one API
- Spike: Accessing the Google Calendar.
- Spike: Create new events.
- Spike: Do events already exist?
- Dynamic differences and similarities in connection interactions.
- Dynamic differences and similarities in communication interactions.
- Connect and communicate with the second API in TDD with the objects of the first API.
- Evaluation assessment of the current software design.
Session 03 - NEW POWERFUL ABSTRACTIONS EMERGE TO DEAL WITH THE THIRD API
Is the software system becoming simpler?
- Spike: Send emails via an online API.
- Spike: Send emails programmatically.
- Spike: Has the email been opened?
- Dynamic differences and similarities in connection interactions.
- Dynamic differences and similarities in communication interactions.
- Send emails to the attendants of Mentoring sessions!!
- Evaluation of the current software design.
Session 04 - VALIDATION AND EXCEPTIONAL FLOWS TO SIMPLIFY OUR DESIGN
Making the use case workflow simple.
- Make a list of alternative and exceptional cases.
- Differences and similarities between the various services.
- Develop some exceptional cases in TDD.
- Evaluation of the result.
About this Challenge
The Working with APIs Challenge is a Course where
Francesco Cirillo develops a feature to improve his back office Mentoring service.
Francesco wants in his Mentoring service as such:
- Every day the software system checks if there are new orders related to Francesco's Mentoring sessions.
- For every new order the system automatically creates an event on Francesco's Google Calendar.
- Automatically send an email to the attendant.
- Update a Google sheet with info about the new order to simplify the accounting.
In order to do this, the software needs to interact with several external systems via their APIs: Francesco’s Online Store, a specific Google Calendar, a Google Sheet and an EmailManager APIs.
Course Info
Format
Live: 4x2 hour sessions (max 8 participants) over two weeks.
Video: 30 breakdown sessions for a total of 8 hours.
Language
English
Delivery Options
Live online, onsite, in-house, recorded video.
Trainer
Francesco Cirillo
Is this training for you?
This Course is ideal for Software Developers and Technical Coaches.
What do you need for your training?
No previous knowledge is needed. Much passion is required!
Join the conversation
Are you interested in asking questions, clarify specific aspects of the Challenge, or share your solution? The Working with APIs Challenge Community is the place for you.
Certificate of attendance
This Certificate is delivered to all the participants who have attended the four sessions of the online course.
Objectives
As a result of this course, you will learn to:
-
Develop objects that can be reused to interact with the various services.
-
Validate data being sent and received from different services by reusing the same objects.
-
Control and adapt the workflow related to the use case.
-
Keep the complexity of the software system low. (>>Flatten the Curve!<<)
The Story Behind this Challenge
This challenge stems from a real situation.
For a few months, I worked in a start-up.
Their product was very simple.
The system retrieves input data from a number of external systems through their APIs,
applies rules, performs calculations and sends its output to other systems through their APIs.
Basically, a simple IPO (Input Process Output) with the use of APIs.
From a business point of view, expanding the startup meant accepting new and different external systems to retrieve data from and possibly new external systems to send data to.
But it that start-up, accepting any new external system meant writing a new module from scratch:
- The code to connect and be authorized by the external system.
- The code to interact with the external system via API.
- The code to validate the information received from that system.
- The code necessary to deal with exceptional flows that could happen in the interaction with that system.
This happened not only for two seemingly different system APIs, for example, an online payment service and an online store. But it also happened for two similar external systems (two payment services).
Consequences
As the business expanded:
- The number of lines of code grew
- The complexity of lines of code grew over time.
- The number of bugs increased.
- The time to deliver the functionality increased (indefinitely=never ending stories).
- A demand to hire more developers increased.
- The need to divide up the work in a specialised way (waterfall style) grew.
Poor software system!
You might argue...
“Francesco, the API of every external system offers a different way to interact! APIs are different, shouldn't we handle them as necessary?”
Francesco’s short answer: "NO!"
What's the benefit of software design?
The idea behind software design is to find a number of objects that can be put together in order to develop ALL the interactions with very different APIs of any possible external system!
It is possible to apply the same reasoning to validation and exception handling.
What are the consequences now that software design is applied?
Consequences (@GoodDesign)
As the business develops:
- The number of lines of code is stable or decreases.
- The software system becomes simpler over time.
- The number of bugs decreases.
- Time to deliver functionality decreases and becomes more predictable (> Flatten the curve<)
- There is no need to hire new developers.
- Developers can work in a despecialised manner.
Ready to program?