Improved API Portal Design

​

We completely refactored the design and look of our API Portal to be more modern, sleek, and intuitive. Take a look at the screenshots below to see the improved design. We also added generated response examples and ergonomic improvements when navigating between pages in the portal. See a full list of changes in the "Improvements and Fixes" section below.

Refactored SDK Documentation​

We now allow you to brand your README.md with a banner image using the new readmeHeader property in your konfig.yaml file like so:

This generates READMEs with your image and title at the top of the file like so:

We completely overhauled the generated documentation for Python and TypeScript to be easier to read and find what you're looking for.

We also plan to improve the generated documentation for other SDKs.

Dart​

Konfig now supports generating Dart SDKs! This means that you can now use Konfig to generate SDKs for your customer's Flutter applications or Dart projects.

Generated Python Snippets​

Konfig's API Portal now seamlessly integrates your Python SDK into the API Reference Page. This means that you can dynamically generate Python code snippets that can be easily copy-pasted for lightning-fast integration in Python. This is the second of many SDK languages that we will be integrating into Konfig.

Improved API Portal Styling​

We made improvements to the styling of the API Portal. The API portal now has rounder edges and denser styling to make it easier to read and navigate. We also made the navbar on the left side smaller to give more room for the core content on the page.

Markdown Pages​

We are excited to announce the release of Markdown Pages! This feature allows you to create a custom documentation page for your API / SDKs. You can use markdown pages to provide examples, links to external documentation, or any other information you want to share with your users. Konfig's markdown pages are fully integrated with the rest of the portal, so you can easily create links to API endpoints or interactive demos.

Currently, we are deploying with a few early customers. If you are interested in trying it out, please reach out to [email protected].

We are excited to announce the launch of our newest product at Konfig!

Introducing: API Reference

​

The Problem​

The next step after generating SDKs is adding them to your docs. But as soon as you do, something feels off. Your API reference is not integrated with your SDKs and you have to maintain two separate pages. You manually copy-paste code snippets from your SDKs to your docs and you have to update them every time your API changes. So we created a better way.

The Solution​

Introducing API Reference by Konfig. It's a single page that combines your API reference and SDKs. It's automatically generated from your OpenAPI spec and SDKs. It's always up-to-date and it's always in sync with your API. It allows you to dynamically generate code snippets for your SDKs and make API requests directly from your docs. It's a single source of truth for your API.

Currently, we are deploying with a few early customers. If you are interested in trying it out, please reach out to [email protected].

From DHH shunning serverless, Ahrefs saving millions by using a cloud provider at all, to Amazon raining fire on their own serverless product, serverless has recently faced significant scrutiny.

But still, everyone and their pet goldfish seem to be creating a serverless runtime (see Bun, Deno, Pydantic, Cloudflare, Vercel, Serverless, Neon, Planetscale, Xata, FaunaDB, Convex, Supabase, Hasura, Banana, and literally hundreds more). One research paper from Berkeley even claimed:

Serverless computing will become the default computing paradigm of the Cloud Era, largely replacing serverful computing and thereby bringing closure to the Client-Server Era.

-- Cloud Programming Simplified: A Berkeley View on Serverless Computing

Is it all hype? Is there real 100% objective merit to it? Where does serverless excel? Where do the trade-offs make sense?

To understand how developers are receiving serverless, I went to where developers live: Reddit, Twitter, Hacker News, and YouTube. I parsed 1,000s of discussions and synthesized my findings in this article, striving to present only thought-provoking opinions.

Next, I transcribed these discussions onto a whiteboard, organizing them into "Pro Serverless," "Anti Serverless", or "Neutral" categories, and then clustering them into distinct opinions. Each section in this post showcases an opinion while referencing pertinent discussions.

Last week we merged our plugin into Backstage (Pull Request) to generate SDKs for internal services. For those that love to follow and discuss technology, we also published a blog post where Dylan reviewed 1,000s of GraphQL vs. REST perspectives. We also made a lot of improvements to our Python, TypeScript, and PHP SDK generators.

Backstage Plugin​

SDKs help onboard external developers but we know that the same problem exists inside organizations when integrating APIs from different teams owning different services. Backstage is a developer portal for centralizing your infrastructure and enabling product teams to quickly ship high-quality code. So we created a Backstage plugin to auto-generate SDKs for internal API services. If you are interested in generating SDKs for your internal APIs please reach out to us and we would love to talk. Check out our official plugin here!

Blog Post: I Reviewed 1,000s of GraphQL vs. REST Perspectives​

Ask any developer: do you prefer GraphQL or REST? This often leads to opinionated conversations, sometimes even devolving into vulgar opinions rather than objective facts. To delve into the GraphQL vs. REST debate, I scoured platforms where developers frequently discuss such matters: YouTube, Reddit, Twitter, and Hacker News. I parsed 1,000s of discussions and synthesized my findings in this blog post, striving to present only thought-provoking perspectives. Read more here!

Ask any developer: do you prefer GraphQL or REST? This often leads to opinionated conversations, sometimes even devolving into vulgar opinions rather than objective facts.

To delve into the GraphQL vs. REST debate, I scoured platforms where developers frequently discuss such matters: YouTube, Reddit, Twitter, and Hacker News. I parsed 1,000s of discussions and synthesized my findings in this article, striving to present only thought-provoking perspectives.

Next, I transcribed these discussions onto a whiteboard, organizing them into "Pro GraphQL," "Pro REST," or "Neutral" categories, and then clustering them into distinct perspectives. Each section in this post showcases a perspective while referencing pertinent discussions. To conclude, I highlight blog posts from GitHub and Shopify that serve as informative case studies in this ongoing debate.

Industry: Fintech

Results​

At Konfig, we are rapidly making progress towards building the easiest way to onboard developers to your API. To keep our followers up-to-date, we are starting this newsletter that will feature 2-3 of our biggest product updates and little fixes.

STATISTICS.md​

Now konfig generate will generate a file named STATISTICS.md that contains a count for Lines of Code in each SDK for your API. Here is an example that we generated. This file is generated in the same directory as your konfig.yaml file. In the future, we would also like to add more data such as weekly downloads.

Interactive Tutorial​

Our interactive tutorial is now live! Learn how to generate SDKs with a guided interface. This is a great way to get started with Konfig if you would like to generate SDKs yourself.

Improved TypeScript SDK Error​

Instead of just throwing the error from the underlying request library, axios, we now generate a file called error.ts that contains a custom Error class. The name of the class is based off the client name in your konfig.yaml file. The new custom error message has a cleaner interface and better inline documentation. In a Next.js API environment, the logged errors now exclude a lot of the garbage that was not helpful when debugging.

Imagine you are tasked to write 417,823 lines of code in 6 different languages. What if there was a way to slash that development effort significantly with just a fraction of the effort? Introducing code generation, where a few high-level instructions can do the work for you. In this blog post, we'll dive into the superpower of code generation, uncovering its presence from early programming to modern-day AI assistants.