43 ms·

Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

220 points by Seb-C 6y ago

Seb-C 6y ago
For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This is the result of my experiments. This is a completely new balance between productivity, simplicity and readability, while providing useful features. I use the template-string tagging syntax to allow writing and concatenating raw SQL queries, while keeping it safe from injections, which allowed me to build kiss-orm. There is no query-building involved, you can freely use the full-power of SQL. I would appreciate feedback on this (and contributions if you love it :D ).
- waheoo 6y ago
  Still not very convinced your ORM is solving a problem it didn't create but I certainly like the approach more than more traditional ORMs. I feel like Im not really the type that wants an ORM to take care of SQL or relational functionality, all I really want is an object mapper at the edges, going in, I want to pass an object and have it map into the right fields, coming out, I want it mapped to the right place. Doing stuff like preloading or relation loading should be done through convention or by database schema querying. Its a tricky problem to solve, while some relational mapping is super helpful to prototype it almost always results in a mess down the line where just writing SQL upfront prevents pain later.
  - twodave 6y ago
    I sort of agree here. I tend to stay away from ORMs in general, but I'd probably use one if it actually justified itself. Most ORMs I've used basically just abstract the data layer so you don't have to write own SQL, but that in itself comes at a cost (and almost all of them are bound to eventually write some really crappy SQL for you and cause performance bottlenecks). If there's not an appreciable benefit besides just not having to write as much SQL, then it's not really worth using.
    - lemontruth 6y ago
      In one way or other you cannot avoid the SQL builder, this ORM is building it in the user's code base. I believe in ballance, you need the query builder for simple queries (that makes most of your queries) but the complex queries should be also supported (even if they are not portable) We have written exactly this kind of ORM https://github.com/holdfenytolvaj/pogi https://github.com/holdfenytolvaj/pogi It saves you a lot of code writing, but is not taking away the power of postgresql (however it is anchored to postgresql)
  - RandoHolmes 6y ago
    Personally, all I want is something that can dynamically build SQL and can hydrate into specific objects. I have no interest in automatically building relationships, I'm completely fine doing that manually, or not at all. Which is why dapper is probably my favorite DB solution out there. return conn.query<MyKlass>("select * from my_klass_table where status = :status", new { status=myStatus }).ToList(); The only thing that can be bothersome sometimes is inserts and updates. It would be really nice to have something that could auto-generate the SQL for you. var sql = SQLGenerator.insert(MyObject); or var sql = SQLGenerator.insert(MyObject, MyKlass.InsertableProperties); It would take care of one of the downsides of raw SQL, which is schema updates needing to be dealt with in multiple places, and would remain super simple. I mean hell, if you wanted to get fancy you could create a generator that would figure out the columns necessary by reaching out to the DB the first time and caching it afterwards, and using a naming convention to map to the actual properties. But personally, I'm 100% fine not having that.
  - electrum 6y ago
    Jdbi works the way you describe: https://jdbi.org/ https://jdbi.org/
    - EdwardDiego 6y ago
      Yep, I've been enjoying JDBI for a new microservice. /me makes sign of cross and throws holy water on legacy Hibernate code it's replacing.
- twodave 6y ago
  This is great. I built something a bit lower-level than this targeting MySQL not long ago. This library has taught me a couple language features I didn't know, however. The SQL tag is pretty clever. I was pleasantly surprised to see transaction support (I feel like people who don't actually use their libraries in real products tend to leave this kind of thing out). I noticed the support for soft-delete (which seems to be a simpler thing in PgSql than in other relational db systems), which is also nice. I think another fairly easy, generic win would be a way to specify that a model has audit tracking fields (createdAt/By, modifiedAt/By, deletedAt/By, etc.). I know some database servers also have a way to track this separately (no idea whether PgSql specifically does), but there are use cases for showing that kind of stuff at an application level as well (and also can make ETL type jobs a bit less painful). All in all, great work. It looks very polished!
  - Seb-C 6y ago
    Thanks! It was a bit tricky to solve the transactions problem, because I did not want to abstract the BEGIN / COMMIT / ROLLBACK instructions, but at the same time I needed to provide something to ensure the integrity of a transaction made of multiple commands. As for the audit fields, I decided not to include it because it very simple to implement, and would be clearer to do it specifically. Most of those fields could be implemented by just adding a default value in the right function.
    - twodave 6y ago
      Another interesting way to solve the transaction problem is following more of a Unit of Work pattern. Then the transaction is more or less held until the unit is committed. Or rolled back. This is also wonderful for writing integration tests because your repositories all contribute to the same UoW and your test can just roll back when it’s finished to return to a clean state.
- arethuza 6y ago
  "you can freely use the full-power of SQL" Sounds like Dapper from the .Net world - which I like precisely for that reason: https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper
  - twodave 6y ago
    OP's project is a little more opinionated than Dapper in that it defines repositories and whatnot. Dapper's more like just a set of query extensions that support basic object mapping. I love it personally, but I wouldn't even call it a micro-ORM.
    - exevp 6y ago
      It might be a good idea to focus on the use of template strings for safe and handy SQL generation instead of introducing too many opinionated ORM concepts. If one had to, i'd separate these things in different libraries and let the developer opt in to what he needs.
      - Seb-C 6y ago
        That is something I seriously considered, but I just did not want to bother with multiple packages and repositories, especially for a repository class that is about 150 lines of code. The repository class that I provide is a very basic and handy abstraction for the 4 basic CRUD operations, but ultimately the goal is to write your own queries and repositories.
      - __ryan__ 6y ago
        Thankfully [0], it [1] already [2] exists. [3] [0] https://github.com/gajus/slonik-sql-tag-raw https://github.com/gajus/slonik-sql-tag-raw [1] https://github.com/felixfbecker/node-sql-template-strings https://github.com/felixfbecker/node-sql-template-strings [2] https://github.com/blakeembrey/sql-template-tag https://github.com/blakeembrey/sql-template-tag [3] https://www.npmjs.com/search?q=sql%20template https://www.npmjs.com/search?q=sql%20template Edit: When I first read your comment, I thought you were saying that you wanted a separate library just to have the SQL template functionality. I agree with what you're saying though.
