We put a Redis server inside our runtime

(encore.dev)

30 points | by eandre 3 days ago

7 comments

  • sudowood0 12 hours ago
    > 25,000 lines of Rust

    I'd really like to understand why they didn't just also have a small container for this running. The only reasoning given in the article is "another container to run and manage" which Docker compose, TestContainers, etc will make trivial.

    If a dev came to me and suggested we go this route I would need to seriously be convinced. They even explicitly call out this is only for local development meaning it's not like this was piggy-backing off of a secondary need for a Rust redis anyways. Insanity.

    • pram 11 hours ago
      Yeah I agree completely, especially because Redis is one of the easiest things to set up. This feels like the wages of tokenmaxxing lol
      • luckystarr 10 hours ago
        There is a difference between easy to set up and not having to set up anything. It's an improvement in operational UX.
        • jagged-chisel 9 hours ago
          There's a difference between easy to set up and (creating 25,000 lines of code to maintain so that we're) not having to set up anything.

          I'd call it a net loss.

    • pjmlp 1 hour ago
      But then you would not have a reason to write a blog post about how cool the company happens to be. /s
    • ahmetson 5 hours ago
      Programming is a craft. People like to write things, so you have plenty of solutions: programming languages, frameworks, game engines and more this kind of tool.

      It’s not bad that they port redis into code. It’s not good thing neither. I’m just worried will they maintain it, did they think about further development that it will take their time, money and energy.

  • drdexebtjl 8 hours ago
    > Tests exercise a real Redis server rather than a mock, so the command behavior a test depends on is the behavior it will meet in production.

    No, they don’t. They exercise an alternative in-process implementation that is supposed to behave like a real Redis, but will not.

    > In production Encore provisions a real, managed Redis, because the embedded server is a development fixture and is not built to scale.

    Ah! So you do see how it does not behave identically to a real Redis.

    This sounds like a terrible idea. Now they’re stuck forever maintaining an alternative Redis implementation, and it isn’t even useful in production.

  • nitwit005 2 hours ago
    They didn't want a mock because it might behave differently:

    > or to replace it with a mock, which only behaves like Redis until your code relies on something the mock implements differently.

    But, then, what they built did apparently behave differently:

    > To guard against that, we test the Rust server against the implementation we ported from.

    > Running the reference suite this way surfaced differences that would be easy to miss otherwise.

  • iwantitez 8 hours ago

      const cache = {}
    
    Look I made a redis server
  • sshine 11 hours ago
    Rewriting Redis in Rust sounds genuinely useful when you want to rely on it as a library.

    Maintaining byte-for-byte parity with newer versions of Redis sounds like being in debt; why not rely on your fork instead?

  • Ozzie-D 10 hours ago
    [flagged]
  • khurs 11 hours ago
    If you look at what CloudFlare did - when they were unhappy with Nginx, they re-wrote their own proxy in Rust, one wonders if this company could instead have 'porting' reddit, started afresh?

    Reddit is from 2009 so must have lots of technical debt over the years? and could have been an opportunity to start afresh? They may have have ended up with a better product!!