Monocle
openapi-preprocessor
Our great sponsors
| Monocle | openapi-preprocessor | |
|---|---|---|
| 5 | 2 | |
| 1,629 | 34 | |
| 0.1% | - | |
| 8.3 | 3.7 | |
| 7 days ago | about 1 month ago | |
| Scala | Go | |
| MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Monocle
-
Ref in cats-effect. When should I use it, and when should I not?
Without concurrency, using a Ref doesn't buy you anything over just using a var. If you want the benefits of immutability with an API that resembles mutability, you have to use something like Monocle.
-
Show HN: Monocle – bidirectional code generation library
A very popular Scala optics library is also called Monocle. I’ve been a happy user for a few years:
https://github.com/optics-dev/Monocle
-
Monocle 3 release candidate - a super useful and simple library for optics with poetic api
See example https://www.optics.dev/Monocle/
- Monocle 3.0.0-M1 is released for Scala 2.13 and Scala 3
-
Monocle 3 Roadmap
We always have work to do, for example to define scalfix rules to automate the migration https://github.com/optics-dev/Monocle/issues/1001
openapi-preprocessor
-
Show HN: Monocle – bidirectional code generation library
I use a mixed approach for OpenAPI, but not bidirectional.
I have OpenAPI pieces generated from my Go source code (comment, types, function signatures) as JSON.
I also have a manually-edited master YAML document that refers to generated bits via $ref links.
I then use openapi-preprocessor [1] (disclaimer: I wrote it) to produce a final openapi.json file which is committed in the repo.
When I want to extend the API in a spec-first process, I can add the new routes manually in the YAML file. When I do the implementation I replace the manual bits by the generated one when they are ready. When committing I can check the diff of openapi.json to verify I'm not losing in the process.
[1] https://github.com/dolmen-go/openapi-preprocessor
-
JSON Schema bundling finally formalised
Bundling for OpenAPI specification has long been a need for authors to allow to reduce duplication, and to allow to split a big specification in multiples files, but publish a single one.
A few years ago I've written a tool to fit that niche: https://github.com/dolmen-go/openapi-preprocessor
https://github.com/dolmen-go/openapi-preprocessor
I have now to tweak it (well, it will be a major rewrite) to handle $ref relative to $id instead of the file location.
What are some alternatives?
Quicklens - Modify deeply nested case class fields
oasdiff - OpenAPI Diff and Breaking Changes
Shapeless - Generic programming for Scala
zod - TypeScript-first schema validation with static type inference
Chimney - Scala library for boilerplate-free, type-safe data transformations
ajv - The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
cats - Lightweight, modular, and extensible library for functional programming.
api-firewall - Fast and light-weight API proxy firewall for request and response validation by OpenAPI specs.
Scalaz - Principled Functional Programming in Scala
io-ts - Runtime type system for IO decoding/encoding
Scala Graph - Graph for Scala is intended to provide basic graph functionality seamlessly fitting into the Scala Collection Library. Like the well known members of scala.collection, Graph for Scala is an in-memory graph library aiming at editing and traversing graphs, finding cycles etc. in a user-friendly way.
apiclarity - An API security tool to capture and analyze API traffic, test API endpoints, reconstruct Open API specification, and identify API security risks.