- exevp 6y ago
  tl;dr: thank god it finally has been done. Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years. Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregations or stuff like window functions and the likes, you most certainly have to fallback to raw queries, usually rendering the whole mapping function of the ORM completely useless. Also projects like Knex.js (or for example HQL in the Java world) look nice at first but are mostly useless IMHO because they just replace SQL with another syntax you have to learn. Why stay with the language everybody familiar with RDBMS can speak if you can invent some useless abstraction, right? And please don't tell me you want to support multiple RDBMS in the same codebase. How often is this really an important use-case? I really loved the way MyBatis did this in Java: instead of mapping tables to objects, mapping result sets to objects and leaving the full power of SQL to the developer. Always wanted (and actually started something almost the same as you did some weeks ago) to basically do MyBatis in Javascript and never had the time to. Thanks for getting it started.
  - areactnativedev 6y ago
    Very surprised by the no value you attach to Knex, I'm curious to get your view on the values I see in using it for a few years now. I feel at ease with SQL and like to get as close to it as possible in my Node service. But Knex still appears to be highly valuable to me to, for instance, not care about managing DB connections, at least until they become critical for my use-case. Not care about sanitising inputs and protecting myself from SQL injections. Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains. Not care about creating and maintaining code for migrations. Running them in transactions, keeping track of and running only the ones needed, ... so happy I didn't have to re-invent that and be the responsible of it never ever failing in production.
    - exevp 6y ago
      > not care about managing DB connections, at least until they become critical for my use-case. That's something the db driver usually does. E.g. when using Postgres, the pg library already comes with the connection pooling. Haven't looked into the implementation in Knex but i'd suspect they just use the Pool class of pg (https://node-postgres.com/features/pooling https://node-postgres.com/features/pooling). > Not care about sanitising inputs and protecting myself from SQL injections. That's also not that much of a concern when just binding parameters. > Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains. Comes with the cognitive cost of maintaining another abstraction for SQL. > Not care about creating and maintaining code for migrations. That's actually the one feature which made me use Knex for years (just for the migration part of course :) ). I didn't use the schema builder functions mostly, just a bunch of `knex.raw` calls in the migration files. But for the benefits you mentioned (transactions, bookkeeping) it is really useful.
- marius_k 6y ago
  thanks. I love it! It is not clear where the `article.id` comes from in many-to-many example. Anyway I don't think I would use those relationships patterns, instead I would just load and operate in plain (shallow) model objects.
  - Seb-C 6y ago
    Thanks! It was a copy/paste mistake. I just fixed the README file.
- deleted 6y ago
  [deleted]
- gmac 6y ago
  My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/ Previous discussion: https://news.ycombinator.com/item?id=23273543 https://news.ycombinator.com/item?id=23273543
  - intellix 6y ago
    thought this looked awesome when I saw it. Was waiting for a little more traction, my project to calm down and perhaps some GQL helpers to appear before jumping on board (not requesting them but just naturally picked up by the community)
    - gmac 6y ago
      Glad to hear it! Presumably GQL is GraphQL, which so far I have let completely pass me by. How would those helpers look, roughly?
  - skrebbel 6y ago
    Zapatos is amazing. I'd definitely use it if I were writing Node backends, I think its design is wonderful. Also, I'm impressed by how beautiful and interactive your docs are. How did you do that? The show imports button, the embedded monaco modal.. Did you just code that up yourself just for these docs, or is this "just" some nice documentation template that I'm not aware of? Either way, very nice!
    - gmac 6y ago
      Thanks. I just coded it up myself[1]. :) As an educator, I’d say the docs are probably the most important element of a library. [1] https://github.com/jawj/zapatos-docs https://github.com/jawj/zapatos-docs
  - ummonk 6y ago
    Wow this is amazing. Really bridges the last remaining gap to close the type-safety gap from SQL -> TS/Node.JS -> GraphQL -> TS / client code. Exactly the kind of "use SQL in typescript code with type-safety" non-ORM that I've always wanted.
- mqus 6y ago
  What do you think about ORMs like Androids Room[1], where you do specify your own queries with sql (by annotating abstract methods) and can bring your own model and the ORM creates the database schema in the database and gives you access to easy insertion methods. I don't know how Room does it but darts floor library(which is similar)[2] then generates the code that is necessary, in addition to a very slim runtime layer for managing update events. I find that this is also an approach which in some ways only does half the work for more flexibility, while still depending on a fixed database schema. [1] https://developer.android.com/training/data-storage/room https://developer.android.com/training/data-storage/room [2] Shameless plug: https://github.com/vitusortner/floor https://github.com/vitusortner/floor
  - Seb-C 6y ago
    Thanks. I do not have experience with Room, but I usually prefer to control and know what is happening in my schema. For example, if your schema is automatically handled, how do you both rename and change the type of a column without losing data? Would it perform a delete and a create?
    - mqus 6y ago
      Only the creation is handled automatically. Room helps with migrations by enforcing a database version but you will have to write the migration code(sql) yourself.
- axlee 6y ago
  I'm extremely happy with Django's ORM. It never felt bloated or overcomplicated to me, especially when compared with the innate verbosity and complexity of SQL.
- Juliennng 6y ago
  I've been playing with tagged-template for a while now and have a similar solution at work. I wanted to build something like that for a while now, well done! I wrote about tagged template literal on my website : https://cavaleiro.fr/posts/template-literals/ https://cavaleiro.fr/posts/template-literals/
- thunderbong 6y ago
  In Ruby, I have always been extremely fond of the Sequel ORM - http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/ The amount of expressiveness and capability it gives is simple outstanding. It lets me drop into pure SQL as well as write statements which are simpler and easire to grok when I'm using the ORM level abstractions. Sequel for SQL users - http://sequel.jeremyevans.net/rdoc/files/doc/sql_rdoc.html http://sequel.jeremyevans.net/rdoc/files/doc/sql_rdoc.html Cheat sheet - http://sequel.jeremyevans.net/rdoc/files/doc/cheat_sheet_rdoc.html http://sequel.jeremyevans.net/rdoc/files/doc/cheat_sheet_rdo...
