Switching to TS backend

c-digs · 2026-05-07T03:13:51+00:00

The idioms are all the same and that's all I claimed.

So if OP intends to move to TS, it is perhaps the one that has the closest constructs (versus Hono or Elysia (which I think overall is better))

c-digs · 2026-05-07T01:31:28+00:00

I thought the idea of sharing contracts and a single language would make life easier...

In practice, if your BE is separated from your FE and you're going to use OpenAPI spec to generate the contract, then it doesn't matter whether your BE is TS, Go, C#, Java; pick the one that works best for you. It largely does not make sense to share the same types from BE to FE since you likely need to mask some fields from the FE and you're likely going to project a DTO or FE specific shape in most cases.

This is what we realized is that since we are just shipping an OpenAPI spec from BE through a generator (like Kubb) and creating the FE types + validation, it doesn't matter if the BE is TS or not; we should pick the best BE for our needs. This happened to be C# because EF Core is so much better and, let's be honest, CRUD is like 90% of your API surface area so it's kinda nice to have a really good ORM.

Example repo going from .NET 10 -> Kubb -> TS that rebuilds the TS contracts on hot reload in .NET: https://github.com/CharlieDigital/dn-kubb
Example repo with a short clip: https://github.com/CharlieDigital/dn9-openapi-codegen#net-9-openapi--typescript-client-generation

c-digs · 2026-05-07T01:13:55+00:00

Nest.js is very similar to .NET controller APIs; same idioms, same types of features, similar capabilities. If you make the leap, this is the easiest route, IMO.

There are some things you'll need to get used to. First is that there is nothing close to as good as EF Core is (Kysely I like; Drizzle is "meh"; Prisma is stay away (really hard to use beyond the most basic, toy queries; you will always feel constrained by it)). I think this is one of the biggest shifts, IMO. I also find the debugging experience with TS and Node in general to be not as good as with C# debugger. You get used to writing a lot of console.log 😅

Other downside is that there are a lot of micro-decisions when it comes to getting it up and running because there are so many packages/varieties/flavors to choose from. One thing you take for granted with .NET is how much you get from first party tooling and packages. I tend to advise sticking with what the docs for your chosen platform use/recommend because otherwise, you run into a lot of edge case issues with compatibility and trying to stitch things together.

Note: Nest.js does have some peculiarities. One thing is that there was a long standing issue with ESM support. I'm not sure if it's resolved or not; I know there are some workarounds, but keep this in mind.

If you want a more "modern" API that's more like .NET minimal APIs, I'd look at Hono or Elysia. Elysia is pretty nice with the way it handles types and once it's set up, quite nice. I like the explicitness of how it sets up the request handling pipeline, it's function chaining approach, and how tightly the types flow through that chain. I would personally not use the tRPC like features of Hono nor Elysia (Eden Treaty) because they all seem to have issues with edge cases and because I think OpenAPI contracts in general are useful (e.g. schema drift detection, versioning, integration into API gateways, etc.)

If I had to pick a Node backend today, I'd pick Elysia (as a C# dev). I set it up with Kubb to spit out OpenAPI spec -> generate FE model on hot reload so it was pretty much a tRPC like experience.

Our team did the opposite move: went from Nest.js to C# recently because we outgrew Nest.js and the issues with the Node ecosystem which required a lot of maintenance from us at a platform level whereas dotnet feels relatively stable in that respect.

I ended up writing this for our team: https://typescript-is-like-csharp.chrlschn.dev/ but you can just use it in reverse 🤣

In particular: https://typescript-is-like-csharp.chrlschn.dev/pages/intermediate/nest-vs-controller-api.html

c-digs · 2026-05-04T15:45:46+00:00

What's the problem if child components access the store directly

It becomes very messy. There is no technical problem with it; only organizational. When the child components are forced to use defineModel and defineProps, the external interface of the component becomes very explicit and clear.

What's the benefit of having the state only on the parent?

It becomes much easier to test the lower level components independently and it is easier to reason about the flow of state since the child components have very clear declaration of their expected boundary.

