connect-es
GJSON
Our great sponsors
connect-es | GJSON | |
---|---|---|
13 | 34 | |
1,202 | 13,616 | |
3.4% | - | |
9.2 | 5.1 | |
6 days ago | 5 days ago | |
TypeScript | Go | |
Apache License 2.0 | MIT License |
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.
connect-es
-
I Reviewed 1,000s of Opinions on gRPC
> However, it's important to note that browser support wasn't a primary focus in gRPC's design. This oversight necessitates an additional component, grpc-web, for browser accessibility. Furthermore, external services often have specific needs like caching and load balancing, which are not directly catered to by gRPC. Adopting gRPC for external services might require bespoke solutions to support these features.
The article should mention the Connect protocol for web-based Protobuf messaging:
https://connectrpc.com/
-
Creating the Local First Stack
We can solve this with a service! Now there are many ways I could have started, but I decided to test out gRPC along the way. This was a mistake. I hoped for the best, but gRPC ended up not being a good choice for the web client. Why? you ask. The gRPC protocol works with all the bells and whistles of http when used server to server, but web clients are not as great. The Javascript client is dependent on http 2.0, and it requires a proxy like Envoy to work with a browser. What's more, I didn't love the structure of the generated web client. So through the process of working on this 'local first stack' I actually got sucked in to a big rabbit hole in making the rpc system work. I ended up going with Connect which is a tool that can create a service from a protobuf service definition, that also talks a simple http 1.1 protocol. What ultimately sold me on this solution as the best is that it also came with a very nice to use web client generation, and even plugs in to my favorite react http helper useQuery.
-
Leveraging Temporal for resilient remote procedure calls (RPC)
Our stack at Escape is written in multiple languages because each team has specific needs. We use TypeScript for its vibrant ecosystem, Python for cybersecurity research and Go for performance-sensitive tasks. To orchestrate cross-language task orchestration, we first developed a simple request-response protocol over HTTP, but it wasn't sustainable as the Escape codebase grew rapidly. We evaluated several technologies to replace our homegrown protocol, and two emerged as the most promising options: Connect and Temporal. The title gives it away, but the reason is far from obvious
- Connect RPC – A Better gRPC
-
Building a modern gRPC-powered microservice using Node.js, Typescript, and Connect
protobuf messages we’ll configure (@bufbuild/connect-es)
-
TypeScript type safety with GO
try https://github.com/bufbuild/connect-web
-
Ask HN: Why isn't JSON-RPC more widely adopted?
As for better gRPC-web, you might want to look into connect-web https://github.com/bufbuild/connect-web
- When to use gRPC vs GraphQL
-
Protobuf-ES: The Protocol Buffers TypeScript/JavaScript runtime we all deserve
They already have! Connect (https://github.com/bufbuild/connect-web) is what you're looking for, as it's grpc-web compatible.
-
Connect-Web: It's time for Protobuf/gRPC to be your first choice in the browser
Ye, fwiw there is an example code size comparison here:
https://github.com/bufbuild/connect-web/blob/main/packages/c...
I'm sure someone will chime in on the implementation details, but hopefully others can give it a try with their projects!
GJSON
-
Rob Pike: Gobs of data (2011)
Someone made a benchmark of serialization libraries in go [1], and I was surprised to see gobs is one of the slowest ones, specially for decoding. I suspect part of the reason is that the API doesn't not allow reusing decoders [2]. From my explorations it seems like both JSON [3], message-pack [4] and CBOR [5] are better alternatives.
By the way, in Go there are a like a million JSON encoders because a lot of things in the std library are not really coded for maximum performance but more for easy of usage, it seems. Perhaps this is the right balance for certain things (ex: the http library, see [6]).
There are also a bunch of libraries that allow you to modify a JSON file "in place", without having to fully deserialize into structs (ex: GJSON/SJSON [7] [8]). This sounds very convenient and more efficient that fully de/serializing if we just need to change the data a little.
--
1: https://github.com/alecthomas/go_serialization_benchmarks
2: https://github.com/golang/go/issues/29766#issuecomment-45492...
--
3: https://github.com/goccy/go-json
4: https://github.com/vmihailenco/msgpack
5: https://github.com/fxamacker/cbor
--
6: https://github.com/valyala/fasthttp#faq
--
7: https://github.com/tidwall/gjson
8: https://github.com/tidwall/sjson
-
Jj: JSON Stream Editor
```
I don't think there is a way to sort an array, though. However, there is an option to have keys sorted. Personally, I don't think there is much annoyance in that. One could just pipe `jj` output to `sort | uniq -c`.
[0]: https://github.com/tidwall/gjson/blob/master/SYNTAX.md
-
Library to analyze an arbitrary JSON string
I’m using GJSON, so far so good!
-
Mapping json fields in api calls to a struct to store them in a database or cache
If the fields you need are just a small subset of the whole json, maybe https://github.com/tidwall/gjson might be of use to read only those (using jsonpath) without needing to create complete corresponding structs.
-
Which CPU to buy based on profiling
Thank you for the reminder, it's never too much of it :) Didn't say it, but the code was pprof-iled many times and i can really say it's well optimized. I use own libraries with on-the-fly equations (sums, avgs, emas, stds, ...) wherever possible and also made custom json parser as json messages are in fixed format, so the parser is about 10x faster than gjson. I optimized it to the point that I avoided using maps, and rather iterate via slice where ever possible.
-
Jetro - transform and query JSON format
You are right, for learning purposes this fit my needs, but I can imagine an approach similar to this repo: https://github.com/tidwall/gjson
-
Any way to convert unknown/dynamic json to generic object structure
https://github.com/tidwall/gjson is a relatively sensible library if this is something you need to deal with and the structure is actually unknowable.
- Need help with getting the grandchild in nested JSON
- Double down on python or learn Go
- Ad hoc JSON parsing
What are some alternatives?
protobuf-es - Protocol Buffers for ECMAScript. The only JavaScript Protobuf library that is fully-compliant with Protobuf conformance tests.
jsoniter - A high-performance 100% compatible drop-in replacement of "encoding/json"
grpc-web - gRPC for Web Clients
go-json - Fast JSON encoder/decoder compatible with encoding/json for Go
ts-proto - An idiomatic protobuf generator for TypeScript
intrinsic
buf - The best way of working with Protocol Buffers.
gojson - Automatically generate Go (golang) struct definitions from example JSON
fastify-autoroutes - fastest way to map directories to URLs in fastify
hub - A command-line tool that makes git easier to use with GitHub.
protoc-gen-validate - Protocol Buffer Validation - Being replaced by github.com/bufbuild/protovalidate
ngrok - Unified ingress for developers