capnorange 6y ago
still yet to find an ActiveRecord equivalent for javascript.
- racedude 6y ago
  What about this? https://github.com/typeorm/typeorm/blob/master/docs/active-record-data-mapper.md#what-is-the-active-record-pattern https://github.com/typeorm/typeorm/blob/master/docs/active-r... (Forgive me if this isn't what you are looking for, not super familiar with ActiveRecord myself, just recalled seeing that yesterday!
  - jdauriemma 6y ago
    Yes, TypeORM is definitely the JavaScript answer to ActiveRecord
    - agustif 6y ago
      Can vouch for TypeORM, hopefully it's creator will pick it back up soon and get it to a stable v1.0.0!!
  - benatkin 6y ago
    I like TypeORM but have passed on it for now because of this potential sql injection issue: https://github.com/typeorm/typeorm/issues/3740 https://github.com/typeorm/typeorm/issues/3740 I have passed a field to order_by() from the user in Django before. I would be more likely to use a dict now, but I shudder at the thought of accidentally creating an SQL injection bug because I expected to be protected by my ORM.
  - Thomaschaaf 6y ago
    https://mikro-orm.io/ https://mikro-orm.io/ is a much better typeorm alternative as it is actively being maintained. TypeORMs development has come to a halt. And many issues are not being fixed.
- midrus 6y ago
  That's Prisma [1] for me. Coming from Django, I've found prisma even better than the Django ORM, despite not yet as complete. [1] https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma
midrus 6y ago
All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives by a very long shot in my opinion. [1] https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma
- bradstewart 6y ago
  This. I've actually used Rails/ActiveRecord migrations in Node projects. More than once...
- Seb-C 6y ago
  > reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks) IMHO, "real production features" means also caring about the long term maintenance, performance and reliability of the data. My experience with ORMs (especially ActiveRecord patterns) is that it always becomes a mess once you reach a certain level of complexity. It is very fast to get started, but gets slower over time once you start having a lot of bugs and hard-to-solve behaviours.
  - bakedbeanz 6y ago
    Interesting, then what is your alternative? It seems like hand-rolling all of your migrations would be an enormous pain on larger projects.
    - Seb-C 6y ago
      Well, this project is my alternative, and so far I did not see any case where it fails, but I'd be happy to learn. This migration pattern is quite common in many frameworks, I just removed the query-building abstraction layer.
- nicoburns 6y ago
golergka 6y ago
Love to see more options in this space! I've made a switch from traditional ORM (TypeORM and Sequelize) to a similar "light ORM", Pgtyped, and never looked back since. Like in Kiss, you write queries in SQL. But unlike other "light ORMs", it also provides type safety by generating type declarations by directly connecting to your database instance and type-checking your query templates. Honestly, I think it's the best of both worlds, and would love to see more developers finally learning SQL and ditching "fat ORMs" that try to hide it under abstraction layers that always end up leaking.
- davecardwell 6y ago
  I agree. I’ve been using pgtyped for a recent project, along with https://github.com/graphile/migrate https://github.com/graphile/migrate for migrations, and it has been great to just write SQL and not have to battle with an ORM’s abstractions.
CoffeeDregs 6y ago
sql"SOME SQL"; This looks to be a "tagged template": https://basarat.gitbook.io/typescript/future-javascript/template-strings https://basarat.gitbook.io/typescript/future-javascript/temp.... I'm a TS user but hadn't seen that feature before. AFAICT, the library is using a side-side-side-feature (tagged templates) of TS as the core abstraction [1]. Impressive. Might be a little brittle in the face of significant SQL or query composition? Anyhow, I'm a heavier-ORM user but that's impressive. --- [1] https://github.com/Seb-C/kiss-orm/blob/c4b6c9ad2f81337938a9c609b4bc9ef05b08c300/src/Queries/SqlQuery.ts#L10 https://github.com/Seb-C/kiss-orm/blob/c4b6c9ad2f81337938a9c...
- lucideer 6y ago
  Tagged templates are a core feature of JS, not just of TS https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- exevp 6y ago
  Not specific to TS, just one of the modern JS features: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Scroll down to the part explaining how to use custom tags.
- marton78 6y ago
  This is nothing special, it's commonly used e.g. with GraphQL (the `gql` tag).
gigatexal 6y ago
As a never-ORM guy I really like what this is trying to do. It seems like the best of both worlds. Kudos!
- Seb-C 6y ago
  I am glad that it is appreciated! Thank you.
