hetida-designer VS openapi-generator

Shameless Plug: We are working on a similar tool: https://github.com/hetida/hetida-designer

We have no GUI programming in the broader sense, in our case nodes are simply run one after another (DAG).

Our tool is a web application and workflows can be triggered / executed via API, which allows for automatisation. Workflows can be nested and are tagged with a version tag making production runs reproducible. It is very much taylored to (simple) Data Science use cases with the goal to make the Python data science stack accessible for Business Experts (or power users), maybe collaborating with Data Scientists.

It is actively developed, and our industrial customers happily use it, however it is still in early development state.

Hello everybody! We recently open sourced hetida designer, a workflow-based collaboration, development, and runtime environment for the Python data science stack.

You would use OpenAPI (formerly Swagger) [1] for that, which includes JSONSchema for data types but also adds specs for defining REST apis. There are plenty of generators and other tools that work with OpenAPI [2]

[1] https://www.openapis.org/

[2] https://openapi-generator.tech/

I found some "tricks" to write less code, hence less code to maintain if there are any changes. Also less code with bugs just by changing the inputs.

For example, OpenAPI spec file + OpenAPI generator (https://github.com/OpenAPITools/openapi-generator). Any changes in the OpenAPI spec are reflected in the final code with a build step.

Another example: MapStruct (https://mapstruct.org/) to avoid passing data from Entity classes to DTO and back. Saves looots of boilerplate code.

Which are your tricks?

Disclaimer: We're an early adopter of Stainless at Mux.

I've spent more of my time than I'd like to admit managing both OpenAPi spec files [1] and fighting with openapi-generator [2] than any sane person should have to. While it's great having the freedom to change the templates an thus generated SDKs you get with using that sort of approach, it's also super time consuming, and when you have a lot of SDKs (we have 6 generated SDKs), in my experience it needs someone devoted to managing the process, staying up with template changes etc.

Excited to see more SDK languages come to Stainless!

[1] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...

[2] https://github.com/OpenAPITools/openapi-generator

As a result, the following specification can be used to generate clients in a number of different languages via OpenAPI Generator.

Of course you can compile the server from source if you have Go and the OpenAPI generator JAR (https://github.com/OpenAPITools/openapi-generator?tab=readme...)

Follow these steps : https://github.com/c100k/rebootx-on-prem/blob/master/.github...

And then :

(cd ./impl/http-server-go && GOARCH=amd64 GOOS=openbsd go build -o /app/rebootx-on-prem-http-server-go-openbsd-amd64 -v)

By adapting the arch if needed. Not tested, but it should work.

TL;DR: Start generating your HTTP clients and all the DTOs of the requests and responses automatically from your API, using openapi-generator instead of writing your own.

As an alternative, you can also use the official OpenAPI Generator, which is a more generic tool supporting a wide range of languages and frameworks.

I trialed generating SDKs using the OpenAPI Generator package, which was largely unsatisfactory.

If Swagger/OpenAPI is available, save yourself a lot of trouble and generate the client using OpenAPI Generator. If not, use a library like RestEase to make it significantly easier to create the client.