Show HN: Kreya, a Postman Alternative (kreya.app)
Hi HN! For over a year we've been working on Kreya. At first, it only supported gRPC, because the alternative tools (eg. BloomRPC) were very limited in their functionality. Since then, we have added many features, trying hard to keep the UI clean while still supporting advanced use cases.
Yesterday, we released Kreya v1.8, which added support for REST!
In our opinion, Kreya is a good alternative to the existing tools out there. Sure, it may not support all the features that Postman has. But we think that Kreya has some innovative approaches (eg. authentication or API importers) that users may find interesting.
50 comments
[ 25.8 ms ] story [ 4079 ms ] threadTelemetry is opt-out and the gathered data points don't seem problematic to me: https://kreya.app/docs/telemetry/
Regarding telemetry, we are very open about what we collect and only use anonymized data.
But we, who are paid to make the most informed decisions, have to think harder.
Speaking personally, I use a REST/GraphQL client to test critical parts of an authenticated service. It is often necessary to test with elevated privileges. The consequences of credential leakage can be severe, and could have regulatory implications.
I cannot accept a closed-source tool that sends uninspectable data to a third-party server.
Open source is not a requirement, but auditability is critical. You can achieve auditability in a number of ways -- open source is just the least costly path.
It also supports generated data, environments, references, and expiring references which might trigger a different http call to get a new value for them.
[0]:https://insomnia.rest/
Some of the differences are the more complete gRPC support, how API authentication is handled and how the project data is stored.
API auth is complicated in insomnia, but there is a clever way to use variables/env to solve it once and for all. So that's also a non-issue in this comparison.
Insomnia UI/UX is still much better/prettier (Postman is ugly + bad UX).
So the only great point for now is how the data is stored. I don't know why Insomnia hasn't fixed this on their end yet; their sync is so bad because of this.
This point makes me interested in trying out your app but I already have large projects on Insomnia. How can I transfer (import) any of them to quickly give it a go and evaluate? Do you (plan to) support any import feature?
Do you guys think you will only gain new customers that are ready to start from 0?
Import of Insomnia or Postman collections is not yet implemented. However, if you have an OpenAPI/Swagger document, you can import that for a quick start. Or use the Kreya example project to quickly evaluate it.
> Postman is a scalable API testing tool that quickly integrates into CI/CD pipeline. It started in 2012 as a side project by Abhinav Asthana to simplify API workflow in testing and development.
https://www.guru99.com/postman-tutorial.html
gRPC is a Remote Procedure Call framework
We went through the list of islands on Wikipedia and changed some letters (and even forgot on which island the name Kreya is based on).
We are based in Switzerland
Overall it looks quite well done, although personally I don't have a real reason to use it over Insomnia.
We can't deny that Insomnia is a pretty good product :) It has its pros and cons compared to Kreya.
1. Variables / Dynamic Variables
2. GraphQL introspection
3. Pre/Post request scripts
4. Collection Runner
Postman is pretty expensive for larger teams.
That makes it horrible to collaborate because then you’d just be sharing giant JSON files which can easily go out of sync between multiple people.
GraphQL may be supported in the future, but we currently plan to expand the core features of Kreya first.
Regarding collaboration, we explicitely designed the Kreya storage model to be easily syncable via git (or your favorite VCS).
Don’t know about the GraphQL story, however.
https://docs.servicestack.net/api-explorer
I'd still use Postman for testing 3rd Party APIs, but it provides a subpar UX for calling our own APIs which we can provide a better optimized UX around our USP features, e.g. the "Code" tab walks end user API consumers through how they can easily call each typed API in 9 different supported languages:
https://docs.servicestack.net/api-explorer#code-tab
Glad to see competition in the space, but I doubt that Kreya can claim to be a "postman alternative" unless it has 75% feature parity with Postman, simply because the range of ways people use Postman is so broad, that it's an unverifiable claim.
Unless Kreya can do teams, testing, scripting, sharing, reviews, forking, publishing secret-link API docs, generating example API code out of the docs in Ruby/Python/etc, it certainly isn't an _alternative_ to Postman for my team's use-cases.
This looks really cool. The pricing confused me a little to begin with. Pricing per individual vs pricing per user feels sort of the same when at first glanced.
This may just be my silly opinion but thought i'd offer my feedback as it might help.
The difference is that with an Enterprise plan, company administrators can handle the (amount of) licenses centrally and distribute the licenses to their employees. The Pro plan is geared towards individuals, meaning they buy one license for themselves.
- Really nice having it integrated into the IDE - Happy with their release cadence - Support/dev has gotten back to me quickly - Does most of the important stuff from Postman imho
When JavaScript is enabled, Docusaurus pre-fetches links that you hover, resulting in a faster load. So Docusaurus deserves the praise for the fast page loads, we are not doing anything special :)
I worked previously with REST/ GraphQL and they have everything I need. Easy way to mock the HTTP 1.1 protocol, easy way to write automation scripts, easy way to debug/customize. Easy for new developers since everybody uses HTTP 1.1. I work with Java and Spring and HTTP 1.1 support is OOTB. For GRPC you have limited tools and unofficial libraries.
When considering an alternative, I was thinking about REST / GraphQL over HTTP2, with a centralized "Type System" and generated models / code (basically GRPC but more user friendly). For me "sending a HTTP2 request with a json payload" seems better and more user friendly than "sending a grpc request"
But now that I looked a bit more into it, seems like HTTP2 might not have a lot of support, so do your own research.