Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try liblab #1543

Closed
wants to merge 7 commits into from
Closed

Try liblab #1543

wants to merge 7 commits into from

Conversation

bkoelman
Copy link
Member

@bkoelman bkoelman commented May 11, 2024

liblab is a new commercial OpenAPI client generator for various languages, including C#. While free for open-source, pricing starts at $100 per month, which provides unlimited credits. Each generation run consumes one credit. Just buying credits would make more sense for small projects, or projects in maintenance mode, but that isn't offered. I've given the C# generator a try, see my findings below.

  • Reading through all the documentation, I haven't found which OAS features are supported and what structure the generator expects.
  • Generated project files target .NET 6 instead of 8 (which is going out of support by the end of this year).
  • Generated C# files don't have the well-known "auto-generated" comment on the first line, causing code-style warnings.
  • Running liblab build generates a separate project for the SDK and one for its usage. I would prefer a single (combined) project by default for simplicity. Generic support code is being generated; a public NuGet package would be easier.
  • The inner loop experience is just as awful as kiota: no msbuild integration. What it should be: build solution, which rebuilds server project, which updates openapi.json, which regenerates the sdk (like NSwag does).
    • Would regenerate even work when I'm on a plane? Requiring an internet connection is a huge limitation.
  • Generated install.sh doesn't run on Windows, should use PowerShell instead.
  • Handling of required/nullable is better than kiota, though not entirely correct. For example, the return type of PatchPersonAsync() should be nullable.
  • Inheritance using allOf with discriminator does not work: the generated types do not inherit from base types. For example, TodoItemDataInResponse should inherit from DataInResponse. Also, oddly named "Type_" property generated, while Type is not a reserved keyword or member.
  • Setting responseHeaders to true in liblab.config.json does not work: the generated code remains the same.
  • A new HttpClient instance is created each time during construction, which isn't scalable (and doesn't respond to DNS changes when long-lived). Should use HttpClientFactory instead.
  • There's no way to inject a DelegatingHandler, for example to log the HTTP requests and responses.
  • When sending a request, the user agent is set to "dotnet/7.0" while the project targets .NET 6.
  • Posting with a request body requires nasty code; should use required init properties instead of constructor parameters. Also, the parameter order from openapi.json isn't respected.
  • There's no way to set the Content-Type when sending a request body.
  • Incorrect generated .NET type for free-format "meta" object (should be IDictionary<string, object?>? instead of object?)
  • There doesn't seem to be a way to intercept serialization to support partial patch (ie: sending "firstName: null" clears the value, whereas omitting the property doesn't change it).
    • NSwag allows to inject custom serializer options, where we add a custom JsonConverter. kiota handles it more elegantly by tracking property assignments.
  • Generated response.EnsureSuccessStatusCode() isn't correct: it fails when HTTP 304 is returned (similar to Kiota throws ApiException when server returns 304 microsoft/kiota#4190).
  • Crash in response deserialization when HTTP 204 is returned with an empty response body.

I just tested a few basics, but my conclusion so far is that liblab currently isn't usable for this project (I don't consider hand-editing generated code an option). Though I'm happy to see competition in the OpenAPI space, it seems to me that liblab doesn't yet provide the features we need.

The individual commits reflect the steps I've followed. This PR was created to share my findings, it is not intended to be merged.

- Create and enter subdirectory src/Examples/OpenApLiblabClientExample
- liblab init
- Change liblab.config.json
  - Set sdkName to JsonApiDotNetCoreClientExample
  - Set specFilePath to JsonApiDotNetCoreExample
- Add generated projects to solution
@bkoelman bkoelman changed the base branch from master to openapi May 11, 2024 07:49
@bkoelman bkoelman closed this May 20, 2024
@bkoelman bkoelman deleted the try-liblab branch May 20, 2024 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

None yet

1 participant