timmy-turner 6y ago
When using raw SQL in strings, I really miss the automatic formatting that is provided for HTML, TSX and TS with prettier. Raw SQL query strings also do not compose well and I miss auto completion when writing them (yes, I'm a spoiled kid after so much Typescript usage). As with everybody else, I didn't like existing ORM/builder approaches, so I built and use my own with type-inference: https://github.com/hoeck/typesafe-query-builder https://github.com/hoeck/typesafe-query-builder. Any feedback would be great because I have the gut feeling that this one has gone way too far on the type astronaut side of things.
- hv42 6y ago
  You should be able to do this with IntelliJ e.g. where you can inject a language into a string. This is quite handy as you can reformat and open the string in a separate editor if needed. The caveat is that it does not work well if you are composing the SQL queries from multiple small parts. see https://www.jetbrains.com/help/idea/running-injected-sql-statements.html https://www.jetbrains.com/help/idea/running-injected-sql-sta... I suppose that other editors or IDE can do similar things.
haakts 6y ago
Seems similar to PureORM[1]. It allows you to write regular native SQL and receive back properly structured (nested) pure business objects. The name pureORM reflects both that it is pure ORM (there is no query builder dimension) as well as the purity of the mapped Objects. [1] https://github.com/craigmichaelmartin/pure-orm https://github.com/craigmichaelmartin/pure-orm
deleted 6y ago
[deleted]
holgerw 6y ago
Thank you for creating Kiss ORM. I have even created a HackerNews account to be able to comment on it. I have been searching for this type of ORM in Typescript for a while. I agree to write raw SQL for queries. So easy and expressive and one less layer of abstraction. I also agree on the value of the respository pattern and methods for CRUD operations to not write this SQL by hand. Making the loading of associations an explicit decision is also the right way to go. The Rails community has good experience with performance surprises of automatic loading of relationships. Personally I found the most useful ORM in Ecto for the Elixir (Erlang) language: https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html (ignoring the query capability). It follows very much the repository pattern like Kiss ORM. The API is a bit more succinct (you only define a schema for each table and use a generic repository instead of subclassing for each table) but that might be possible only due to Elixir's language capabilities like meta-programming. One piece of Ecto that might be a win to implement in Kiss ORM is the "Changeset" pattern to give a canonical, succinct and productive solution to validate data (https://hexdocs.pm/ecto/Ecto.Changeset.html#content https://hexdocs.pm/ecto/Ecto.Changeset.html#content). For example have a look at how Ecto unifies validation (checked without hitting the DB) and constraints (checked by hitting the DB) in a single API. This type of functionality increases the usefulness of the repository's CRUD operations. Thank's for your initiative to create KISS ORM. I will sure try it out and follow along it's evolution.
- holgerw 6y ago
  Just forgot to mention Ecto's "Multi API", that is worth knowing. Allows to construct a chain of operations as a data structure and to execute it later transactionally. You may even include operations that are part of transactional business logic but that do not hit the DB (like sending an email). (https://hexdocs.pm/ecto/Ecto.Multi.html#module-run https://hexdocs.pm/ecto/Ecto.Multi.html#module-run) As I understand KISS ORM's sequence function would also allow to express business logic transactionally and operations beyond the DB. Obviously the rollback would only effect the DB, but other failing operations can at least trigger the rollback, right? I think this is usefull as integration with external services (like email providers, payment APIs..) are really the source of runtime surprise that might fail a business operation and demand a DB rollback.
ryanmarsh 6y ago
This is very nicely done, kudos to the author. I'm sure many will find this useful. Personally I've gotten away from using SQL RDBMSs. Since I primarily build on AWS I use DynamoDB but the same principle would apply elsewhere. I like to store data in the format that best supports the read model. Event sourcing allows me to change the structure of the read model, or add new read models, or vary strategies depending on data, as needed. I like that I no longer have the impedance mis-match of the normalized relational model. It was a big jump to make, and I had to unlearn a lot. I'm not dismissing the value of RDBMSs at all. I love them, especially star schemas for analysis. I just want to share that it's ok to not use an relational model for your transaction store.
LorenzA 6y ago
the template syntax reminds me of an other postgres libary https://github.com/porsager/postgres https://github.com/porsager/postgres
Dragory 6y ago
It seems you cannot load relationships for a collection of entities easily without N+1 queries, unless I'm missing something. Based on the many-to-many section of the docs (https://github.com/Seb-C/kiss-orm#many-to-many https://github.com/Seb-C/kiss-orm#many-to-many), I would have to load relationships for each entity separately, and then if they have further nested relationships, run a query for each again. The subsequent section also mentions eager loading is not supported. For me, being able to load relationships (and especially nested relationships) with little boilerplate and few queries is probably the most useful feature in an ORM (usually explicitly eager-loaded), so I'm sad to see it's not supported.
- WkndTriathlete 6y ago
  Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query analysis tools. Using an ORM just adds extra steps: instead of optimizing a query in SQL, the query needs to be optimized using directives or methods or annotations that the ORM provides in the hope that the SQL that is ultimately generated is efficient; that is, we're programming the ORM which programs the database instead of just programming the database. Why bother with the extra step? With modern programming languages there really isn't that much extra boilerplate to implement the DTOs for straight SQL and it usually results in code that is a lot easier to maintain and extend in the examples I've seen.
  - Dragory 6y ago
    In my experience, 99% of the relationships I fetch fit the basic one-to-one, one-to-many, many-to-many definitions that pretty much all ORMs support. For these cases, the queries are generally more than efficient enough and there's little reason to reinvent the wheel and implement the code for fetching those relationships yourself. For anything more complex, I agree. But for the common case of fetching simple and often (depending on your project) nested relations, I definitely enjoy the abstraction provided by ORMs.
nhumrich 6y ago
I actually built something almost exactly like this internally. This is awesome. But, its a far cry to call this an ORM. Its just a safe query serializer. ORM takes an object and writes the query for you.
blaufast 6y ago
I think its funny that 'opinionated' could be considered a virtue. I'm imagining a charity that uses 'opinionated' to describe itself, or even worse, a person. Even Apple, a brand famous for its strong design stances, does not use that word as a description of its values.
mrmonkeyman 6y ago
SQL is an useful and simple abstraction in and of itself. Stop wasting mental cycles.
wayneftw 6y ago
I started using Objection.js and Knex last year and I think it might be the best ORM I've used on any platform. There's no way I'm going back to writing raw queries. If I did that, eventually I'd rewrite Knex. If and when I need a raw query, I can already do that with Knex.
cryptica 6y ago
History keeps repeating itself. People never seem to learn anything. At first there were no ORMs, then ORMs became extremely popular and everyone was using them, then everyone learned that ORMs were a very bad idea and we stopped using them, vowing never to make the mistake again... And here we are again in 2020, ORMs are back. They will be in for a while, then out again, then in again.... Same with statically typed vs dynamically typed. First everything was statically typed, then dynamically typed (interpreted) languages gained popularity, developers LOVED not having to wait for the compiler to finish to test their changes; this was a revolution... Now again, we're going back to statically typed languages, everyone uses clunky bundling and transpilation tools which add bloat and everyone is happy to wait 20 seconds to a minute for their code to compile. Every few years, developers believe the opposite of what they believed before and the consensus seems to be close to 100% every time. It's ridiculous.
- lemontruth 6y ago
  That is because many people believe in extremes. After a while people should learn that there is no absolute truth, everything has it's place. ORM is good sometimes, pure queries are better on others. So what is needed is more like relaxed ORMS.
- nesarkvechnep 6y ago
  What I've learned from my career so far is that developers hate history. They just don't want to learn from experience. They see the new shiny thing and jump on the hype train. Then they come to conclusions like "mongo was not the right choice since we never needed to scale and our data is relational".
- ben509 6y ago
  That's overly broad. A lot of people jump on the latest trends, especially people who are simply new to development, because there's no way you can know stuff you haven't had time to learn.
nesarkvechnep 6y ago
There's still nothing like Elixir's Ecto in JS land...

220 points by Seb-C 6y ago

For a long time, I have been frustrated with the state-of-the-art about the existing ORMs. I like things to be simple, but somehow all ORMs seems to be bloated and overcomplicate a lot of things. When designing a new project, I have been trying to find a more satisfying design while avoiding the existing ORMs. I especially wanted to use proper SQL rather than reducing it's syntax to fit it in another language. This is the result of my experiments. This is a completely new balance between productivity, simplicity and readability, while providing useful features. I use the template-string tagging syntax to allow writing and concatenating raw SQL queries, while keeping it safe from injections, which allowed me to build kiss-orm. There is no query-building involved, you can freely use the full-power of SQL. I would appreciate feedback on this (and contributions if you love it :D ).

waheoo 6y ago
Still not very convinced your ORM is solving a problem it didn't create but I certainly like the approach more than more traditional ORMs. I feel like Im not really the type that wants an ORM to take care of SQL or relational functionality, all I really want is an object mapper at the edges, going in, I want to pass an object and have it map into the right fields, coming out, I want it mapped to the right place. Doing stuff like preloading or relation loading should be done through convention or by database schema querying. Its a tricky problem to solve, while some relational mapping is super helpful to prototype it almost always results in a mess down the line where just writing SQL upfront prevents pain later.
- twodave 6y ago
  I sort of agree here. I tend to stay away from ORMs in general, but I'd probably use one if it actually justified itself. Most ORMs I've used basically just abstract the data layer so you don't have to write own SQL, but that in itself comes at a cost (and almost all of them are bound to eventually write some really crappy SQL for you and cause performance bottlenecks). If there's not an appreciable benefit besides just not having to write as much SQL, then it's not really worth using.
  - lemontruth 6y ago
    In one way or other you cannot avoid the SQL builder, this ORM is building it in the user's code base. I believe in ballance, you need the query builder for simple queries (that makes most of your queries) but the complex queries should be also supported (even if they are not portable) We have written exactly this kind of ORM https://github.com/holdfenytolvaj/pogi https://github.com/holdfenytolvaj/pogi It saves you a lot of code writing, but is not taking away the power of postgresql (however it is anchored to postgresql)
- RandoHolmes 6y ago
  Personally, all I want is something that can dynamically build SQL and can hydrate into specific objects. I have no interest in automatically building relationships, I'm completely fine doing that manually, or not at all. Which is why dapper is probably my favorite DB solution out there. return conn.query<MyKlass>("select * from my_klass_table where status = :status", new { status=myStatus }).ToList(); The only thing that can be bothersome sometimes is inserts and updates. It would be really nice to have something that could auto-generate the SQL for you. var sql = SQLGenerator.insert(MyObject); or var sql = SQLGenerator.insert(MyObject, MyKlass.InsertableProperties); It would take care of one of the downsides of raw SQL, which is schema updates needing to be dealt with in multiple places, and would remain super simple. I mean hell, if you wanted to get fancy you could create a generator that would figure out the columns necessary by reaching out to the DB the first time and caching it afterwards, and using a naming convention to map to the actual properties. But personally, I'm 100% fine not having that.
- electrum 6y ago
  Jdbi works the way you describe: https://jdbi.org/ https://jdbi.org/
  - EdwardDiego 6y ago
    Yep, I've been enjoying JDBI for a new microservice. /me makes sign of cross and throws holy water on legacy Hibernate code it's replacing.
twodave 6y ago
This is great. I built something a bit lower-level than this targeting MySQL not long ago. This library has taught me a couple language features I didn't know, however. The SQL tag is pretty clever. I was pleasantly surprised to see transaction support (I feel like people who don't actually use their libraries in real products tend to leave this kind of thing out). I noticed the support for soft-delete (which seems to be a simpler thing in PgSql than in other relational db systems), which is also nice. I think another fairly easy, generic win would be a way to specify that a model has audit tracking fields (createdAt/By, modifiedAt/By, deletedAt/By, etc.). I know some database servers also have a way to track this separately (no idea whether PgSql specifically does), but there are use cases for showing that kind of stuff at an application level as well (and also can make ETL type jobs a bit less painful). All in all, great work. It looks very polished!
- Seb-C 6y ago
  Thanks! It was a bit tricky to solve the transactions problem, because I did not want to abstract the BEGIN / COMMIT / ROLLBACK instructions, but at the same time I needed to provide something to ensure the integrity of a transaction made of multiple commands. As for the audit fields, I decided not to include it because it very simple to implement, and would be clearer to do it specifically. Most of those fields could be implemented by just adding a default value in the right function.
  - twodave 6y ago
    Another interesting way to solve the transaction problem is following more of a Unit of Work pattern. Then the transaction is more or less held until the unit is committed. Or rolled back. This is also wonderful for writing integration tests because your repositories all contribute to the same UoW and your test can just roll back when it’s finished to return to a clean state.
