7 ms·
This is great, and I mean no disrespect, but aren't most servers written in anything but TypeScript? Java, Python, Ruby, .Net, Go, etc.? I recognize that chan
by dventimihasura 3y ago
This is great, and I mean no disrespect, but aren't most servers written in anything but TypeScript? Java, Python, Ruby, .Net, Go, etc.? I recognize that changing it from "most servers" to "most GraphQL servers" brings in TypeScript, but I think that underscores the point I'm trying to make. Most HTTP APIs are REST (I think...that's worth checking) and will use something like Spring Boot, MuleSoft, Django, RoR, etc. In "enterprise" it's mostly going to be Java with Spring Boot or MuleSoft, or .Net. To have more GraphQL APIs, that's where the big game is: converting those REST APIs to GraphQL, or at least gradually (or not so gradually) persuading enterprises to switch from REST to GraphQL. With Spring Boot and MuleSoft, there's already a relatively easy story there: Spring GraphQL, Netflix DGS, MuleSoft Datagraph, graphql-java, etc.. There's probably something similar in the other ecosystems (Python, .Net, Ruby, etc.) You get to keep most of your code and development practices, but you do add in a few new libraries and you do write your code a little differently. So I just struggle to see what the audience is for TypeScript servers. Just my two cents.
- wubrr 3y agoThere are maaaany backends written in JavaScript (nodejs), TypeScript is a much better alternative, and this is a step in the right direction (though I'm personally not a fan of GraphQL).
- dventimihasura 3y ago> There are maaaany backends written in JavaScript (nodejs) Are there? I honestly don't know. I feel like it depends on how you count them. Are there JS/TS/nodejs "Backends For Frontends" (BFFs)? Yeah, I could see that, but then in that case there's at least as many other backends behind them, probably written in something else. Are there JS/TS/nodejs backends, mediating interaction with upstream databases in large enterprise organizations? I highly doubt it.
- calmoo 3y agoYes, node/TS backend APIs are extremely common.
- dventimihasura 3y agoAre they more common, or less common, than Django and RoR?
- wubrr 3y agoLMGTFY
- dventimihasura 3y agoDid you forget the link?
- hn_throwaway_99 3y agoYou are simply wrong. NodeJS is a popular server technology. I've implemented server APIs in NodeJS (both with and without GraphQL) in everything from large, well-known enterprises to brand new startups.
- sgarland 3y agoWhen I think “robust, performant language to serve traffic at scale,” my first instinct is definitely a frontend language. I despise NodeJS and its entire ecosystem. The number of incidents I’ve been dragged into which are directly linked to its use is too damn high.
- dventimihasura 3y agoI could be wrong. That's one thing I'm trying to figure out. Setting that aside, like I said I don't really know that community, being mostly a Java developer. What're the go to database libraries? Is it sequelize, or something else?
- hn_throwaway_99 3y agoThere are tons of DB drivers/libraries for node. I'm personally a huge fan of slonik.
- dventimihasura 3y agosequelize seems to be much more popular than slonik. Is sequelize more or less the standard or at least market leader? https://trends.google.com/trends/explore?date=all&geo=US&q=Slonik,Sequelize&hl=en https://trends.google.com/trends/explore?date=all&geo=US&q=S...
- dventimihasura 3y agoOf course, Hibernate (Java) dwarfs them all. https://trends.google.com/trends/explore?date=all&geo=US&q=Slonik,Sequelize,Hibernate&hl=en https://trends.google.com/trends/explore?date=all&geo=US&q=S...
- wubrr 3y ago> I highly doubt it. Not sure why you highly doubt it, when you admit 'I honestly don't know' and the truth is 20 seconds of googling away. backend web frameworks - https://github.com/vanodevium/node-framework-stars https://github.com/vanodevium/node-framework-stars ORMs - https://github.com/emanuelcasco/typescript-orm-benchmark https://github.com/emanuelcasco/typescript-orm-benchmark Not to mention pretty much every major cloud service (AWS, GCP, etc) has first-class JavaScript/TypeScript SDKs.
- dventimihasura 3y agoI highly doubt it because I was talking about enterprise companies. I honestly have no idea how common node is in general, including other organizations, but when it comes to enterprise companies, I do have an idea. My idea is that node isn't very common. I'm even more confident in relative terms: however common it is, it's less common than Java and .Net are. As for cloud service SDKs, are you saying that many node backends rely on cloud SDKs?
- wubrr 3y agoWhat's an 'enterprise company' lol? Many big banks have hundreds, if not thousands of nodejs-based backend services. Is Netflix[0] an 'enterprise company'? What about Walmart[1] ? [0] https://www.bellcorpstudio.com/blog/how-netflix-is-using-node-js https://www.bellcorpstudio.com/blog/how-netflix-is-using-nod... [1] https://medium.com/walmartglobaltech/migrating-large-enterprise-to-nodejs-6c38523d2b33 https://medium.com/walmartglobaltech/migrating-large-enterpr... > As for cloud service SDKs, are you saying that many node backends rely on cloud SDKs? Almost anything that uses a cloud service like DynamoDB is going to 'rely on cloud SDKs'... the language is irrelevant.
- dventimihasura 3y agoIncidentally, I see no evidence in those links or elsewhere that either Walmart or Netflix is using node to meditate interactions with upstream data sources. What I do see elsewhere is the usual suspects: some databases and message queues, and then lots of Java https://blog.bytebytego.com/p/ep76-netflixs-tech-stack https://blog.bytebytego.com/p/ep76-netflixs-tech-stack
- freedomben 3y agoI've mainly worked in startups, but also worked with big enterprises as well during a stint at Red Hat, and yes, backends in Javascript are numerous and plentiful. Aside from Java in enterprise environments, it's by far the most common backend I've seen.
- dventimihasura 3y agoI'm curious about that ecosystem, especially with regard to databased. I asked this elsewhere, but what're the main libraries for database access?
- freedomben 3y agoFor databases it varies quite a bit. Among people who like to use an ORM, TypeORM is the current thing that is in widespread use. For non-ORM people, most use pg or a similar thin-layer on top of raw SQL. In enterprise it was a lot of raw SQL as well, in large part because there was a lot of different DBs to support from db2 to SQL Server to Postgres
- dventimihasura 3y agoIt's dodgy finding the right search term, but at first blush it looks like sequelize is most popular, though the gap has narrowed considerably.
- ahzhou 3y agoThey fall under a few buckets: Driver: - node-postgres - node-mysql2 Query Builder / Other thin clients: - knex - kysely - slonik ORM: - TypeORM - MikroORM - Objection.js - DrizzleORM - Prisma (actually runs a separate binary)
- akavi 3y agoNotion (valuation 10 G$) and Asana (market cap 5 G$) are both nodejs down to the DB layer, to name two codebases I have personal experience with. Not quite Fortune 500 tier, but certainly not small potatoes.
- dventimihasura 3y agoWell, I'm pretty sure I didn't say that nobody wrote node backends.
- p1necone 3y agoBuilding your backend/s and frontend/s in the same language makes keeping your data model, api inputs/outputs and business validation consistent much simpler and easier.
- sgarland 3y agoI have met perhaps a handful of devs who care about a good data model, or even know what one is. Most seem to think that JSON is god’s gift to mankind, and that RDBMS are weird boxes you throw said JSON – along with random scalars for fun – into, and then you can blame the DB for being old and slow when your latency is abysmal.
- hn_throwaway_99 3y ago> I have met perhaps a handful of devs who care about a good data model, or even know what one is. Then you have worked with an abnormally large amount of shitty devs.
- hn_throwaway_99 3y agoIn addition, especially for smaller teams, there is huge value in teams that can easily go between front-end and back-end code. Before I worked at an "all Typescript" shop, lots of times someone on the front end would need some small additional piece of data or an extra API call from the server team. They almost never did it themselves, and it wasn't so much that they couldn't read/code in Java, it's that the environment setups were so different. It just was rarely worth it to them to spend all the time setting up the backend environment (again, in a language they could understand but weren't "used to" in their day-to-day) to make a couple line change. Worse, some enterprising folks would set it up, but then since they only needed to make backend changes once in a blue moon, the next time they needed to make a change they'd have to spend a ton of time again getting their environment updated. There is huge value to using the same language, and coding environments, across front and back ends.
- freedomben 3y agoI used to say the same thing, but after 10 years of using node on the backend I no longer think that's worth much. The amount of code sharing I've experienced has been pretty minimal. You can definitely architect your app around it to make it more useful, but with some rare exceptions, on the backend you are working with the entire dataset/database, and on the frontend you are working on a small subset. I just haven't found the amount of code-sharing to be significant because things are so different. The huge productivity gains of frameworks like Phoenix (Elixir) have in my experience far outweighed the gains from code-sharing. This is all just my personal experience of course, so I'd love to hear from others if this really ends up benefitting them enough to be worth it.
- simonw 3y agoNode.js is almost 15 years old at this point. JavaScript has been a mainstream server-side programming language used by experienced, thoughtful developers for a long time now.
- dventimihasura 3y agoI'm not talking about the developers. I'm sure they're wonderful people. I'm talking about the organizations. I don't believe node has been as popular for backends in the last 15 years, especially at enterprise companies, as Java and .Net have been.
- endisneigh 3y agoGiven that node is barely 15 years old that's not surprising.
- dventimihasura 3y agoWait...is it "almost 15 years" or "only 15 years"? Is node old and established or is it still the plucky upstart?
- xboxnolifes 3y agoWhichever one convinces you to agree with the opinion I hold.
- solumunus 3y agoSo what? In all comments you seem hell bent on making a point but it’s not clear what the point is. JS backends are popular, and this is a GraphQL solution for them. The fact that JS backends are less common in enterprise companies seems completely irrelevant.
- dventimihasura 3y agoDo you want to meet people where they are and help them with solutions given their constraints? Or, do you want to offer solutions using your preferred tools? There are no wrong answers, as far as I'm concerned. I'm just curious which you would prefer.
- endisneigh 3y agoI don't really get the point of this comment. Even if most servers are not typescript, some are, and of those some may be interested in graphql, hence this. The things you're mentioning see irrelevant if you're using typescript. You may be alluding to the question of why even use node, but that would be beyond the scope of discussion.
- dventimihasura 3y agoThe point of the comment is to confront the following question: "What exactly are we trying to do here?" Are we trying to offer GraphQL servers? Or are we trying to offer GraphQL servers in Node? Because, if it's the latter, then I'll move on my merry way. If it's the former, then a new way of building GraphQL servers in Node may not be all that relevant if there's a majority of developers who already aren't building servers of any type in Node.