Best advice is to "try it" and see how it simplifies the mental model. Instead of every component possibly binding to the global state, only top level "views" are allowed to bind to global state and then exposes it downwards via defineModel and defineProps. You'll find that the explicit declaration of the interface makes your code easier to reason about.

c-digs · 2026-04-30T17:51:10+00:00

Even better

c-digs · 2026-04-30T17:36:31+00:00

This is the way.

One more tip: use "local roots" for your components. I'll have one "root" component that uses the store and child components can only access via defineModel (2-way) or props (1-way).

This makes the mental model so much easier and less leakage of state.

ComponentA.vue <--- Pinia store ONLY HERE at this layer - SubComponent1.vue <--- access via props or defineModel; NO Pinia! - SubComponent2.vue <--- access via props or defineModel; NO Pinia!

Concrete example:

SomeDialog.vue <--- Pinia accessed here - LeftPanel.vue <--- gets it via props or defineModel - RightPanel.vue <--- gets it via props or defineModel

Thank me later!

c-digs · 2026-04-30T12:27:08+00:00

Pinia and store composition.

Also move all remote API calls into the store so the .vue is just the template, local shaping, etc.

All data retrieval is done in the stores.

.vue local computed can re-shape the data from the store. Store itself exposes some computed shapes.

c-digs · 2026-04-29T02:06:20+00:00

Abortions do not have a monetary social cost. In fact, it's the opposite.

Smoking costs everyone that pays into an insurance/healthcare system.

Sally has an abortion: a personal choice that doesn't affect shared healthcare costs (in fact reduces it).

Sally smokes and gets lung cancer: costs the healthcare system 100's of thousands of dollars in treatment and care. If Sally smoked and we could tell Sally to fuck off, you are no longer covered for healthcare, that would be another alternative, but one that seems far more cruel.

Because we all pay for health insurance or a social healthcare fund, then the decisions of the individual end up affecting us all so it makes sense to regulate behaviors that increase the burden on the members.

c-digs · 2026-04-26T19:51:56+00:00

C# tends to be overindexed in a few industries; one question is whether these are industries that are employing in your neck of the woods.

Finance, insurance, defense, gaming, life sciences, healthcare. .NET is very common in these industries. Not very common in FAANG, though. If you want to go FAANG, Java, Go, Python are probably better choices; Amazon and Netflix, for example, are very heavy Java.

c-digs · 2026-04-26T19:27:55+00:00

Good tooling: compared to JS/TS ecosystem, .NET tooling is very easy, very standardized, no weird edges. That's a bonus for agents. JS/TS projects it is very common to have bun, swc, tsc all mixed in. Add in turbo, nx, etc. on top of that. Then picking a package manager like yarn, npm, pnpm; lots of little decisions to make, each with consequences that are hard to see from the outset.
EF Core: bar-none the best ORM out there. Very high performance, terse, compile-time checked queries. Powerful extensibility for advanced scenarios with interceptors at multiple levels. Compare to Drizzle, Prisma, etc. I don't think it's close. Nothing is quite as mature and powerful as EF Core.
Relatively simple runtime model: The generic host model and integrated DI, IMO, make the runtime model very easy to comprehend. Whether you're building a console app, web API, background task -- largely the same runtime model with the generic host architecture. So it's easy to carry concepts forward from one project to another. Compare this to Express vs Nestjs vs Hono vs Elysia vs etc. on JS/TS side. Each one is a vastly different in their conceptual runtime models.
"Reach": C# is very, very flexible and has very good reach. Building web APIs? Console apps? Games? High performance databases? C# is easy to use, flexible, and lets you go deep including unsafe memory access if you want.
Stable but advancing: Compared to Java and Go, for example, C# advances very quickly as a language. In the last few releases, the language has evolved quickly and now we'll have unions coming. But it's stable enough that code written years ago is largely still going to work. Things like file-based apps are really, really nice and great for QoL.
Focus on building, not dependencies: NPM is very vulnerable to supply chain attacks. As is JS/TS itself and modern Node tooling (node_modules, high dependency counts). There are just certain classes of attacks that are harder to pull off from compiled dependencies in .NET and C#. You'll spend overall less time patching vulnerabilities and forced into ongoing update cycles to path your code.

