Our great sponsors
-
orval
orval is able to generate client with appropriate type-signatures (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification, either in yaml or json formats. 🍺
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
crystal
Functional, tagless and lens-based, global state management. With scalajs-react fs2.Stream integrations. (by gemini-hlsw)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Backend is source of truth for types on frontend (backend generated OpenAPI definition with tapir, frontend takes it with orval)
Backend is source of truth for types on frontend (backend generated OpenAPI definition with tapir, frontend takes it with orval)
Then there's scalajs-react, which can be integrated with existing React ecosystem, but it's just sooo compex: macros, 5-6 type parameters, hundreds and hundreds of cryptic types. We decided to stick with TypeScript instead.
Yes, I have. It didn't work out. There are quite neat libs like Tyrian, but they lack any ecosystem and I struggled to integrate it with pure JS libs - yet our app has a lot of very common components/widgets that we're really hesitating to write ourselves.
I’ve used sbt-npm for exactly this case without issue. FWIW, I would generate both your Scala routes and TypeScript front ends from an OpenAPI spec rather than making the front end “see what the back end does today” with Tapir.
Maybe Laminar?
In this case, maybe Crystal?