arethuza 6y ago
"you can freely use the full-power of SQL" Sounds like Dapper from the .Net world - which I like precisely for that reason: https://github.com/StackExchange/Dapper https://github.com/StackExchange/Dapper
- twodave 6y ago
  OP's project is a little more opinionated than Dapper in that it defines repositories and whatnot. Dapper's more like just a set of query extensions that support basic object mapping. I love it personally, but I wouldn't even call it a micro-ORM.
  - exevp 6y ago
    It might be a good idea to focus on the use of template strings for safe and handy SQL generation instead of introducing too many opinionated ORM concepts. If one had to, i'd separate these things in different libraries and let the developer opt in to what he needs.
    - Seb-C 6y ago
      That is something I seriously considered, but I just did not want to bother with multiple packages and repositories, especially for a repository class that is about 150 lines of code. The repository class that I provide is a very basic and handy abstraction for the 4 basic CRUD operations, but ultimately the goal is to write your own queries and repositories.
    - __ryan__ 6y ago
      Thankfully [0], it [1] already [2] exists. [3] [0] https://github.com/gajus/slonik-sql-tag-raw https://github.com/gajus/slonik-sql-tag-raw [1] https://github.com/felixfbecker/node-sql-template-strings https://github.com/felixfbecker/node-sql-template-strings [2] https://github.com/blakeembrey/sql-template-tag https://github.com/blakeembrey/sql-template-tag [3] https://www.npmjs.com/search?q=sql%20template https://www.npmjs.com/search?q=sql%20template Edit: When I first read your comment, I thought you were saying that you wanted a separate library just to have the SQL template functionality. I agree with what you're saying though.
