6 ms·

I’ve got a similar stack, what are you using for ORM? Started using Prisma to replace TypeORM/TypeGraphQL but it’s new and unproven. Also are you caching with R

I’ve got a similar stack, what are you using for ORM? Started using Prisma to replace TypeORM/TypeGraphQL but it’s new and unproven. Also are you caching with Redis, any other utilities helping with that? GraphQL-codegen is a lifesaver for generating gql types and resolvers.

hn_throwaway_99 6y ago
We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c https://medium.com/@gajus/bf410349856c ). Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.
- tolmasky 6y ago
  I highly recommend you not use node-lru-cache: https://github.com/isaacs/node-lru-cache/issues/63 https://github.com/isaacs/node-lru-cache/issues/63 (as you can see from the last comment on that bug, these truly bizarre performance characteristics were not solved, and I would recommend drop-in replacing the fast-lru library we use).
- btown 6y ago
  I'm curious how you handle migrations and schema documentation, which to me are the huge benefit of using something like Django or ActiveRecord. Do you version-control at least your forward-migrations as SQL or SQL-via-Slonik? And do you have processes in place to ensure columns are documented in a central location?
  - hn_throwaway_99 6y ago
    For migrations we actually use knex, but primarily just because it was in place first before I knew about Slonik. Writing a migration tool is pretty trivially easy - all knex does is let you write an up migration and a down migration, and it keeps track of which migrations have been applied in a DB table. Main thing is that all of our migrations are each in an individual versioned file in our source repo. We use postgres COMMENT functionality to apply comments to all of our table columns.
- sthomas1618 6y ago
  I've worked worked developers that have a hardline against ORMs. I see lot of their points, especially around the performance of raw SQL. But I cannot get past how much boilerplate code that has be written over and over again. And then you have to test that boilerplate code. I find that most people are far more productive using an ORMs. To me this makes sense because it's less things to type. Less is often more. We have services that don't ORMs and I have to wonder if it's worth the cost.
  - hermanradtke 6y ago
    We use slonik and a few helper functions. Very little boilerplate.
  - hn_throwaway_99 6y ago
    While I don't write a ton of "boilerplate", the primary thing for me is writing boilerplate, if necessary, is trivially easy. What's hard is debugging when problems arise, or trying to do some slightly more complicated join that isn't supported out of the box by your ORM tool of choice. Basically, in my opinion ORMs just make the easy stuff slightly easier, but they make the hard stuff much harder, and when you're stressed out trying to fix some critical production DB query all they do is get in the way.
coldtea 6y ago
ORM? What is this, 2004 J2EE? Joking aside, in a dynamic language like Javascript, especially in modern coding style which is not OO anyway, you don't need an ORM.
- tayo42 6y ago
  You write sql statements? And turn the response into classes by hand in every app you write? Ruby and python have orms too. Am I missing something?
  - coldtea 6y ago
    You write classes? What is this, 2005? Joking aside, I do write SQL statements (or use a query builder, which is not the same as an ORM). I don't "turn the response into classes by hand in every app I write" however, because the responses are perfectly usable as they are (in a more functional style), and OO is not the best way to model records anyway. I know Ruby and Python have ORMs, ActiveRecord, SQLAlchemy and so on. They're not really needed. Heck, I've read authors of ORMs saying you don't really need one...
    - tayo42 6y ago
      This seems like a sweeping judgment your making saying don't use orms, or classes. But this seems like just an odd religious take people have so I'm out...
      - PostThisTooFast 6y ago
        you + are = you're
      - whatl3y 6y ago
        While some people are hard lined enough on this that I agree it sort of becomes weird, I can tell you my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I think the answer depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.
notsag-hn 6y ago
Maybe not an ORM but a query builder: Knex has been of so much help to me, it works pretty well and it's really easy to use. Used sequelize in the past but it can get incredibly complicated, really positive change.
eyelidlessness 6y ago
If you’re already doing codegen, you might take a look at Zapatos[1]. It generates types from your database schema, and provides type safe query builders (raw SQL via tagged literal, some simple ORM-like functions for basics). 1: https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
- camjohnson26 6y ago
  Prisma does something similar, provides a typed schema and a query engine written in Rust.

