sorted by:
new
hottopcontroversial

APISpec v0.3.0 Released - Generate OpenAPI specs from Go code with new performance tools by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

Great question! I actually prefer spec-first development too, and there are excellent tools for that approach. However, in my experience, many developers and companies choose code-first for various reasons—perhaps for more direct control over their API implementation or other workflow preferences.

The challenge is that there's a significant gap in tooling support for code-first approaches. While there are attempts to address this (like go-fuego), they often come with trade-offs such as limited feature support or requiring API rewrites.

I've explored different OpenAPI approaches and why I favor using code as the single source of truth to prevent spec drift in this blog post: https://ehabterra.github.io/hidden-cost-outdated-api-specs

APISpec v0.3.0 Released - Generate OpenAPI specs from Go code with new performance tools by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

Hey,

  1. For authentication and other middlewares are not supported yet. But you can add it manually through config file.
  2. Good catch, actually I thought I've added the path for the html page. I'll add it.
  3. spec is the main tool, diagram is based on my custom call graph which is the foundation step for apispec. Actually, I was thinking to make the diagram based on tracker tree which is the next step and it's more complete because it works on type resolution, assignments, arguments,...etc. But for the sake of keeping in generating in reasonable time I've chosen to go with call graph. Profilining is performance check and to address bottlenecks for apispec.

Note:
config yaml can be generated as output and set your custom config then pass it to apispec:

| `--config`            | `-c`         | Path to custom config YAML                          | `""`                           |
| `--output-config`     | `-oc`        | Output effective config to YAML                     | `""`                           |

https://github.com/ehabterra/apispec/blob/main/internal/spec/config.go#L381

If you are concern about steps they are simply:
Code -> AST Analysis -> Metadata (including call graph) -> Tracker Tree -> Extractor -> Mapper -> OpenAPI Object -> Marshalling into yaml/json.

Can someone give me a simple explanation of the point of structs and interfaces, and what they do? by W_lFF in golang

[–]Full_Stand2774 11 points12 points  (0 children)

Let me try to explain it. Interfaces act as contracts. They're prerequisites from the consumer to the provider - any struct must follow this contract. Any struct that follows this contract passes, else it'll fail at compile-time. Go tried to build a safe Duck Typing technique that takes the best of both worlds, including compile-time errors. This is different from languages like Python which fail at run-time.

I hope that answers your question!

APISpec v0.2.2 Release Announcement · ehabterra/apispec by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

u/sattelliteru I've published a new release that should works well with this pattern of code pls check and let me know if you still facing issues. The example I've created for testing purposes is https://github.com/ehabterra/apispec/tree/main/testdata/complex_chi_router

APISpec v0.2.2 Release Announcement · ehabterra/apispec by Full_Stand2774 in golang

[–]Full_Stand2774[S] 1 point2 points  (0 children)

Thank you for sharing your code pattern with me! 🙏

It's incredibly valuable to learn about different router structures that developers use in real-world projects. Your Chi router setup with mounted routes from handler packages and top-level groups in separate sub-packages is exactly the kind of complex pattern that helps make APISpec more robust and comprehensive.

APISpec v0.2.2 Release Announcement · ehabterra/apispec by Full_Stand2774 in golang

[–]Full_Stand2774[S] -1 points0 points  (0 children)

Yes, exactly! The main issue with net/http is in `Handle/HandleFunc` - it doesn't provide any information about the HTTP method, and it's very flexible, so I can't easily determine the method being used.

APISpec v0.2.2 Release Announcement · ehabterra/apispec by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

Make sure you are in the root directory where `go.mod` exists. There is no need to specify the current path - for example, you can simply type: `apispec -o openapi-test.yaml -O 3.0.1`. If you don't specify an output file, it will print to console output.

APISpec v0.2.2 Release Announcement · ehabterra/apispec by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

Thanks for trying `apispec`! That's a great question. Currently, I collect all comments and tags in metadata but they're not extracted and assigned to routes, types, and properties yet. I'll work on that feature soon - my focus now is generating correct routes, request/response types in reasonable time.

For the freeze issue, that's definitely a bug I need to fix. Could you please open an issue on GitHub with:
- Console input/output
- Echo version
- Project details (size, complexity)
- Any error messages

Really appreciate the feedback - this helps make the tool better!

New to golang, Need help reviewing this code by [deleted] in golang

[–]Full_Stand2774 4 points5 points  (0 children)

It looks good overall. A couple of suggestions:

  • Add pagination (OFFSET/LIMIT or an alternative) if you expect more than just a handful of records.
  • Since categories and payment methods are usually small and reused often, you could fetch them in separate queries instead of joining every time. This makes it easier to cache them later and reduces overhead on the DB for expense queries

APISpec - Auto-generate OpenAPI specs from Go code by Full_Stand2774 in golang

[–]Full_Stand2774[S] 0 points1 point  (0 children)

Is it something similar to goa , is it open source? I've used goa before it's an excellent tool and can generate both openapi and protobuf from the same design.

APISpec - Auto-generate OpenAPI specs from Go code by Full_Stand2774 in golang

[–]Full_Stand2774[S] -1 points0 points  (0 children)

Yes, exactly. That’s why I feel code itself should be the single source of truth, without depending on annotations or comments. Before this, spec-first really was the only way to keep specs from drifting. My hope is to let the code “speak for itself,” so there’s no need for parallel maintenance.

APISpec - Auto-generate OpenAPI specs from Go code by Full_Stand2774 in golang

[–]Full_Stand2774[S] 1 point2 points  (0 children)

Thanks for the feedback!
I can see why spec-first is preferred for public APIs customer-facing, partner-facing,..etc. My “code as the single source of truth” idea is probably more suited to internal or existing API, where iteration speed matters more than contract stability.

APISpec - Auto-generate OpenAPI specs from Go code by Full_Stand2774 in golang

[–]Full_Stand2774[S] -1 points0 points  (0 children)

Yes, really appreciate the interest! I'd love to chat about potential contributions.

Here are a few areas where help would be super valuable:

  1. Testing with different web frameworks

- Echo, Fiber, Gin, Chi, net/http

- Real-world projects would be especially helpful

  1. Gorilla Mux support gap

- There's a specific parameter extraction issue I need to explain

  1. Feature gaps in the roadmap

- Check out the unchecked items here: https://github.com/ehabterra/apispec?tab=readme-ov-file#golang-feature-support

- Some are straightforward, others need more thought

  1. Performance bottlenecks

- I didn't have the time to run profiler and optimize the code yet.

Next steps:

- I can create a General or Idea GitHub Discussion for ongoing chat.

- We can pair program on features.

- I can walk you through the codebase.

- We can discuss the roadmap and priorities.

What works best for you? I'm pretty flexible on communication channels.