Hey. I'm currently making Typeflows to solve this (amongst) another few pain points, and am planning to make it available in JVM (this exists now)/TS and Python at least.
There are existing solutions around, but do miss out a bunch of things that are blatantly missing in the space:
- running workflows through an event simulator so you can tell cause and effect when it comes to what triggers what. Testing workflows anyone? :)
- security testing on workflows - to avoid the many footguns that there are in GHA around secrets etc;
- compliance tests around permitted Action versions;
- publishing of reusable repository files as binary dependencies that can be upgraded and compiled into your projects - including not just GHA actions and workflows but also things like version files, composable Copilot/Claude/Cursor instruction files;
- GitLab, CircleCI, Bitbucket, Azure DevOps support using the same approach and in multiple languages;
Early days yet, but am planning to make it free for OSS and paid for commercial users. I'm also dogfooding it on one of my other open source projects so to make sure that it can handle non-trivial cases. Lots to do - and hopefully it will be valuable enough for commercial companies to pay for!
Hey - maintainer here. Sorry about your bad experience and thanks for mentioning it! The Core Web Vitals test did come back ok - but evidently there's more to do so will get that sorted. (Web design not a strong point! ). The code examples should be showing on smaller screens when in landscape on mobile (they looked awful in portrait) - but will also look at that as well!
Could I possibly ask you to reply with the model of your phone so can make sure it works ok after have fixed?
Hey - Typeflows maintainer here. We know that there are other similar libraries out there that do some of the same thing as Typeflows, but am hoping to go much much further than anything out there to help out teams struggling with their pipelines. Examples of things on the roadmap:
- running workflows through an event simulator so you can tell cause and effect when it comes to what triggers what;
- security testing on workflows - to avoid the many footguns that there are in GHA around secrets etc;
- compliance tests around permitted Action versions;
- publishing of reusable repository files as binary dependencies that can be upgraded and compiled into your projects - including not just GHA actions and workflows but also things like version files, composable Copilot/Claude/Cursor instruction files;
- GitLab, CircleCI, Bitbucket, Azure DevOps support using the same approach and in multiple languages;
Lots to do - and hopefully it will be valuable enough for commercial companies to pay for!
Luckily, there are saner alternatives on the JVM. If you read at "Your server as a function" paper from Twitter, you'll see that the composing of middleware and simple handler functions can be used to develop powerful stacks which are a doddle to write, reason about and test.
The SaaF design was used to design Finagle (Scala), and then it inspired http4k (Kotlin). There may be more that I'm not aware of. These libraries are often described as micro-frameworks - but this is misleading - it is only because the core is very small and can be easily extended by bolt-on modules.
First off, the most important thing for us is to keep the APIs simple, sane and consistent. We absolutely won't add anything in a rush, or if it means compromising that core principle. :)
There are various things I'd like to add - simple plugin modules for metrics (dropwizard or prometheus), security (probably pac4j) and typesafe session support (via lenses) are in there. A sane websocket api seems to be a popular request so we'll also probably look at that.
Async would probably be via coroutines as that seems to be the nicest option API-wise. If it did work out well then we could probably backport it and piggyback the sync api on top.
The serverless stuff is interesting as well, although that's more around the deployment tooling at the moment - we'll see what happens if Google and MS get involved, or how the tooling develops for things like terraform.
Other than that - we'll happily accept suggestions! :)
All in? About 15 years of being frustrated at various frameworks... :)
More seriously, we had a pretty good idea of how we wanted the main interfaces to look - the current HttpHandler and Filter file (https://github.com/http4k/http4k/blob/master/http4k-core/src...) file is only 19 lines long - so the actual implementation was pretty quick! :)
Previous to that, we started out with a 40 line Kotlin script which wrapped the API of an awesome Java framework called UtterlyIdle. However we soon wanted to begin using pure, idiomatic Kotlin, so eventually decided to start again and port what we needed. The simple routing API was also pretty easy, although the ability to infinitely nest routes in concert with the Filter system came later.
Timewise, we've been in prod with http4k since about March - here's the github contribution graph (https://github.com/http4k/http4k/graphs/contributors). A lot of the effort since has been for adding the various modules as we needed them - AWS request signing was interesting, as was adding Multipart support (ported from a Java implementation by @tiestvilee who you can witness being sarcastic further down this thread :).
Personally, the most complicated (ie. time-spent) bit to get right was probably the Lens API- there were several iterations of that until it was as clean, and we learned a lot about the language at the same time - for instance, that you can define extension methods on a Kotlin Object and then import them from that instance - thus allowing you to have different versions of the same extension method happily coexisting.
Hi. Library author here - we thought we'd commemorate our v3.0.0 release - which adds AWS Lambda as a as a server(less!) backend - with a self-congratulatory post. We hope you like our stuff :)
As you might have guessed from the version number, http4k isn't actually that new - we've been using it in production with significant traffic (in the top 1000 globally according to alexa.com) since March so it's thoroughly battletested in the wild.