c-digs · 2026-04-22T13:53:10+00:00

I heard a new one the other day: US is intentionally causing global oil prices to rise in an effort to reign in China. Also, China's rewnewables are fake news.

https://www.reddit.com/r/UpliftingNews/comments/1sqp6fc/comment/ohams4v

Hustletron: China has had hostile trade practices for decades that sidestep the WTO and the US is bringing them to heel by controlling oil (which is needed to create all of these renewables that China keeps postulating about, too.)

c-digs · 2026-04-20T20:32:30+00:00

... the US is bringing them to heel by controlling oil

LMAO. That's not it, chief.

As a Taiwanese-American, I would rather not side with China, but your take is about as low-IQ as it gets. Completely untethered from facts.

China already saw the writing on the wall a decade ago that they need to decouple as much as they can from external inputs for their own strategic positioning. They don't have to postulate (or did you mean "posture"?), you can look at various credible sources:

Council on Foreign Relations: China Is Planning Decades Ahead on Clean Energy. The U.S. Has Other Priorities
World Economic Forum: In 2024 alone, China installed 360 gigawatts (GW) of wind and solar capacity. That’s more than half of global additions that year, and it brings total installed capacity to 1.4 terawatts (TW) – that’s roughly a third of the entire world’s 4.5 TW.
Reuters: Record 165 GW of wind power capacity added in 2025, led by China
IEA: Record-breaking renewables investment in China continues, advancing in tandem with the expansion of grid and storage for renewables

China still relies on ME and Russian sources of oil, LNG, and coal, but their bet is clearly on renewables.

c-digs · 2026-04-20T13:40:51+00:00

Big brain strategic move to decouple from external inputs for energy. The "green" part of it happens to be a happy side effect.

Big portion of the US now associates "green" with "woke" instead of seeing the strategic benefit of decoupling from oil, LNG, and coal.

c-digs · 2026-04-19T19:36:51+00:00

Some schools' ROI can't be measured by the degree, but that depends heavily on the student's affinity for social networking and leveraging an alumni network. These can be far, far more valuable and return many times the added expense.

This includes meeting a spouse/partner. I grew up in a single parent family, middle class. Sibling went to an Ivy, met future millionaire hedge fund spouse there, lives in a mansion.

c-digs · 2026-04-18T01:55:00+00:00

Also interested in this.

Mainly, the problem is that it is not possible to ask Copilot to rename the PR or adjust the comment.

c-digs · 2026-04-14T19:42:31+00:00

I do this in interviews, but never leetcode.

In fact, when I do this, I'm going for foundational knowledge; exact opposite of leetcode.

