googleapis
aws-sdk-rust
googleapis | aws-sdk-rust | |
---|---|---|
13 | 33 | |
6,522 | 2,858 | |
1.0% | 1.1% | |
9.6 | 9.8 | |
4 days ago | 3 days ago | |
Starlark | Rust | |
Apache License 2.0 | Apache License 2.0 |
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.
googleapis
-
REST vs gRPC
Rich Error Model: This model enables servers to return and clients to consume additional error details expressed as one or more protobuf messages. It further specifies a standard set of error message types to cover the most common error (QuotaFailure, PreconditionFailure, BadRequest, etc). When an error occurs, the server returns the appropriate status code along with an optional error message.
-
Mullvad Leta
They list search in their public api
https://github.com/googleapis/googleapis/blob/288aa7fb71c9b6...
-
Reasons to use gRPC/Protobuf?
We structure the repo according to proto packages. It's quite similar to how the googleapis repository is structured.
-
Problem Details for HTTP APIs
It's unfortunate that the spec doesn't contain custom fields to a sub-object like other RPC specs, like proto Status [1]. They should have had the message go into a field named "message" and not "detail". And have a field like "details" where the opaque type is serialized, which should be named by the "type" field. The problem is that systems with existing error types may have field name conflicts with type, title, status, detail, or instance, so we'd just dump the actual error into a custom "extension member" which by definition, isn't standard.
[1] https://github.com/googleapis/googleapis/blob/1c8a25ab153eef...
-
[Media] Dear Google, When Rust? Sincerely, Internet
Protobuf (https://github.com/googleapis/googleapis)
-
gRPC vs REST: Comparing API Styles in Practice
All the required changes can be viewed in our last demo, the grpc-rest-app implementation. First, we need to update our proto service interface to help the proxy service make our gRPC service methods available at the right URLs and for the correct HTTP operations. To do this, the Google API HTTP library provides annotations we can add to our proto to describe the correct mappings. The buf tool allows us to include the googleapis dependency as a plugin in our buf.yaml file).
-
Code Design Decision – Always throw custom exceptions
I think this only makes sense if the 3rd party is also throwing custom exceptions.
If you want to reduce coupling you should avoid throwing custom exceptions at all. Semantic information can go in the error message and log. The error type should be used to indicate to your program whether an error is recoverable, retriable or some other action needs to be taken. For example google on has 16 canonical error codes for all APIs.
https://github.com/googleapis/googleapis/blob/master/google/...
-
Microservice Communication
OpenAPI and possibly developing reusable, versioned client libraries could help, but it's a major undertaking that gRPC makes redundant. I'd be tempted to use grpc-gateway even if I had to implement a REST API. Try looking into buf and monorepo structures for proto management, e.g. something like GoogleCloudPlatform/microservices-demo. For more thorough proto and grpc-gateway definition examples, see googleapis/googleapis.
-
Convex vs. Firebase
Firestone does provide global consistency, so the following quote is incorrect:
> In Cloud Firestore, the data on the client are loaded from the database at different points in time. Even if you listen for realtime updates, results from separate queries will not remain in sync. This creates consistency anomalies and bugs in your app.
Here is a link to the protocol documentation that the clients use to support it: https://github.com/googleapis/googleapis/blob/d0b394f188e8c3...
I'd link to the client implementation but it's quite involved.
-
Useful Old Technologies: ASN.1 (2013)
Well there is Timestamp defined as a well known type which is available to all implementations despite not being a primitive type [1]. Plus one is obviously able to define any other custom types if necessary- eg as seen in [2].
[1] https://developers.google.com/protocol-buffers/docs/referenc...
[2] https://github.com/googleapis/googleapis/blob/master/google/...
aws-sdk-rust
- Boletín AWS Open Source, Christmas Edition
-
My top picks of re:Invent 2023
The AWS SDK for Rust contains one crate for each AWS service - you can check them out here.
- AWS SDK Crates reach 1.0 🎉
-
General Availability of the AWS SDK for Rust
> What kind of plans for support of Rust's evolving async ecosystem?
We were hoping async-function-in-trait would land before GA, however, we have a plan to add support in a backwards compatible way when it's released.
> Any particular reason why the public roadmap does not show the columns similar to "Researching", "We're Working On It" like the other similar public AWS Roadmaps?
Our roadmap has unfortunately been in a state of disrepair for some time. We're hoping to get it cleaned up and accurate post GA.
> Would be nice to have fully working examples on Github, for most common scenarios across most AWS services. This is something that historically AWS SDKs have been inconsistent on. Just a request not really a question :-)
There are lots of examples here [1], some simple, some quite complex. If there's something you have in mind, please file an issue! Having great examples is one of our priorities.
[1]: https://github.com/awslabs/aws-sdk-rust/tree/main/examples
-
Proper way to do thousands of asynchronous http requests
There’s a pretty nice example of this in the aws rust sdk here.
-
[Q] How mature is the AWS Rust ecosystem?
The official AWS Rust SDK still seems to be a work in progress(developer preview) with a warning to not use it in production.
-
Hey Rustaceans! Got a question? Ask here (16/2023)!
i'm using https://github.com/awslabs/aws-sdk-rust heavily and was wondering if there was a more specific community (subreddit, Discord server, etc) of Rust x AWS developers?
-
"thread 'main' panicked at 'no CA certificates found'", when running application in docker container
Only relevant search result was this github issue, which didn't really solve the problem.
-
S3 Proxy Server
I went on rusoto just because aws-sdk-rust says at the beginning of the readme:
-
[Media] Dear Google, When Rust? Sincerely, Internet
Official libraries for major cloud vendors will definitely boost Rust's adoption. aws-sdk-rust is still in 'developer preview', but it's getting there.
What are some alternatives?
supabase - The open source Firebase alternative.
cloudscraper - A Python module to bypass Cloudflare's anti-bot page.
powerproto - 🎉 An awesome version control tool for protoc and its related plugins.
vouch-proxy - an SSO and OAuth / OIDC login solution for Nginx using the auth_request module
readyset - Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
zig - General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
grpc-gateway - gRPC to JSON proxy generator following the gRPC HTTP spec
sea-query - 🔱 A dynamic SQL query builder for MySQL, Postgres and SQLite
gogoprotobuf - [Deprecated] Protocol Buffers for Go with Gadgets
polars - Dataframes powered by a multithreaded, vectorized query engine, written in Rust
parthenon - The Symfony SaaS boilerplate
Replibyte - Seed your development database with real data ⚡️