DEV Community: Christophe Dujarric

Bump.sh included in the GitHub Student Developer Pack

Christophe Dujarric — Wed, 19 Jul 2023 09:24:51 +0000

GitHub Education just announced that Bump.sh is included in their latest Mobile Development Experience.

That brings back some memories...

Our roots in Mobile Development

Five years ago, in a previous venture, we introduced a major issue in a mobile app. It brought the service down for all its users. The root cause? A breaking change in our API that we didn’t identify when releasing to production. That change was part of a much wider product evolution, including database migrations, making it virtually impossible to roll back and bring the service back up fast.

This story probably rings a bell to many.

And that’s precisely the origin of Bump.sh. We realized the lack of actionable API documentation tools, that would assist in identifying changes, and let developers discover, build and consume APIs.

Helping students not reproduce our issues

Today, we’re thrilled to open free access to Bump.sh for all GitHub Students.

The GitHub Student Developer Pack lets students worldwide access a wide variety of professional-grade tools that otherwise wouldn’t be affordable. While learning, they can directly benefit from what will be their day-to-day workspace once they start their career. They can complete student projects through a great developer experience. They can apply everything they learn about, hands-on.

A keystone of API development, whether for Mobile or web apps, is in the specifications such as OpenAPI (ex-Swagger) or AsyncAPI. They make it possible to define a robust contract that tells how to work with an API. We’re fervent advocates of specifications and encourage student developers to discover and learn how to use them early on.

By offering Bump.sh to students, we’re hoping it will assist them in those efforts. Bump.sh indeed generates stunning docs directly from OpenAPI and AsyncAPI contracts. It detects any change in those contracts and can warn a team whenever a breaking change occurs. More: through our GitHub Action, get API docs automatically updated, and decide whether breaking changes should turn your commit status to red.

Read more about what’s included in our offer.

Students, we’ll love to see what you’ll build. We’ll be there if you need any assistance on the road!

Why AvioBook switched from Swagger UI to Bump.sh for all of their APIs

Christophe Dujarric — Wed, 24 May 2023 12:33:38 +0000

Some Words about AvioBook

AvioBook (a Thales Group company) is a software and hardware technology company building a suite of solutions for airlines. Starting with an EFB or Electronic Flight Bag solution for pilots, the suite now includes tools for all stakeholders in flight operations from dispatchers and technicians through to cabin crew and EFB admins.

What is an Electronic Flight Bag (EFB)? Well, you might have that picture of fancy pilots wearing their uniforms in your mind right now. Think about what they have in their hands. See that fancy suitcase? Well, that’s soooo 1960’s. It’s all digital now! And actually, much more powerful. Transform that into a tablet that lets pilots access crucial information in real-time to prepare for their flight, get passengers comfortably and safely to their destinations, and communicate with cabin and ground crew.

About Mano, AvioBook’s CTO

He’s busy but we’ve been very lucky: Mano Swerts, AvioBook’s CTO, found time to answer a few questions.

I’ve been at AvioBook for more than 4 years now. I worked at consultancy firms in the past, switching between a large number of customers and industries. I was drawn to AvioBook as it is a product company with an incredible offering in a unique industry. I joined the company as a Java Tech Lead and was one of the drivers behind the redesign and restructuring of AvioBook’s approach to APIs and API documentation. In my current role, I’m still closely involved in our API strategy, although I'm more focused on how we can bring the power of AvioBook's APIs to our customers.

Organizing teams and APIs, together

The AvioBook product suite is quite extensive. We have several product teams that focus on the development and evolution of our many products. Every team is responsible for a specific part of this suite. Apart from that, we have our managed integrations team that is specialized in building integrations between the AvioBook platform and airline IT systems. They create tailored solutions per customer, leveraging the AvioBook platform APIs to do so.

We had 2 main challenges: during the design phase of our APIs, we needed to make sure that the use cases of all of our internal teams were taken into account. This required a uniform approach to documenting and discussing APIs.

After APIs were implemented, we needed to make sure that all teams were able to easily browse all available APIs and understand how they could use them.

Writing OpenAPI and AsyncAPI contracts

That’s why we started using OpenAPI and AsyncAPI specifications to support both use cases. Here at AvioBook, we started out with a Swagger UI to provide a single place to look for all available APIs. It was a great starting point, but it does have some limitations. The most important ones are not being able to visualize AsyncAPI files and not being able to efficiently host multiple versions of the API contracts.

As a company, we are mainly focused on REST APIs over HTTPS and event-based messaging APIs (with RabbitMQ). REST APIs were our first focus as they have the broadest field of applicability. They can be used to power mobile applications, web portals, but also integration scenarios. As we keep on investing in scalability and increased availability of our product suite, we have started working on a messaging strategy as well, which is mainly suitable for performant and scalable service-to-service integrations.

From Swagger UI to Bump.sh

Using Swagger UI, we weren’t able to easily centralize API documentation for all of our platform versions. With Bump.sh, we can easily do that and show differences between versions of the API.