exevp 6y ago
tl;dr: thank god it finally has been done. Long version: i've been seriously frustrated with the state of ORM (in Javascript in particular) for years. Javascript ORM are nice and handy if all you're doing is simple CRUD stuff. If you're starting with more complex relational queries (we're using an RDBMS so why wouldn't we?) you quickly reach the limits of what the ORM can map. If you start doing more complex aggregations or stuff like window functions and the likes, you most certainly have to fallback to raw queries, usually rendering the whole mapping function of the ORM completely useless. Also projects like Knex.js (or for example HQL in the Java world) look nice at first but are mostly useless IMHO because they just replace SQL with another syntax you have to learn. Why stay with the language everybody familiar with RDBMS can speak if you can invent some useless abstraction, right? And please don't tell me you want to support multiple RDBMS in the same codebase. How often is this really an important use-case? I really loved the way MyBatis did this in Java: instead of mapping tables to objects, mapping result sets to objects and leaving the full power of SQL to the developer. Always wanted (and actually started something almost the same as you did some weeks ago) to basically do MyBatis in Javascript and never had the time to. Thanks for getting it started.
- areactnativedev 6y ago
  Very surprised by the no value you attach to Knex, I'm curious to get your view on the values I see in using it for a few years now. I feel at ease with SQL and like to get as close to it as possible in my Node service. But Knex still appears to be highly valuable to me to, for instance, not care about managing DB connections, at least until they become critical for my use-case. Not care about sanitising inputs and protecting myself from SQL injections. Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains. Not care about creating and maintaining code for migrations. Running them in transactions, keeping track of and running only the ones needed, ... so happy I didn't have to re-invent that and be the responsible of it never ever failing in production.
  - exevp 6y ago
    > not care about managing DB connections, at least until they become critical for my use-case. That's something the db driver usually does. E.g. when using Postgres, the pg library already comes with the connection pooling. Haven't looked into the implementation in Knex but i'd suspect they just use the Pool class of pg (https://node-postgres.com/features/pooling https://node-postgres.com/features/pooling). > Not care about sanitising inputs and protecting myself from SQL injections. That's also not that much of a concern when just binding parameters. > Have more readable and maintainable code in my repositories than SQL in plain strings as a default. Yes I have some raw queries but 98% of my queries are easy to follow knex chains. Comes with the cognitive cost of maintaining another abstraction for SQL. > Not care about creating and maintaining code for migrations. That's actually the one feature which made me use Knex for years (just for the migration part of course :) ). I didn't use the schema builder functions mostly, just a bunch of `knex.raw` calls in the migration files. But for the benefits you mentioned (transactions, bookkeeping) it is really useful.
marius_k 6y ago
thanks. I love it! It is not clear where the `article.id` comes from in many-to-many example. Anyway I don't think I would use those relationships patterns, instead I would just load and operate in plain (shallow) model objects.
- Seb-C 6y ago
  Thanks! It was a copy/paste mistake. I just fixed the README file.
deleted 6y ago
[deleted]
gmac 6y ago
My own TypeScript non-ORM, Zapatos, shares much of the same design philosophy (and indeed a sql`...` tagged template function): https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/ Previous discussion: https://news.ycombinator.com/item?id=23273543 https://news.ycombinator.com/item?id=23273543
- intellix 6y ago
  thought this looked awesome when I saw it. Was waiting for a little more traction, my project to calm down and perhaps some GQL helpers to appear before jumping on board (not requesting them but just naturally picked up by the community)
  - gmac 6y ago
    Glad to hear it! Presumably GQL is GraphQL, which so far I have let completely pass me by. How would those helpers look, roughly?
- skrebbel 6y ago
  Zapatos is amazing. I'd definitely use it if I were writing Node backends, I think its design is wonderful. Also, I'm impressed by how beautiful and interactive your docs are. How did you do that? The show imports button, the embedded monaco modal.. Did you just code that up yourself just for these docs, or is this "just" some nice documentation template that I'm not aware of? Either way, very nice!
  - gmac 6y ago
    Thanks. I just coded it up myself[1]. :) As an educator, I’d say the docs are probably the most important element of a library. [1] https://github.com/jawj/zapatos-docs https://github.com/jawj/zapatos-docs
- ummonk 6y ago
  Wow this is amazing. Really bridges the last remaining gap to close the type-safety gap from SQL -> TS/Node.JS -> GraphQL -> TS / client code. Exactly the kind of "use SQL in typescript code with type-safety" non-ORM that I've always wanted.
mqus 6y ago
What do you think about ORMs like Androids Room[1], where you do specify your own queries with sql (by annotating abstract methods) and can bring your own model and the ORM creates the database schema in the database and gives you access to easy insertion methods. I don't know how Room does it but darts floor library(which is similar)[2] then generates the code that is necessary, in addition to a very slim runtime layer for managing update events. I find that this is also an approach which in some ways only does half the work for more flexibility, while still depending on a fixed database schema. [1] https://developer.android.com/training/data-storage/room https://developer.android.com/training/data-storage/room [2] Shameless plug: https://github.com/vitusortner/floor https://github.com/vitusortner/floor
- Seb-C 6y ago
  Thanks. I do not have experience with Room, but I usually prefer to control and know what is happening in my schema. For example, if your schema is automatically handled, how do you both rename and change the type of a column without losing data? Would it perform a delete and a create?
  - mqus 6y ago
    Only the creation is handled automatically. Room helps with migrations by enforcing a database version but you will have to write the migration code(sql) yourself.
axlee 6y ago
I'm extremely happy with Django's ORM. It never felt bloated or overcomplicated to me, especially when compared with the innate verbosity and complexity of SQL.
Juliennng 6y ago
I've been playing with tagged-template for a while now and have a similar solution at work. I wanted to build something like that for a while now, well done! I wrote about tagged template literal on my website : https://cavaleiro.fr/posts/template-literals/ https://cavaleiro.fr/posts/template-literals/
thunderbong 6y ago
In Ruby, I have always been extremely fond of the Sequel ORM - http://sequel.jeremyevans.net/ http://sequel.jeremyevans.net/ The amount of expressiveness and capability it gives is simple outstanding. It lets me drop into pure SQL as well as write statements which are simpler and easire to grok when I'm using the ORM level abstractions. Sequel for SQL users - http://sequel.jeremyevans.net/rdoc/files/doc/sql_rdoc.html http://sequel.jeremyevans.net/rdoc/files/doc/sql_rdoc.html Cheat sheet - http://sequel.jeremyevans.net/rdoc/files/doc/cheat_sheet_rdoc.html http://sequel.jeremyevans.net/rdoc/files/doc/cheat_sheet_rdo...

capnorange 6y ago

still yet to find an ActiveRecord equivalent for javascript.

