Hacker Newsnew | past | comments | ask | show | jobs | submit | tilyupo's commentslogin

I’ve been building a self-hosted configuration manager that lets you tweak your software without running scripts or building your own admin panel. Store feature flags, rate limits, timeouts, UI text, and app settings without redeploying your code.

The main idea: you store configs in Replane, your apps connect via SDK, and changes propagate in real-time via Server-Sent Events. No more PRs and CI pipelines just to flip a feature flag or change log level.

SDKs available for JavaScript, React, Next.js, Svelte, Python, and .NET – all with type safety and real-time updates.

Github repo: https://github.com/replane-dev/replane


I would love to hear your feedback in the dynamic config sdk design and your use cases


Thanks! I miss Entity Framework too, one of the best ORMs out there.


Yep, I would love to use plain "==" and "+", but JS doesn't support it.


You can achieve some hacky form of operator overloading by implementing the “well-known” Symbol.toPrimitive, and exploiting the fact that the addition operator coerces its operands to either a Number or String.

It won’t be perfect but maybe you can do something useful with it. Symbols in general are a really powerful tool that almost enable meta-programming in JS. I searched “Symbol” in your repository and didn’t see any results, so if you aren’t familiar with them, I recommend taking the time to read up on how you can use them.

See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

And this 2015 blog: https://www.keithcirkel.co.uk/metaprogramming-in-es6-symbols...


I've seen (and implemented myself) operator overloading based systems for query builder type things ... and the way such facilities work in every language I've seen/tried them in has had enough limitations that it wasn't really a great idea in the end anyway.

https://p3rl.org/DBIx::Perlish does it pretty nicely, but only because instead of using operator overloading the author lets the query code compile as a lambda and then pulls apart the perl5 VM opcodes and translates -those- into a query, which is ... awesome in its own way but not something you'd want to try and reproduce.

Interestingly, Scala actually turns 'x + y' into 'x.+(y)' and you could maybe get somewhere with that style.

For javascript, you'd probably need instead to provide a Babel transform and rely on the fact that like 90%+ of javascript projects are already 'compile to javascript' code except that the source is also sort of javascript.

My plan instead is to have an API much like yours (... or possibly just (ab)use yours, see my other comment ...) and then a format string based DSL for nicer querying.

... now that I think about it, making the DSL I have in mind work with qustar might be a good "dual implementations keep you honest" thing, but I have a lot of yaks to shave before that becomes relevant, so please nobody hold your breath.


Same, I hope Qustar will provide better developer experience than raw SQL without sacrificing flexibility.


I've big plans for Qustar, thanks for kind words!


Qustar parametrizes all queries by default, so it's immune to SQL injections. I'll add info about that with examples to the docs, thank for the feedback!


It was more of an ergonomics choice. To me it seems like it's more readable to write `await users.filter(user => user.id.eq(42).fetch(connector)` instead of `await connector.fetch(users.filter(user => user.id.eq(42))`.

But I might be wrong, your idea makes more sense from logical perspective.


What about moving the connector to the table declaration, similar to dbcontext in .net?

Something like Q.table(definition, connector), which would then allow you to just write users.filter(user => user.id.eq(42).fetch()


I’m not sure I can say which is _objectively_ better, but I was also surprised, connector.fetch would be more consistent with common JS practices


I agree, classic ORMs usually don't play well with complex queries.

I think Qustar is closer to a query builder than ORM tbh. You can compose arbitrary queries using it.


People have often said of https://p3rl.org/DBIx::Class that's it's more a Relational to Object Mapper than an Object to Relational Mapper.

We've (I was the original author, bias alert) always had a policy of "if you can't convince it to produce the exact same query that you'd've written by hand, that's either a bug or a missing feature."

Some of said features do still remain missing, because of course they do, but the attitude is hugely important nevertheless.

You're doing an awesome thing here, and ... I've been considering trying to write a better ROM for JS on and off for a while, and though I may still do so anyway, assuming my sieve-like brain doesn't forget about qustar first I think I should really talk to you about whether we can work together instead before I strike out on my own.


Exactly! Qustar was heavily inspired by EF.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: