Show HN: Hacker News API SDKs → Code Generation in Rust | Hacker News Reader

Show HN: Hacker News API SDKs → Code Generation in Rust

hacker-news.sideko.dev

39 pointspmkelly444419 comments

Hi Hacker News!

Patrick and Elias here. We built an SDK / Documentation generator for REST APIs. The link included shows the shiny output of our system: the docs! We generated 5 SDKs and docs from the Hacker News OpenAPI we found on GitHub. If you write code in Python, Typescript, Go, Ruby, or Rust, we’d love for you to try an SDK out!

If you want to generate SDKs for your own API try our tool here: https://github.com/Sideko-Inc/sideko

We are both software engineers, and we built this tool because we were spending too much time writing API integrations, supporting integrations, writing documentation, and manually testing APIs at our jobs. We think every engineer can benefit from spending less time on APIs.

The generator is written in Rust because we need the rich type system, macros, and general correctness emphasis to generate working code. The SDKs are typed, they simplify auth, and they handle files.

If you want to learn more, check out our complete write up here: https://sideko.substack.com/p/the-hacker-news-api-enhanced-b...

Thanks everyone,

PK and EP - team@sideko.dev

Open articleView on HN

Every week there's a new SDK & Docs generator popping out. Fern, Speakeasy, LibLab, Stainless. And now Sideko. How many more do we need?

Edit: just took a look at the GitHub repo provided and turns out it's just a wrapper around their API.

Hey, co-founder of Fern https://www.buildwithfern.com here.

You're right that four companies are going after SDK and Docs generation. After seeing enterprises like AWS, Stripe, Twilio, Palantir, Dropbox, and many more build codegen for REST APIs in-house, it seems like a no-brainer that they'll be a solution that serves the millions of developers out there working with REST APIs.

We're seeing a new category getting created before our eyes! I could see it being defined as "Developer Experience Infrastructure", "API Management", or "API Operations". Time will tell.

How are you

A few years back I built an API with Django REST Framework, and the client wanted a thin client. I opened up Postman, and generated Python code from the requests I was making while testing, then I made it as reusable / generic as possible, it was insanely thing, even for not using requests, I forgot what the built-in for Python 2 was called.

So I havent had to since, but Postman's code generation is enough to give you a boilerplate to go from, but I think also openAPI has code generator tools. I do think making something so repetitive is kind of dull when tooling can automate so much of it and then you refine it as needed.

Very cool idea! I can't wait to use this next time I need bindings to an API.

As a side note, I wanted to go see what code was generated (and check the quality) but I couldn't find a docs.rs or github for the rust example (did I miss it?). I ended up having to look it up on docs.rs and was surprised that there were no comments there.

Do you have plans to add language-level documentation for the generated code?

Thank you! We will add links to the github/docs.rs to our documentation ASAP.

And yes, language-level docs will be implemented. So far we've found that our users are happy with using the snippets in the docs + autocomplete from typing in code editor. But for advanced use cases I definitely see the value in language-level docs.

edit: we've moved all unofficial projects to the "public" subdomain: https://public.sideko.dev/hacker-news/docs

Looks interesting! I’m curious how you’re integrating in the target languages? Are you loading a .so/.dll lib built by rust? Or wrapping a binary? Something else?

thank you! It's funny, loading a .so/.dll was our initial approach to the problem. we found that this didn't work for us for two reasons.

1. Security/packaging problems. Security problem is self-explanatory, and for packaging binaries in SDKs we ran into a lot of issues with languages that don't have first-class support for binaries. It was particularly problematic in golang. 2. Iteration time: waiting for a cross-compilable binary each time we wanted to create a new SDK was a huge testing issue. we needed to build in a way that let us test our outputted SDKs in seconds rather than minutes. we now have a testing pipeline that runs in less than a minute on a bunch of live APIs

so we've gone with an approach that uses a combination of custom macros + templating

Ah so you’re doing code generation in each target language. Cool, that’s an interesting approach.

any plans to generate something for the server side? What I've been prototyping macros which wrap functions to ensure that they adhere to the behavior of an openapi spec.

Hmm, I'm getting PR_CONNECT_RESET_ERROR

Google results showing me this occurs in Firefox sometimes. will check it out

… it's just Firefox's error identifier for a connection reset. It's otherwise not specific to Firefox, it's just a connection reset…

Looks awesome. Can’t wait to try it out!

Love it, amazing job guys!

This is quite cool

Thank you!

Wife changing technology. Amazing work guys.

Reply on news.ycombinator.com