racedude 6y ago
What about this? https://github.com/typeorm/typeorm/blob/master/docs/active-record-data-mapper.md#what-is-the-active-record-pattern https://github.com/typeorm/typeorm/blob/master/docs/active-r... (Forgive me if this isn't what you are looking for, not super familiar with ActiveRecord myself, just recalled seeing that yesterday!
- jdauriemma 6y ago
  Yes, TypeORM is definitely the JavaScript answer to ActiveRecord
  - agustif 6y ago
    Can vouch for TypeORM, hopefully it's creator will pick it back up soon and get it to a stable v1.0.0!!
- benatkin 6y ago
  I like TypeORM but have passed on it for now because of this potential sql injection issue: https://github.com/typeorm/typeorm/issues/3740 https://github.com/typeorm/typeorm/issues/3740 I have passed a field to order_by() from the user in Django before. I would be more likely to use a dict now, but I shudder at the thought of accidentally creating an SQL injection bug because I expected to be protected by my ORM.
- Thomaschaaf 6y ago
  https://mikro-orm.io/ https://mikro-orm.io/ is a much better typeorm alternative as it is actively being maintained. TypeORMs development has come to a halt. And many issues are not being fixed.
midrus 6y ago
That's Prisma [1] for me. Coming from Django, I've found prisma even better than the Django ORM, despite not yet as complete. [1] https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma

midrus 6y ago

All these things fall short the moment you need real "production" features, such as reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks), transactions, community support, relationship/nested/join queries without a ton of boilerplate and being battle tested. So far, the best thing I've found in the node ecosystem is Prisma [1], and it's better than the alternatives by a very long shot in my opinion. [1] https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma

bradstewart 6y ago
This. I've actually used Rails/ActiveRecord migrations in Node projects. More than once...
Seb-C 6y ago
> reliable migrations (writing them by hand? no thanks. Outsourcing to another library like knex? no thanks) IMHO, "real production features" means also caring about the long term maintenance, performance and reliability of the data. My experience with ORMs (especially ActiveRecord patterns) is that it always becomes a mess once you reach a certain level of complexity. It is very fast to get started, but gets slower over time once you start having a lot of bugs and hard-to-solve behaviours.
- bakedbeanz 6y ago
  Interesting, then what is your alternative? It seems like hand-rolling all of your migrations would be an enormous pain on larger projects.
  - Seb-C 6y ago
    Well, this project is my alternative, and so far I did not see any case where it fails, but I'd be happy to learn. This migration pattern is quite common in many frameworks, I just removed the query-building abstraction layer.
nicoburns 6y ago

golergka 6y ago

Love to see more options in this space! I've made a switch from traditional ORM (TypeORM and Sequelize) to a similar "light ORM", Pgtyped, and never looked back since. Like in Kiss, you write queries in SQL. But unlike other "light ORMs", it also provides type safety by generating type declarations by directly connecting to your database instance and type-checking your query templates. Honestly, I think it's the best of both worlds, and would love to see more developers finally learning SQL and ditching "fat ORMs" that try to hide it under abstraction layers that always end up leaking.

davecardwell 6y ago
I agree. I’ve been using pgtyped for a recent project, along with https://github.com/graphile/migrate https://github.com/graphile/migrate for migrations, and it has been great to just write SQL and not have to battle with an ORM’s abstractions.

CoffeeDregs 6y ago

sql"SOME SQL"; This looks to be a "tagged template": https://basarat.gitbook.io/typescript/future-javascript/template-strings https://basarat.gitbook.io/typescript/future-javascript/temp.... I'm a TS user but hadn't seen that feature before. AFAICT, the library is using a side-side-side-feature (tagged templates) of TS as the core abstraction [1]. Impressive. Might be a little brittle in the face of significant SQL or query composition? Anyhow, I'm a heavier-ORM user but that's impressive. --- [1] https://github.com/Seb-C/kiss-orm/blob/c4b6c9ad2f81337938a9c609b4bc9ef05b08c300/src/Queries/SqlQuery.ts#L10 https://github.com/Seb-C/kiss-orm/blob/c4b6c9ad2f81337938a9c...

lucideer 6y ago
Tagged templates are a core feature of JS, not just of TS https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
exevp 6y ago
Not specific to TS, just one of the modern JS features: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Scroll down to the part explaining how to use custom tags.
marton78 6y ago
This is nothing special, it's commonly used e.g. with GraphQL (the `gql` tag).

gigatexal 6y ago

As a never-ORM guy I really like what this is trying to do. It seems like the best of both worlds. Kudos!

Seb-C 6y ago
I am glad that it is appreciated! Thank you.

timmy-turner 6y ago

