Apache Thrift
deno
Our great sponsors
Apache Thrift | deno | |
---|---|---|
10 | 446 | |
10,097 | 92,681 | |
0.4% | 0.7% | |
8.9 | 9.9 | |
7 days ago | 1 day ago | |
C++ | Rust | |
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.
Apache Thrift
-
Symfony in microservice architecture - Episode I : Symfony and Golang communication through gRPC
There are various notable implementations of RPC like Apache Thrift and gRPC.
- What is gRPC popularity? I believe not very popular. And subreddit is small. Why is that?
-
Fresh – The next-gen web framework
> "Most of the logic inside the form has to be written two times: in PHP and in vue"
That's just your choice of how to build your app, right?
For an internal-facing employee tool - you could've just gone with rendering templates on the server and sending static HTML to the client. Have the business logic and validations take place on the server-side too. I'm sure you have your reasons for doing things the way you did, but it's not like there's only one way to build something like this.
> "Most enum types are repeated"
Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/
> That's just your choice of how to build your app, right? You could've avoided this by rendering templates on the server and sending static HTML to the client, keeping the business logic on the server.
No, that's a requirement on most business cases, my comment stated 'complex and dynamic web apps'. Re-rendering the whole page everytime the user checks a box or clicks a button is (a) terrible UX, (b) hard to track the state between page refresh, (c) wrong practice and (d) bad performance.
> Here's just one of ten-thousand other battle-tested options you can use: https://github.com/apache/thrift/
Sure, I should setup a complex and huge dependency for just one of the many problems I highlighted. What a great idea
- Ask HN: Who Wants to Collaborate?
-
Deadline Budget Propagation for Baseplate.py
Thus, we released Baseplate.py v2.1 with deadline propagation. Each request between Baseplate services has an associated THeader, which includes relevant information for Baseplate to fulfill its functionality, such as tracing request timings. We added a “Deadline-Budget” field to this header that propagates the remaining timeout so that information is available to the following request, and this timeout continues to get updated with every new request made. With this update, we save production costs by allowing resources to work on requests awaiting a response, and gain overall improved latency.
-
parquet2 0.3.0, with native support to read async
The biggest addition is native async reading via futures::AsyncRead and futures::AsyncSeek, which required a lot of (to be merged) changes upstream (changes to thrift rust compiler and parquet-format-rs). I placed those changes on a temporary crate until things are released there.
- proposal: expression to create pointer to simple types #45624
deno
-
I have created a small anti-depression script
Install Node.js (or Bun, or Deno, or whatever JS runtime you prefer) if it's not there
-
Unison Cloud
So as an end user it's kind of like https://deno.com/ where you buy into a runtime + comes prepacked with DBs (k/v stores), scheduling, and deploy stuff?
> by storing Unison code in a database, keyed by the hash of that code, we gain a perfect incremental compilation cache which is shared among all developers of a project. This is an absolutely WILD feature, but it's fantastic and hard to go back once you've experienced it. I am basically never waiting around for my code to compile - once code has been parsed and typechecked once, by anyone, it's not touched again until it's changed.
Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Union system but 3rd party plugins (stuff interacting with the OS or other libs).
-
Deno in 2023
~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again!
The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.
-
Mini site for recommending songs using Svelte & Deno
Behind the scenes is a simple Sveltekit-powered server function to fetch a Spotify client token then find a user's recommendation playlist and its track information. A Deno edge function to performs this data fetch and renders server-side Svelte.
-
Supercharge your app with user extensions using Deno JavaScript runtime
If your application is written in JavaScript, integrating it with JavaScript extensions is a no-brainer. However, Secutils.dev is entirely written in Rust. How would I even begin? Fortunately, I recently came across an excellent blog post series explaining how to implement your JavaScript runtime in a Rust application with Deno:
Protecting against memory-hungry scripts in Deno is more challenging. I won't go into details about how it works and instead direct you to the issue in the Deno repository with all the details. In short, you need to create a JavaScript runtime with a specific heap limit and add a callback that's invoked when the memory limits are approached. This gives you a chance to terminate the execution before Deno/V8 crashes the entire process.
- Oxlint – written in Rust – 50-100 Times Faster than ESLint
-
Deno Cron
I found the code for that here: https://github.com/denoland/deno/tree/v1.38.3/ext/cron
Thank you for the detailed feedback. Deno 1.38.4 was just released with a partial fix for the VSCode issue you mentioned. We're fixing the twisted issue too.
This is being worked on: https://github.com/denoland/deno/issues/21122. Should be available with the next Deno release.
What are some alternatives?
gRPC - The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)
ASP.NET Core - ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
typescript-language-server - TypeScript & JavaScript Language Server
ZeroMQ - ZeroMQ core engine in C++, implements ZMTP/3.1
Cap'n Proto - Cap'n Proto serialization/RPC system - core tools and C++ library
pnpm - Fast, disk space efficient package manager
Protobuf - Protocol Buffers - Google's data interchange format
esbuild - An extremely fast bundler for the web
bun - Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
Apache Avro - Apache Avro is a data serialization system.
Koa - Expressive middleware for node.js using ES2017 async functions
Apache Parquet - Apache Parquet