jonfk
Joined 15 years ago
Joined 15 years ago
It reminds me of the hive cities of Warhammer 40k.
Another analysis of Kowloon I enjoyed is this one by the architect Dami Lee [1].
[1] https://m.youtube.com/watch?v=WLn_QTFVZgE&pp=ygUFIzJhYWI%3D
I am in Canada.
My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia which doesn't seem to be much better in my opinion.
I recently found httpyac[1]. It's a cli and file based http client similar to the IntelliJ HTTP client, but has plugins, hooks and allows scripting through javascript blocks. It seems to have everything I need but I haven't used it much yet. It also already supports gRPC.
One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request. Postman did provide some of that but that's one area I wanted more from any client I looked at. I could of course simply wrap curl in a script but at that point, I will be maintaining my own jerryrigged version of an http client for my team.
How to handle the differing syntax of each databases would be handled at a higher level, by the query builder or orm. The orm could decide to let the user decide for themselves whether to write portable sql or not and fail at runtime, or like diesel in rust, enforce the useable features through its types.
In my experience that is something that is currently missing in the rust ecosystem. Each library seem to have its own connection logic and if I want to write a program that could run on different databases in rust right now, I have to write different code to connect to each database I would like to support.
Diesel has been serving me really well but I currently need to choose a specific backend when I am building a query, and implementing the above dynamic style of connection would be quite cumbersome to implement. It would be nice if we could choose another a standard sql backend where I would only be able to use a subset of features supported by most sql databases and build queries against that. Hopefully the RDBC project could help with something like that.