Bump.sh also allows us to visualize AsyncAPI files in the same consistent manner as our OpenAPI documentation, something we couldn’t do at all with our previous solution.

Probably most important: Bump.sh allows us to expose our APIs to our customers using proper access management features, which is entirely lacking in Swagger.

Bump.sh supports us in providing APIs as a service to our customers, basically allowing us to bring a new platform (APIs) to the market. This is one of our key differentiators. We were already quite unique in the market with our managed integration services. However, enabling our customers to integrate directly through their own processes and current IT systems serves to reinforce our position a leading platform.

It also allows our teams to work together in a more efficient way as there is a single place for everyone to access API documentation.

APIs in the sky, so high

Working with AvioBook has been a blast for us, too. Beyond the fact that we’re indirectly contributing to safe and comfortable flights, our collaboration with the AvioBook engineering teams led us to improve Bump.sh on various aspects, including advanced OpenAPI features support, and improving overall performances of Bump.sh for all users.

Looking for an alternative to Swagger UI? AvioBook can tell better than us.
We're here to help!

Supporting Canopy's API-Led Product Growth

Christophe Dujarric — Wed, 17 May 2023 15:03:19 +0000

Canopy

With Canopy’s API and CanopyOS, Fintechs, banks, and credit unions can improve borrower repayment rates, increase net promoter scores, and decrease the cost of servicing for lending and credit card products.

Sharing part of our history with Canopy

Canopy was founded in 2019 to help Fintechs and banks service customer accounts through automation and flexible APIs.

Bump.sh was already offering its OpenAPI-based API documentation generator, and shared a ride with Canopy, starting summer of 2020. Let us tell you more about it.

In our early stages

Anurag Angara, Head of Product at Canopy, joined their team as the 4th employee and technical product manager.

Back then, Canopy was a fintech technology solution built from developer-centric APIs. It’s still one of their core strengths. As an innovative product and company, one of his key tasks was to understand the lending and credit market.

Leveraging OpenAPI was a smart move to quickly build prototypes that could be shown to potential lending and credit clients and collect their feedback. Its intuitive, language-agnostic nature offered a similar experience to working with mockups and wireframes for a web application. Without having to completely release a product, Anurag could share projected API docs with potential customers.

That’s where Canopy and Bump.sh began working together. Anurag needed to render the OpenAPI contract into shareable, professionally polished documentation. Back then, we already had great support of OpenAPI, and we were precisely working on building a stunning docs UI. Well, we had to start somewhere, and we’re not ashamed to say that Anurag initially sent us a CSS sheet that we integrated to produce the intended styling (yes, it’s much easier than that now, it’s all in our publication UI). It was the start of a great relationship. It’s always, and will always be, crucial for us to be close to our users. And Canopy’s team has been close to us, too.

Bump.sh made things easy. It was pretty much ’set it and forget it’. We’d be sure that our docs would always be up to date, even during our fast-paced development cycles.

Their API docs quickly became a key ingredient of their sales and customer onboarding processes. They could generate those “Aha!” moments whenever Canopy would spin out a branch of their API (each automatically deployed on Bump.sh), to show them what would be possible. It had a direct impact on reaching and closing deals.

Another win? Reducing the time-to-first-API-call. Before using Bump.sh, Canopy used Google Sheets. As much as this is a pragmatic way to get started, automatically generating a user-friendly documentation portal from OpenAPI contracts brought the experience to a whole new level. Additionally, the support of references ($ref, automatically recognized and resolved) and JSON schema by Bump.sh made it t possible for them to maintain, manage, and improve their API schema as their team and product continued to grow over the next three years.

Serving Canopy’s customers today and tomorrow

Canopy started acquiring customers, scaled, and raised a Series A in August 2021. As a direct consequence, their roadmap pace increased. And with it: their need for more automation and the ability to rely on an API reference.

They further developed their public API and used our CLI to completely automate the publication of their latest API changes. No need to log in to our dashboard: everything is under control on their end.

The API doc is now the single source of truth for all of their developers, always up-to-date, and shared in real-time with the customers. And they keep on loving the look of it.

Bump.sh is critical to our stack and workflow.

We’re still regularly having calls, collecting Canopy’s feedback, and figuring out new ways to improve their API’s documentation experience. And with that, supporting them to offer their service to even more teams!

At Bump.sh, our mission is to help teams and companies to step up their API game. We’re right here if you need some assistance on these kinds of projects; feel free to contact us anytime.

Helping Memo Bank deliver APIs & comply with FinTech regulations

Christophe Dujarric — Wed, 15 Mar 2023 15:27:48 +0000

Memo Bank’s journey, so far

Memo Bank was created in 2017 to offer Small and Medium Businesses a banking experience that echoes their needs and challenges. Where traditional banks offer services for larger businesses, and some FinTech make a difference for individuals, the SMB market was poorly addressed.

