A startup is a long and difficult journey, one that I was wholly unprepared for despite having a decade of work experience in finance and tech. Learnings from one failed startup influence the next startup attempt, so to take a step back and discuss why I got into the gaming space in the first place, I have to talk about my first startup, an investment app that helped people learn about and construct portfolios of ETFs, that I co-founded in 2021.

OpenAPI makes it really easy to generate documentation for your API. There are a number of open source and paid solutions that make it easy to generate documentation for your API. To determine the best solution for your needs, we researched and compared the best open source and paid OpenAPI documentation generators.

At the end, we give our opinion on which solution is best for you depending on your requirements and current setup.

Python SDK Ergonomic Improvement​

We improved the Python SDK to return Pydantic-based response values which allows for using the __getattr__. This is slightly more concise than the previous version, which used the __getitem__ syntax to access response values.

Before​

Previously, you had to use the [] syntax to access response values. This required a little more code for every property access.

After​

With Pydantic-based response values, you can use the . syntax to access. This is slightly less verbose and looks more Pythonic.

Notice how there is also no need to use the body attribute to access the response body. All new Python SDKs will be using this new syntax.

We will not be updating previously generated Python SDKs to use this new syntax to ensure backwards compatibility.

Non-SDK Snippets in API Portal​

The API Reference page now generates non-SDK code snippets for cURL and other languages that do not have an SDK. This allows developers to quickly generate, copy, and paste code snippets regardless of whether or not there is an SDK for your language.

Konfig offers numerous benefits when generating SDKs from OpenAPI compared to utilizing an open-source library or crafting them manually. These benefits significantly impact your engineers and business in a positive manner. In this article, we will outline these crucial advantages.

GitHub Copilot has recently taken the software engineering world by storm, hitting a milestone of $100M ARR. This achievement alone qualifies it to be a publicly listed company. Meanwhile, funding continues to flow into code-focused LLM use cases.

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.