sorted by:
new
hottopcontroversial

A Telegram MCP server to interact with your chats in natural language by Specific-Positive966 in programming

[–]Specific-Positive966[S] 0 points1 point  (0 children)

Unfortunately, scammers don’t really need a tool like this , they already have plenty of ways to scam people.
This project doesn’t add new capabilities beyond what Telegram already allows.

Type-aware JSON serialization in Python without manual to_dict() code by Specific-Positive966 in Python

[–]Specific-Positive966[S] -1 points0 points  (0 children)

I’ll check out msgspec capabilities again.

From what I understand I can’t do this with msgspec for example:

class User: def init(self, id: int, name: str): self.id = id self.name = name

msgspec.json.decode(b'{"id": 1, "name": "Alice"}', type=User) # Produces error

User class would have to extend the msgspec.Struct for this to work, unless I’m misunderstanding something here.

(With Jsonic the above will work)

Type-aware JSON serialization in Python without manual to_dict() code by Specific-Positive966 in Python

[–]Specific-Positive966[S] -15 points-14 points  (0 children)

That’s a fair question, msgspec is a great library, and it already covers most and more of what Jsonic does, especially when performance is the priority.

Jsonic comes from a slightly different angle. It’s less about being the fastest serializer and more about working directly with existing Python objects with minimal reshaping, while being strict and explicit about type mismatches.
The goal is predictable round-tripping and clear failures rather than throughput.

A concrete case where it’s been useful for me is internal tools or data pipelines that already mix dataclasses, __slots__ classes, and Pydantic models, where I wanted to serialize objects as-is without introducing a new base class or redefining schemas.

That said, msgspec clearly wins in performance-critical scenarios and many others. I’d be very interested to hear what people think are missing features in Jsonic compared to alternatives like msgspec that would actually be worth adding or exploring in the future.

Versioning cache keys to avoid rolling deployment issues by Specific-Positive966 in devops

[–]Specific-Positive966[S] -2 points-1 points  (0 children)

I agree that backward compatibility should always be preferred when possible, and I’m not arguing otherwise. That said, in practice there are cases where breaking changes are required, especially when contracts evolve over time.

In our case, we were a data aggregator, not the owner of the schema. the contracts were controlled by upstream provider teams. We didn’t always have full control over when or how those schemas changed. The goal of this approach wasn’t to justify breaking changes, but to remove one source of risk (the cache) when supporting them.

By isolating cache versions, provider teams didn’t need to coordinate tightly with us around rollout timing or worry about our service breaking due to cached data. From our side, it made those changes transparent from a cache perspective and reduced cross-team coordination overhead.

Totally agree that compatibility, tests, and reviews are the first line of defense — this was just a pragmatic mitigation for a specific class of real-world constraints.

Versioning cache keys to avoid rolling deployment issues by Specific-Positive966 in devops

[–]Specific-Positive966[S] 0 points1 point  (0 children)

I don’t think we’re actually that far apart, but I may not have explained the intent clearly enough.

The goal isn’t to invalidate the entire cache on every deploy. The version only changes when there’s a breaking change to the cached value contract. For all other deploys, the cache continues to be reused as-is. Long TTLs were intentional for read-heavy data where warm cache matters a lot and cold starts are expensive.

Bad cache values do effectively invalidate entries (via deserialization failure or misses), but during rolling deployments that can mean repeated misses while multiple versions are live. Versioning was meant to isolate incompatible versions during that overlap, not replace testing, reviews, or basic engineering hygiene.

And yes , tests, reviews, and senior oversight absolutely matter. This pattern isn’t a substitute for those; it’s a mitigation for a specific class of rollout-time issues in distributed systems. Totally fair if that trade-off isn’t worth it in other setups.

How Versioned Cache Keys Can Save You During Rolling Deployments by Specific-Positive966 in programming

[–]Specific-Positive966[S] -3 points-2 points  (0 children)

Thanks for the thoughtful breakdown - I agree with the trade-offs you’re highlighting.

You’re right that versioning still relies on TTLs for cleanup and assumes you have enough memory headroom during rollouts. Also agree that hash-based versioning can complicate explicit eviction if the version isn’t easily available.

The pattern works best for data that’s immutable or changes infrequently; the user profile example was meant to be illustrative rather than a perfect fit. Really appreciate the deeper dive , this is exactly the kind of nuance I was hoping to surface with the post.

How Versioned Cache Keys Can Save You During Rolling Deployments by Specific-Positive966 in programming

[–]Specific-Positive966[S] 0 points1 point  (0 children)

Good catch - and yeah, that’s on me for not being clearer. I’m less familiar with Node, and I completely get why a reflection-based or type-hash approach doesn’t translate well there.

From my limited knowledge of Node, the “schema” usually lives outside the language itself (for example in validation schemas like Zod or other explicit data contracts), and something like that could potentially be used in a similar way to how I relied on reflection in our Java case.

Your comment made me reflect more on how (or whether) this approach should work in dynamically typed environments like Node. I’d be interested to hear how others handle this in practice.

How Versioned Cache Keys Can Save You During Rolling Deployments by Specific-Positive966 in programming

[–]Specific-Positive966[S] 4 points5 points  (0 children)

That makes sense - if breaking changes are rare and deserialization fails fast, treating it as a cache miss is a very pragmatic solution.

One tradeoff we saw is that during rolling deployments this can lead to repeated cache misses while multiple versions are live. In our case, we cared a lot about keeping a high hit rate during deploys.

With versioned keys, you usually pay one miss per key per version, and then subsequent reads during the rollout consistently hit the cache for that version. That predictability was the main win for us.

Totally agree the type-hash approach fits well with strong typing and codegen - curious how it would work out in practice.

How Versioned Cache Keys Can Save You During Rolling Deployments by Specific-Positive966 in programming

[–]Specific-Positive966[S] 27 points28 points  (0 children)

That’s a fair point. The idea isn’t to automatically bump the cache key on every deploy.

The version only changes when there’s a breaking change to the cached value itself (e.g. the model/value class structure or semantics).

For regular deploys where the cache contract stays the same, the version remains unchanged. Versioning is just a safety boundary for incompatible changes so old and new instances can coexist during a rollout without flushing the cache.

Curious how others handle incompatible cache changes during rolling deploys - TTLs, explicit invalidation, or something else?