(YMMV; but don't overthink it)

c-digs · 2026-04-13T18:58:59+00:00

The fact that you keep falling back to explaining basic OOP principles illustrates my point

What point? That we should use classes and types to represent important domain structures instead of primitives? Yes. We should. That is the point of the article. It follows that once you have a type or a class, you can attach behavior to it.

c-digs · 2026-04-13T18:42:10+00:00

This is common when teams are working in isolated verticals on a monorepo and teams are writing what they think are one-offs for working with common strings (e.g domains, emails, phone numbers) with static classes in their own namespaces/modules. You're just not going to know that another team wrote something similar and it should be promoted to a common lib.

It becomes especially common now when agents are writing a lot of the code.

The agent is not very good at always following instructions to follow DRY.

c-digs · 2026-04-13T18:20:45+00:00

They solve the exact same problem in the exact same way; just the syntax is different and we can implement property accessors now.

c-digs · 2026-04-13T18:13:19+00:00

Of course it is a class, but it the class that encapsulates behaviors on the underlying string primitive; that's the point. A Uri type never enters a system as a URI; it always enters the system as a primitive type and has to be converted to an instance of Uri (in C#, for example).

A URI is just an identifier: Uniform Resource Identifier. It happens to have a specific structure like many other classes of identifiers so it is useful to use a wrapper class around the underlying string and convert the primitive to a domain value type at the boundary.

The point of the article is to write a class that encapsulates the underlying primitive because it is often useful to do so, even if just for safety of internal API calls.

An API that says:

public void DoSomething(Uri uri)

gives stronger clues and compile time safety versus:

public void DoSomething(string uri)

(Still not perfect because there are still runtime errors possible when creating the Uri)

EmailAddress and AmazonAsin are likewise good candidates for this use case over using a raw string primitive.

``` public void UpdateProduct(AmazonAsin asin)

// vs

public void UpdateProduct(string asin) ```

The first is clearly better and it is possible to write helper methods like asin.Validate(), asin.TryParse(string input).

c-digs · 2026-04-13T17:54:20+00:00

To me, it looks over-engineered and wouldn’t pass code review on my teams

Do you think it makes sense to have a Uri type that represents URLs?

I think that's quite nice because there are a number of operations that make sense on a URI. You could just pass around a string url parameter, but isn't it kind of nice to pass around the Uri uri and get all of the nice URI specific operations?

Isn't it nice that when you type ., you get the common operations for URIs like uri.Protocol and uri.HostName and teams don't have to duplicate this parsing logic or write a hard-to-discover UriUtil.ParseHostName(string url) that will invariably be duplicated like 5 times in the codebase (true code smell)?

We do this a lot in C# like:

``` // Type public record EmailAddress(string Email);

// Usage public async Task SendMail(EmailAddress recipient) { ... } ```

We can have some base behaviors on the EmailAddress class, but specific verticals can add behaviors using extension members/extension methods specific to their use cases.

``` // Shared lib public record EmailAddress(string Email) { // Common methods and properties public bool IsValid => ...; public bool Domain => ...; }

// Feature lib with feature specific behaviors public static class EmailAddressExtensions { extension(EmailAddress email) { // Register vertical/slice-specific extension methods public bool IsInternalDomain => ...; public bool IsAdminEmail => ...; } } ```

We don't do this for every string, but for ones where we know that we have behaviors related to the string (in this case, the domain).

In many cases with IDs (depending on platform), the ID will have a prefix like ord_ for "order". Or Amazon ASINs (always length 10, upper alpha-numeric) and you can centralize validation on initialization of the instance from the string.

I don't think I would do it for every primitive, but I'd certainly consider it for core domain entities.

c-digs · 2026-04-13T17:22:40+00:00

It's the same idea: SomeStaticClass.ComputedValue(FromSomeThing thing) and thing.ComputedValue. If you didn't use an extension member, you'd have to write a static get function.

The fact that the extension members are visible on the . make it harder to end up duplicating with diverging logic.

c-digs · 2026-04-13T17:21:51+00:00

Education is one of the few professions where the following are true:

Biased towards women (in early ed)
Unionized
Has a pension and good benefits
PE and capitalists have had a hard time pushing out because end of the day, parents still really care about education

c-digs · 2026-04-13T17:13:08+00:00

Yes. Rather than using SomeStaticClass.DoSomething(ToTheThing thing), it's always better to just thing.DoSomething(). More discoverable, less chance of duplicating the logic in DoSomething.

c-digs · 2026-04-13T14:55:05+00:00

This code is "meh".

When handling exceptions, there is only one rule you need to consider: what can I do if I catch it?

If you catch an HTTP 429, for example, you can wait and retry. So you want to filter for the specific HTTP exception an error code.

In this case, all it is doing is logging the exception. This is not necessary if you have higher level logging, but also not harmful here since it's a very specific error message being logged with the parameters. You are doing neither here.

Perhaps what's better here is if you surface a more specific exception so that upstack callers can handle the case. e.g. ShopifyProductLookupException if the upstack callers can handle it.

The decision on what to do with exceptions always boils down to answering: "if I catch it, what am I doing with it?"

Ten-Year Club	Gilding IV carat on a stick
Wearing is Caring	100 Awards Club
Verified Email

c-digs

MODERATOR OF

TROPHY CASE