When using raw SQL in strings, I really miss the automatic formatting that is provided for HTML, TSX and TS with prettier. Raw SQL query strings also do not compose well and I miss auto completion when writing them (yes, I'm a spoiled kid after so much Typescript usage). As with everybody else, I didn't like existing ORM/builder approaches, so I built and use my own with type-inference: https://github.com/hoeck/typesafe-query-builder https://github.com/hoeck/typesafe-query-builder. Any feedback would be great because I have the gut feeling that this one has gone way too far on the type astronaut side of things.

hv42 6y ago
You should be able to do this with IntelliJ e.g. where you can inject a language into a string. This is quite handy as you can reformat and open the string in a separate editor if needed. The caveat is that it does not work well if you are composing the SQL queries from multiple small parts. see https://www.jetbrains.com/help/idea/running-injected-sql-statements.html https://www.jetbrains.com/help/idea/running-injected-sql-sta... I suppose that other editors or IDE can do similar things.

haakts 6y ago

Seems similar to PureORM[1]. It allows you to write regular native SQL and receive back properly structured (nested) pure business objects. The name pureORM reflects both that it is pure ORM (there is no query builder dimension) as well as the purity of the mapped Objects. [1] https://github.com/craigmichaelmartin/pure-orm https://github.com/craigmichaelmartin/pure-orm

deleted 6y ago

[deleted]

holgerw 6y ago

Thank you for creating Kiss ORM. I have even created a HackerNews account to be able to comment on it. I have been searching for this type of ORM in Typescript for a while. I agree to write raw SQL for queries. So easy and expressive and one less layer of abstraction. I also agree on the value of the respository pattern and methods for CRUD operations to not write this SQL by hand. Making the loading of associations an explicit decision is also the right way to go. The Rails community has good experience with performance surprises of automatic loading of relationships. Personally I found the most useful ORM in Ecto for the Elixir (Erlang) language: https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html (ignoring the query capability). It follows very much the repository pattern like Kiss ORM. The API is a bit more succinct (you only define a schema for each table and use a generic repository instead of subclassing for each table) but that might be possible only due to Elixir's language capabilities like meta-programming. One piece of Ecto that might be a win to implement in Kiss ORM is the "Changeset" pattern to give a canonical, succinct and productive solution to validate data (https://hexdocs.pm/ecto/Ecto.Changeset.html#content https://hexdocs.pm/ecto/Ecto.Changeset.html#content). For example have a look at how Ecto unifies validation (checked without hitting the DB) and constraints (checked by hitting the DB) in a single API. This type of functionality increases the usefulness of the repository's CRUD operations. Thank's for your initiative to create KISS ORM. I will sure try it out and follow along it's evolution.

holgerw 6y ago
Just forgot to mention Ecto's "Multi API", that is worth knowing. Allows to construct a chain of operations as a data structure and to execute it later transactionally. You may even include operations that are part of transactional business logic but that do not hit the DB (like sending an email). (https://hexdocs.pm/ecto/Ecto.Multi.html#module-run https://hexdocs.pm/ecto/Ecto.Multi.html#module-run) As I understand KISS ORM's sequence function would also allow to express business logic transactionally and operations beyond the DB. Obviously the rollback would only effect the DB, but other failing operations can at least trigger the rollback, right? I think this is usefull as integration with external services (like email providers, payment APIs..) are really the source of runtime surprise that might fail a business operation and demand a DB rollback.

ryanmarsh 6y ago

This is very nicely done, kudos to the author. I'm sure many will find this useful. Personally I've gotten away from using SQL RDBMSs. Since I primarily build on AWS I use DynamoDB but the same principle would apply elsewhere. I like to store data in the format that best supports the read model. Event sourcing allows me to change the structure of the read model, or add new read models, or vary strategies depending on data, as needed. I like that I no longer have the impedance mis-match of the normalized relational model. It was a big jump to make, and I had to unlearn a lot. I'm not dismissing the value of RDBMSs at all. I love them, especially star schemas for analysis. I just want to share that it's ok to not use an relational model for your transaction store.

LorenzA 6y ago

the template syntax reminds me of an other postgres libary https://github.com/porsager/postgres https://github.com/porsager/postgres

Dragory 6y ago

It seems you cannot load relationships for a collection of entities easily without N+1 queries, unless I'm missing something. Based on the many-to-many section of the docs (https://github.com/Seb-C/kiss-orm#many-to-many https://github.com/Seb-C/kiss-orm#many-to-many), I would have to load relationships for each entity separately, and then if they have further nested relationships, run a query for each again. The subsequent section also mentions eager loading is not supported. For me, being able to load relationships (and especially nested relationships) with little boilerplate and few queries is probably the most useful feature in an ORM (usually explicitly eager-loaded), so I'm sad to see it's not supported.

WkndTriathlete 6y ago
Agreed on the N+1 query problem, but I'm a bit mystified why people still choose ORMs for any projects with even a moderate level of database complexity. When using a straight SQL layer (JDBC or the basic features of KISS-orm) the query is in SQL form and the performance characteristics of the query are obvious from the query or can be analyzed easily by taking the query and running it through the database's query analysis tools. Using an ORM just adds extra steps: instead of optimizing a query in SQL, the query needs to be optimized using directives or methods or annotations that the ORM provides in the hope that the SQL that is ultimately generated is efficient; that is, we're programming the ORM which programs the database instead of just programming the database. Why bother with the extra step? With modern programming languages there really isn't that much extra boilerplate to implement the DTOs for straight SQL and it usually results in code that is a lot easier to maintain and extend in the examples I've seen.
- Dragory 6y ago
  In my experience, 99% of the relationships I fetch fit the basic one-to-one, one-to-many, many-to-many definitions that pretty much all ORMs support. For these cases, the queries are generally more than efficient enough and there's little reason to reinvent the wheel and implement the code for fetching those relationships yourself. For anything more complex, I agree. But for the common case of fetching simple and often (depending on your project) nested relations, I definitely enjoy the abstraction provided by ORMs.

nhumrich 6y ago

I actually built something almost exactly like this internally. This is awesome. But, its a far cry to call this an ORM. Its just a safe query serializer. ORM takes an object and writes the query for you.

blaufast 6y ago

I think its funny that 'opinionated' could be considered a virtue. I'm imagining a charity that uses 'opinionated' to describe itself, or even worse, a person. Even Apple, a brand famous for its strong design stances, does not use that word as a description of its values.

mrmonkeyman 6y ago

SQL is an useful and simple abstraction in and of itself. Stop wasting mental cycles.

wayneftw 6y ago

I started using Objection.js and Knex last year and I think it might be the best ORM I've used on any platform. There's no way I'm going back to writing raw queries. If I did that, eventually I'd rewrite Knex. If and when I need a raw query, I can already do that with Knex.

cryptica 6y ago

History keeps repeating itself. People never seem to learn anything. At first there were no ORMs, then ORMs became extremely popular and everyone was using them, then everyone learned that ORMs were a very bad idea and we stopped using them, vowing never to make the mistake again... And here we are again in 2020, ORMs are back. They will be in for a while, then out again, then in again.... Same with statically typed vs dynamically typed. First everything was statically typed, then dynamically typed (interpreted) languages gained popularity, developers LOVED not having to wait for the compiler to finish to test their changes; this was a revolution... Now again, we're going back to statically typed languages, everyone uses clunky bundling and transpilation tools which add bloat and everyone is happy to wait 20 seconds to a minute for their code to compile. Every few years, developers believe the opposite of what they believed before and the consensus seems to be close to 100% every time. It's ridiculous.

lemontruth 6y ago
That is because many people believe in extremes. After a while people should learn that there is no absolute truth, everything has it's place. ORM is good sometimes, pure queries are better on others. So what is needed is more like relaxed ORMS.
nesarkvechnep 6y ago
What I've learned from my career so far is that developers hate history. They just don't want to learn from experience. They see the new shiny thing and jump on the hype train. Then they come to conclusions like "mongo was not the right choice since we never needed to scale and our data is relational".
ben509 6y ago
That's overly broad. A lot of people jump on the latest trends, especially people who are simply new to development, because there's no way you can know stuff you haven't had time to learn.

nesarkvechnep 6y ago

There's still nothing like Elixir's Ecto in JS land...