> was previously primarily a Java programmer

same here, except Apollo GraphQL, we still use REST. it is indeed nirvana. wish the community finally settle down on a stack at least for a decade.. shifting the backend every few years doesn't do good for dev productivity.. (had to recently use Go due to peer pressure. while performance wasn't a concern it was purely due to the "feel" that Node.js is not good enough for serious backend work - lack of multi threading , potential future performance and scalability etc.)

> lack of multi threading

That aspect of Node.js can actually be a very good thing for serious backend work, as it encourages process decoupling using API's. Decoupling ends up scaling better later on: you build a distributed system that can be scaled out horizontally across a fleet, rather than running up against vertical scaling limits of how many threads you can get running on the same local hardware.

Whenever I've seen applications that use worker threads for backend systems they end up regretting it and wished they had decoupled into a separate process that could have been scaled independently onto other hardware over the network. Spinning up new threads on the same machine is a temporary crutch that bites you later on in your growth.

I’ve seen plenty of serious backends that use multiple threads and are horizontally scaled.

I don’t think this is a particularly compelling argument for the lack of multi-threading. The worker thread pattern is fairly useful and there is no reason a well architected application couldn’t use both horizontal and vertical scaling. Independent scaling is only really useful if there is a large variation in the amount of work done by the workers per query. If it’s well bounded, then it might be easier to just horizontally scale the entire backend.

There are also other use cases for threads that don’t fit into the worker pattern. For example, background tasks that happen outside the serving path.

Same here, same stack. Was considered a big risk when we started 3 years ago. The code sharing possibilities, much easier team transitions (couple that with client development on all platforms via React Native), much easier hiring. I'm not sure that out of all contenders Javascript/TS as a language was worthy of such a role, but here we are, and it's working.

> huge, enormous, gargantuan benefits

Would you mind enumerating them? I have an idea of what they are but curious about other perspectives.

My sense is that code sharing is not that common between a Typescript frontend and backend. You mostly need generated request/response data types but I don't think there's that much shared behavior because you can't import any of your backend-y logic (database, auth, external APIs) transitively into your frontend.

I think primary gain is what you've hinted at: 1 ecosystem and it's easier to onboard fullstack devs.

Notion shares a large amount of code between the front-end and back-end. We have many algorithms, collections, helpers, etc that we share. Here's an example, we have a shared loadPageChunk function that takes a cursor and a loader implementation, then traverses our data graph to gather the data needed to render part of a page.

    // shared code - implement the algorithm
    export async function loadPageChunk(
     args: LoadPageChunkArgs,
     loadRecordValue: loadRecordValueFn
    ) {
      // ...
    }
    
    // client code - use the algorithm, provide client-specific IO
    // eg on Android we'd use Sqlite.
    const records = await loadPageChunk(cursor, SqliteService.loadRecordValue)
    
    // Server code - same, but use the server's data stores.
    // Behind the scenes, these loaders batch, etc
    const records = await loadPageChunk(cursor, useCache ? CacheService.loadRecordValue : PostgresService.loadRecordValue)

Even if we only shared types, there's a significant benefit. We try to push as much logic into the type system as we can; for example we use discriminating unions to define different groups of related types. Eg, we have a union type called ContentBlock that has all the specific block types that can have children, `Page | Text | Column | ...`, sharing this type and its helper functions like `isContentBlock(block: BlockValue): block is ContentBlock` means both our front-end and back-end code rely/expect/enforce the same invariants.

One example: input validation logic is something that is nice to run in the front end (for performance and immediate responsiveness to users) but that you also need to run in the back end for correctness.

Previously I've done this with 2 implementations (JS on frontend and Java on backend), but then keeping the logic in-sync is a nightmare. With a single language you can just share the library.

You are correct, though, the biggest benefit I see is not sharing code, but making it trivially easy for a front-end dev to add a small piece of backend code that they need without needing a back-end dev to do it, and vice versa. It just makes the overall team much more productive because there is very little "waiting on the back/front-end" to do it.

Oftentimes we'll have either team write up the schema for a new endpoint using the GraphQL schema definition language, then from that we autogenerate the TypeScript types, then usually the front-end team creates a simple mock in the backend so that they can fully implement the UI, meanwhile the backend team works concurrently on the real implementation. This process allows for much more parallel productivity than if, when something is broken or needed from the other team, you just have to submit a ticket and wait.

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.

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 (overview explaining the rationale for this library is at 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 ) and Redis when we need a global cache.

I highly recommend you not use node-lru-cache: 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).

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.

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.

We use slonik and a few helper functions. Very little boilerplate.

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?

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.

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/

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

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.

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.

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?

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...

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...

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.

I think the mistake is thinking an orm is actually going let you be free of knowing or caring database fundamentals. That only applies in the most simple cases. An orm has other benefits though.

How much work do you have to deal with if a column gets renamed? Be honest.

1. Don't rename your columns, but if you have to

2. project search and replace on $COLUMN_NAME

If your column name is a common keyword, variable name, etc. in your code base and it's difficult to find using project search, that's unfortunate, but we organize our backend code and tests in a logical enough way that it's never taken longer than an hour to create a PR to create a migration to rename a column and update all places in code that reference it.

Renaming a column is an operation which showcases the weakness in not using an ORM. Other operations of the sort do exist, anything that operates on columns across multiple arbitrary spots in the code.

IMO an hour for a change you have so little confidence about is not acceptable when the alternative allows you to do it in a second with full confidence.

While this is fair and I don't disagree that changing a column name or possibly other schema changes using an ORM and it's subsequent migration scripts is potentially going to be a faster exercise than without one, changing a column name (or any schema change for that matter) in a database in my experience is rare. If you choose to use an ORM for reasons like it might (emphasis on might) be a bit faster and easier to change a column name than without one instead of for other more meaningful people or efficiency-oriented reasons of the day-to-day developer workflow is probably a poor approach.

Keep in mind I've installed and used an ORM in projects where the ORM is used only for migrations, but not used in application code and this is absolutely a fine reason to use one imo. But adopting an ORM for migration purposes and forcing or using in application code simply because it's installed isn't necessarily a good approach.

Like I said, it's one example.

ORMs are to SQL what static types are to programming languages. The conversation we just had was me giving you one example of the benefit of static types, which happens to showcase a huge weakness in dynamic typing:

- How painful is it to rename a class attribute?

=> It's a long search & replace exercise which results in a less-than-certain outcome.

The obvious take from this isn't that "renaming class attributes is rare".

This is a very simplistic view of the situation.

ORMs have very basic support of current SQL standards and database specific features.

This means that using an ORM reduces the power of the database choice you made.

Also things like arbitrary SQL support imply you have to manually creat return value typings.

Having to leave the nice ORM wrapper functions for arbitrary SQL means you lose all the ORM niceties like soft deleted or updated_at fields

Overall I see very little use for ORMs.

You don’t need an ORM, but (unless you’re a total masochist) you probably want _something_ to smooth the interaction with SQL.

We have a TypeScript Node.js API in production, and we wrote Zapatos to be that something: https://jawj.github.io/zapatos/

I know several people who currently/used to work at PayPal and this is their stack (the people I know were on the wallet team, but I got the sense it's a fairly prevalent thing across the org)

We have a similar setup and it works pretty good, the only thing missing is the auto generated clients and that sounds like it could be really useful. What are you using there?

Not OC but we generate the client types with Apollo codegen (https://www.apollographql.com/blog/typescript-graphql-code-g...) using the schema file generated by our NestJS backend

Check out gqless which generates a full Typescript schema without any need for strings.