May sound boring and small but it is a burning problem I'm solving today, we're adding SSO or single sign-on to Tesults ( https://www.tesults.com ) - long overdue and requested at this point by many teams. Hope to have it done by next week. Not as grandiose and admirable as Space X and Neural Link but in a small way we do make the world a better place, we even have a promise, giving open source developers, small team…
Ask HN: Which burning problem you'll solve today?
11–15 of 15 posts
Re: Ask HN: Which burning problem you'll solve today?
#122. Always wanted a type-safe way to construct efficient SQL queries building bottom-up as in SQL rather than left-to-right as in ORMs[2].
3. A framework using (1) and (2) so building backends are not time-consuming or error-prone. Still in early stages.
[0] https://github.com/karmakaze/moja
Re: Ask HN: Which burning problem you'll solve today?
#13May sound boring and small but it is a burning problem I'm solving today, we're adding SSO or single sign-on to Tesults ( https://www.tesults.com ) - long overdue and requested at this point by many teams. Hope to have it done by next week. Not as grandiose and admirable as Space X and Neural Link but in a small way we do make the world a better place, we even have a promise, giving open source developers, small team…
Re: Ask HN: Which burning problem you'll solve today?
#141. Experimenting to see if a practically useful monad library can be made for a popular statically-typed language: Java[0] or TypeScript[1] 2. Always wanted a type-safe way to construct efficient SQL queries building bottom-up as in SQL rather than left-to-right as in ORMs[2]. 3. A framework using (1) and (2) so building backends are not time-consuming or error-prone. Still in early stages. [0] https://github.com/kar…
Re: Ask HN: Which burning problem you'll solve today?
#151. Experimenting to see if a practically useful monad library can be made for a popular statically-typed language: Java[0] or TypeScript[1] 2. Always wanted a type-safe way to construct efficient SQL queries building bottom-up as in SQL rather than left-to-right as in ORMs[2]. 3. A framework using (1) and (2) so building backends are not time-consuming or error-prone. Still in early stages. [0] https://github.com/kar…
Number 2 seems particularly useful for devs, As they are ones who suffer most of writing complex SQL queries using "ORM".
I do have to admit that it is awfully convenient to use a REPL to write a long chain query using an ORM. I do often run into limitations, and knowing that the solution in plain SQL is so simple is very annoying. The idea is to allow convenient composition, but following the structure of SQL rather than parent-children navigation so there aren't paint-yourself-in-a-corner cases.