hn_throwaway_99 6y ago

We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c https://medium.com/@gajus/bf410349856c ). Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.

tolmasky 6y ago
I highly recommend you not use node-lru-cache: https://github.com/isaacs/node-lru-cache/issues/63 https://github.com/isaacs/node-lru-cache/issues/63 (as you can see from the last comment on that bug, these truly bizarre performance characteristics were not solved, and I would recommend drop-in replacing the fast-lru library we use).
btown 6y ago
I'm curious how you handle migrations and schema documentation, which to me are the huge benefit of using something like Django or ActiveRecord. Do you version-control at least your forward-migrations as SQL or SQL-via-Slonik? And do you have processes in place to ensure columns are documented in a central location?
- hn_throwaway_99 6y ago
  For migrations we actually use knex, but primarily just because it was in place first before I knew about Slonik. Writing a migration tool is pretty trivially easy - all knex does is let you write an up migration and a down migration, and it keeps track of which migrations have been applied in a DB table. Main thing is that all of our migrations are each in an individual versioned file in our source repo. We use postgres COMMENT functionality to apply comments to all of our table columns.
sthomas1618 6y ago
I've worked worked developers that have a hardline against ORMs. I see lot of their points, especially around the performance of raw SQL. But I cannot get past how much boilerplate code that has be written over and over again. And then you have to test that boilerplate code. I find that most people are far more productive using an ORMs. To me this makes sense because it's less things to type. Less is often more. We have services that don't ORMs and I have to wonder if it's worth the cost.
- hermanradtke 6y ago
  We use slonik and a few helper functions. Very little boilerplate.
- hn_throwaway_99 6y ago
  While I don't write a ton of "boilerplate", the primary thing for me is writing boilerplate, if necessary, is trivially easy. What's hard is debugging when problems arise, or trying to do some slightly more complicated join that isn't supported out of the box by your ORM tool of choice. Basically, in my opinion ORMs just make the easy stuff slightly easier, but they make the hard stuff much harder, and when you're stressed out trying to fix some critical production DB query all they do is get in the way.

coldtea 6y ago

ORM? What is this, 2004 J2EE? Joking aside, in a dynamic language like Javascript, especially in modern coding style which is not OO anyway, you don't need an ORM.

tayo42 6y ago
You write sql statements? And turn the response into classes by hand in every app you write? Ruby and python have orms too. Am I missing something?
- coldtea 6y ago
  You write classes? What is this, 2005? Joking aside, I do write SQL statements (or use a query builder, which is not the same as an ORM). I don't "turn the response into classes by hand in every app I write" however, because the responses are perfectly usable as they are (in a more functional style), and OO is not the best way to model records anyway. I know Ruby and Python have ORMs, ActiveRecord, SQLAlchemy and so on. They're not really needed. Heck, I've read authors of ORMs saying you don't really need one...
  - tayo42 6y ago
    This seems like a sweeping judgment your making saying don't use orms, or classes. But this seems like just an odd religious take people have so I'm out...
    - PostThisTooFast 6y ago
      you + are = you're
    - whatl3y 6y ago
      While some people are hard lined enough on this that I agree it sort of becomes weird, I can tell you my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I think the answer depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.

notsag-hn 6y ago

Maybe not an ORM but a query builder: Knex has been of so much help to me, it works pretty well and it's really easy to use. Used sequelize in the past but it can get incredibly complicated, really positive change.

eyelidlessness 6y ago

If you’re already doing codegen, you might take a look at Zapatos[1]. It generates types from your database schema, and provides type safe query builders (raw SQL via tagged literal, some simple ORM-like functions for basics). 1: https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/

camjohnson26 6y ago
Prisma does something similar, provides a typed schema and a query engine written in Rust.