After a successful exit with the acquisition by Trainline, one of Captain Train’s founders felt from their experience with traditional banks that it was time to break some of the codes by creating a tech-led bank, capable of understanding and serving today’s entrepreneurs.

The first big step was to get their license in June 2020 from the Banque de France (French National Central Bank), allowing them to exercise across Europe.

The service went live a couple of months later, in September 2020, based on a brand new Core Banking System (CBS), fully developed by Memo Bank’s engineering team. Something unique in the industry.

Engineering at Memo Bank

Jérémie Martinez was the first tech Memo Bank employee and grew to lead tech, then Head of Engineering. He’s now leading over 20 people across teams working on the CBS, frontend, Site Reliability Engineering, and data.

Most of our team has learned a lot over the past years, building uncommon expertise in advanced banking and transaction systems, which is scattered across many more individuals in larger, traditional banks.

As you can expect, the banking operations ecosystem is highly regulated and controlled, requiring extremely sharp engineering delivery.

The team loves nothing more than a carefully technically-crafted product and knows how to build it. Jérémie is proud to say that they had no production incident yet and close to no developer turnover.

Where OpenAPI and Memo Bank meet

A cornerstone of Memo Bank’s product and software architecture is its API ecosystem.

Technically, the team has a code-first approach: they generate an OpenAPI definition from the code; not the other way around. Still, it will start with a design phase where they’ll agree upon contracts, even if they’ll directly code it and then document it. They will also continuously verify how the OpenAPI definition renders, to ensure an elegant usage of the solution.

OpenAPI 3.0 lets us automate nearly everything and benefit from all that is developed around this standard.

To produce OpenAPI contracts, Jérémie’s teams use JaxRS: Jersey is used server-side to generate the OpenAPI contract source. That source is used to automatically generate the client’s code using another open-source project, RestEasy.

Wanna know more about their APIs?

A key value proposition for their customers is to let them programmatically pilot their bank accounts and transactions. Salary payments, purchases via wire transfers, collecting money from their customers, and all of that by batch if necessary to gain efficiency and focus on their core business rather than administration. Their public REST API (Published on Bump.sh - surprise!) offers their customers all the flexibility they need. Memo Bank especially leveraged two unique features of Bump.sh: the changelog, and branches support. As their API is versioned and offers backward compatibility, customers can pick the doc version they need, even if they still use an older version after a breaking change for instance.

Beyond their public API, they have a legal duty to produce a partner API following the DSP2 European regulation, to which Third Party Providers connect. Those “TPPs” (for instance Powens and Bridge) role is to ensure secure payments through Strong Customer Authentication. Also built as a REST API, this API’s doc is conveniently centralized with the rest of the catalog on Bump.sh, and its access is restricted to the TPP (Access management? Yup, we got your back).

Because we’ve been super nice lately, Jérémie exceptionally accepted to lift the veil for a moment on their private APIs. The apps’ architecture, as Jérémie says, isn’t exactly structured as “micro-services”. It’s more “macro-services”, per business logic and following a Domain Driven Design approach. And all of those need to communicate! Some of the APIs are in REST/HTTP. Some of them are asynchronous. The choice of event-driven API directly results from the highly regulated and controlled banking ecosystem. An event-driven system empowers traceability: all events are logged and become immutable facts that can be audited. In more detail, there are two event-driven APIs: one for streaming events, using Kafka, and one serving as a “discrete messaging queue”, using ActiveMQ (AMQP). Adopting the AsyncAPI specification and deploying docs with Bump on an internal Hub is currently under exploration by Memo Bank’s engineering team.

Memo Bank treat: integrating Bump.sh and Gitlab

How about that? Memo Bank’s engineering team cooked a little something they’re willing to share (see below): a custom Bump.sh/Gitlab integration that automatically displays a diff at the Merge Request level when they implement new API changes, so that the team can review it easily before merging.

You’ll find here the script that runs in their CI/CD pipeline, for each Merge Request.

And that’s the type of result you can expect if using a similar script:

The way we helped Memo Bank

In all, Memo Bank adopted all of the key features of Bump.sh, with a special highlight on:

Automated generation of elegant documentation. Their public API is a strategic feature in their approach to the SMB market. Bump.sh helped them set up the corresponding public doc very fast, and helps them keep it up to date automatically, for a considerable gain in time and efficiency.
CI integration and change log. For their partner API, the CI integration of Bump.sh supports Memo Bank in mitigating reputation risks (which would happen with uncontrolled breaking changes) and compliance (DSP2 regulation).

Bump.sh plays a key role in helping us publish always up-to-date API documentation. That means more engineering efficiency and better support for our customers, as well as risk mitigation on reputation and compliance.

Some of their favorite Bump.sh perks? The ability to set a custom domain, the stunning design (including the dark mode), the changelog, the versioning and branches, the CLI, the full support of OpenAPI, the automation, and the sections introductions with Markdown support. and beyond the tool itself, they appreciated finding the Bump’s team around the corner whenever they had a question or needed support.