51–60 of 71 posts
Does anyone know what this RSAL license’s impact is for internal tools (e.g log analysis)?
Redis as a pure in-memory store (caching) engine just doesn't make as much money as "analytic system". I don't have a problem with this as they have to make money somehow.
The redisgraph functionality is really cool, it makes it an interesting choice over SQLite for small data science projects. The search functionality also is helpful for data science projects. Does anyone know what this RSAL license’s impact is for internal tools (e.g log analysis)?
As long as this log analysis is part of the production environment of your application, and you don't resell it as a tool, that should be fine.
What a crazy mess of services, so sad to see. redis was such a beautiful, elegant and pragmatic code base that was extremely effective at what it does. It looks like they are trying their hardest to make it more enterprisy to squeeze every last cent out.
Earlier quoted context omitted.
Just develop for an interface, instead of an implementation. Migraring data is no fun, but much more straightforward than rewriting a good part of your code when you decide to switch database.
Is there any example of this ever working in practice in the history of computing? As in, we built a large, stable service with datastore X, but we were forward looking enough to make sure that we only "developed to an interface" and we successfully swapped to datastore Y without significant code changes?
For instance, to create a "User" we need the PutItem API from DynamoDB [1]. Similarly, to retrieve a "User", there's the GetItem API [2].
Instead of making references to these APIs all over our codebase, we have a single `db-interface` module, which implements `get_user` and `create_user` functions. Each of these functions has an interface: they expect specific arguments with corresponding types. This interface is modeled against our data domain, not DynamoDB data domain quirks.
Inside the `db-interface` module, we implement the conversion from our data domain to Dynamo's. We also have general-purpose functions, like `create_item` and `get_item`, so that `get_user` and `create_user` are pretty much wrappers and only serve the purpose of defining the interface for interacting with the "User" data object.
The rest of our code only interacts with our internal interface, never with DynamoDB APIs directly.
If we were to switch database, we only need to re-implement the general-purpose functions (e.g. `create_item`, `get_item`).
May sound like a lot of work, but it took only a handful of days to implement the entire interface mapping everything we needed from DynamoDB.
Hope this helps clarifying a bit the application of this concept (develop for an interface, not an implementation) in the context of interacting with databases.
[1] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...
[2] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...
Earlier quoted context omitted.
It's the hot take culture. Some people see internet forums as a vessel to unleash their toxicity.
I don't see how it's 'toxic' to express dissatisfaction with mission creep in a piece of software. It's a totally normal, reasonable criticism, and from the author's point of view is far more useful than their staying silent.
Earlier quoted context omitted.
Is there any example of this ever working in practice in the history of computing? As in, we built a large, stable service with datastore X, but we were forward looking enough to make sure that we only "developed to an interface" and we successfully swapped to datastore Y without significant code changes?
The project I'm currently working uses AWS DynamoDB as primary DB. Since it's proprietary, we ensure the AWS-specific APIs are contained in small and specific part of the codebase. For instance, to create a "User" we need the PutItem API from DynamoDB [1]. Similarly, to retrieve a "User", there's the GetItem API [2]. Instead of making references to these APIs all over our codebase, we have a single `db-interface` mod…
Instead a lot of product start out that way and then if it becomes popular scope creep rears it ugly head and it is extended to be mediocre at many things.
I find far too many developers once they start investing time in a product they want it to do all sorts of other things that there are allready tools that do it well.
Worth a watch for sure
What a crazy mess of services, so sad to see. redis was such a beautiful, elegant and pragmatic code base that was extremely effective at what it does. It looks like they are trying their hardest to make it more enterprisy to squeeze every last cent out.
Doesn't seem like that has changed to me