Same, but with ASP.NET (which produces an OpenAPI specification) + Entity Framework on the server, React + TypeScript on the client (which consume that specification through openapi-generator).

https://github.com/OpenAPITools/openapi-generator

I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease of long-term support, at least without going to very niche technologies where you'll have other problems.

Database schema is generated from models described in C# (or reverse-engineered from an existing schema). You don't have to compromise your schema to satisfy the ORM (another claim I often read on HN), as it's very adaptable to your needs.

Migrations are generated automatically — change your models, ask it to generate migration code in C# + a SQL migration script, review the generated SQL, and apply.

The vast majority of database queries (pretty much everything besides reports) is written in type-safe LINQ, which makes it easy to refactor code, and also construct & combine queries at runtime. Unlike that specification abomination JPA expects you to use, LINQ queries look something like this:

  var latestOrders = _db.Orders
    .Where(ord => ord.CreatedAt >= DateTime.Today)
    .Where(ord => !ord.Deleted)
    .OrderByDescending(ord => ord.CreatedAt)
    .Take(25)
    .Select(ord => new {
      OrderId = ord.Id,
      Customer = ord.Customer.Name,
      CreatedAt = ord.CreatedAt,
      Products = ord.Products.Select(prod => new {
        ProductId = prod.Id,
        Title = prod.Title,
      })
    })
    .ToList();

If you change your schema and forget to update one of the queries accordingly (although using an IDE makes this pretty much impossible), your code won't even compile.

That sounds impressive.

Do you still need to pass around "Data Transfer Objects" to do simple parameter binding?

They form the type safety

This is very backend-centric. It can't compare to a framework like SvelteKit or NEXT or NUXT, where the primary benefit is also shipping your tightly-integrated frontend code to the browser. .NET apps are old school, full refresh apps unless you are also using a separate frontend framework like React or Vue standalone. And that adds a lot of time and overheard.

Everything you described in terms of easy migrations and querying is exactly what Prisma gives you in the stack the OP described.

They are describing using .NET as an API providing a typed OpenAPI contract (aka swagger).

Nothing about that is “full refresh” and you can use whichever frontend framework you like.

> .NET apps are old school

Microsoft has invested massively in modernizing .NET and C#.

It is also widely praised by devs - .NET is ranked 4th most loved framework in the SO 2022 dev survey.

You have built-in scaffolding to get a React + .NET app right from the CLI, with hot-reload and all the facilities you'd expect.

Hardly old school at all. Personally, if I had to build a website with a thin API layer I'd reach for NextJS (or equivalent) alone, but anything beyond that I'd go for .NET Core any time of day.

Exactly.

With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models.

With Next, there's true code reuse between client and server. Next is smart about shipping your code where it needs to run, server, client, both. You can even mix and match from page to page: Server-side render one page per request; statically generate another at build time.

As much as I like ASP.NET, Next has leapfrogged it for web apps.

> As much as I like ASP.NET, Next has leapfrogged it for web apps.

Look, I like NextJS as much as the next guy - I'd say it's my main working technology right now. And I've never built anything on .Net - I know its characteristics from watching tutorials and reading docs.

My take however is that "web apps" is a very broad world. NextJS gives you a thin API layer. There is no model layer to speak of. You're left fending for yourself in the wild, wild world of JavaScript.

.Net Core, on the other hand, offers a batteries-included, heavy-lifting, opinionated framework, with an immense toolbox and many conventions to guide you. There has to be a reason why people speak such wonders of it. If I had to build something enterprise-y with more than handful of devs it would probably be my choice.

If anything the model layer in Next.js is superior because you can use the same model layer to build the page SSR, and then Next.js will gracefully transfer the entire model layer over to the client where your app can continue to work against it.

> I've never built anything on .Net

The grass isn't greener. I've built in both - I have a .NET Core/Angular SaaS app that I created and sell, and I've been building greenfield in Next. I much prefer Next.

The duplication in .NET/Angular has never been worth it...not once. And having network calls for everything is unnecessarily painful.

I started the app in 2019, when RESTful SPAs were all the rage. I bought into the hype that you should have API endpoints for everything no matter what, because you'd soon have a mobile app and daemons and this and that.

Turns out, YAGNI. It would've been better to server-side render and only create API endpoints when necessary.

That's what I like about Next: Static generate where you can, server-side render per request where you can't, SPA where necessary - and the layers are as flat as can be. It's the best of all worlds.

That being said, I've worked in .NET for ~16 years now, and I like it more than JavaScript/TypeScript. But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.

> But I'd still rather develop a web app in Next and put any background services elsewhere in .NET if needed.

Thanks for sharing your perspective.

I think we're essentially saying the same thing. I would start pretty much 99% of my projects in NextJS. But if I needed to reach for something doing complex logic and scaling to a larger team, I could always add a .Net service to that later.

> With ASP.NET, a React/Angular project is separate, there's a separate model layer, and you have to keep that in sync with the .NET models.

The separation of models is indeed inevitable when there is JS on the client and not-JS on the server. That's a 'problem' common to all non-JS back-ends.

However there are three points I'd make.

1. That's often a good thing, not a flaw, in that it enforces a mapping boundary between what the server and the client know and therefore strongly discourages leakage of data.

2. Mapping requirements of this type are much too trivial to base a tech stack choice on. It's barely worth considering given that mappings only need doing once and updating once per change. They are also very good protection against accidentally exposing new stuff precisely because changes in models don't automatically impact the client.

3. If this model syncing was really an issue (it usually isn't) you could try Blazor. By doing C# on the client as well as the server you get to share the same code/models. As per point 2 I don't think that's a good enough reason to switch tech stacks, but Blazor also has its place.

> 1. That's often a good thing, not a flaw, in that it enforces a mapping boundary

That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity.

> 2. Mapping requirements of this type are much too trivial to base a tech stack choice on.

Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup.

> 3. If this model syncing was really an issue (it usually isn't) you could try Blazor.

Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does. Sure, you can integrate, but you're just making life more complicated for yourself. It feels like too little, too late.

One man's mandatory busywork is another man's separation of concerns.

> That just sounds like mandatory busywork that may or may not prevent poor programming practices. I'd rather pick a framework for productivity.

Mandatory busywork implies stuff with no real purpose. I specifically pointed out the purpose. You may not agree with the cost/benefit involved in doing it, but that's a preference and doesn't automatically make someone else's way of working busywork. And personally I find it increases productivity by eliminating a whole range of security concerns.

> Trivial for large corporations with money to burn, maybe. A huge time-waster for my startup.

This largely depends upon if you accept that the work itself is of benefit. If you believe it's just busywork, then whilst my own opinion differs, your conclusion is reasonable for your situation.

> Blazor is cool, but the bundle sizes are still too large right now, and it doesn't have the ecosystem of web components that JavaScript does.

You're right on the sizes and the ecosystem (though that is not Blazor-specific and is something no non-JS client-side tech will ever be able to compete with).

I do ASP.NET and Blazor (alongside Node, Go, Python, Rails etc) and TBH whilst personally I see great value in Blazor it feels like that's mostly for back-office or enterprise applications where you get the incredible productivity (that much is true) and don't need to worry about the sizes or, depending on how you implement it as this is optional, the need for a persistent web-socket connection.

That sounds nice for the main user interaction, but what about when you need more heavy lifting of async tasks and side effects?

Like I get a shared model being accessed "directly" for the things that the UI displays and manipulates. But once you click an Order button you have transactions to process, ledgers to update, notifications to dispatch.

That kind of code doesn't float between client and server, it needs to happen once the order has been received regardless of the client state.

You can offload that to other services, lambdas, etc. but that's the sort of thing that you can just do all-inclusive in a standalone backend be it Node, .NET, Go, etc.

If you need to create a more complex application, you still would do that as a separate API project that your NextJS application would query...

If you have .NET 6/7 installed, give this a try:

    dotnet new webapi -minimal
    dotnet run

I know there's been a lot of discussion about whether .NET/C# are faster than X or Y or Z based on TechEmpower benchmarks, but this will give you a backend that looks more or less like Express with an OpenAPI schema built-in (generate TS bindings for frontend) and a runtime that is going to be higher thoughput than Express or Node.

    dotnet watch

And you get hot reload.

That's not what GP is talking about, though. I like the new .NET minimal APIs, but what GP is talking about is the frontend/backend _integration_ with a framework like Next.js.

Next isn't really like Angular in that you don't need an API layer (though you can have one if needed). It's more like ASP.NET Core MVC.

The difference is the frontend code is truly integrated with the backend. It all lives in the same project. It's just React components. You can render them statically on the server at build time, per request at runtime, or on the client. And you can mix and match. Next only ships the client the JavaScript it needs.

You don't need an API unless you want SPA parts of the app. Where you do want that, it's simple to implement, because you're already in JavaScript and all your other code plays nicely with it. It's a really nice way to organize and consolidate the different pieces of web dev IMO.

Could you go into a little bit more detail?

> I chuckle every time I read claims about Go (or whatever) being amazingly productive

You can get the same'ish with Ent and Atlas

I am very slowly building a big glue between DB and front-end and making it pluggable into their underlying libs and native libs

> Database schema is generated from models described in C# (or reverse-engineered from an existing schema). You don't have to compromise your schema to satisfy the ORM (another claim I often read on HN), as it's very adaptable to your needs.

Generating the schema from the models is easy mode, the ORM naturally won't generate anything it doesn't understand. The claim is that the ORM can't handle advanced schema features that it wouldn't generate. (Although in my experience most people claiming that just never bothered to learn the ORM).

If your are going to mention .NET in this context, why not mention Blazor?

With Blazor you just write both the reactive frontend and backend in C#. No need to write Javascript. Super productive, type safe all the way.

Today it has even support for hot reloading. Save your C# and see the changes in your browser.

Last time I looked at Blazor it only had two options, which were both equally horrible for public websites.

You either had to ship a big and bloated WASM file, which was at least 10x the size of competing JS frameworks, and in some cases 100X the size. Or you had to render all dynamic parts of your website on the server, which made latency a huge problem, since your website feels sluggish between each interaction.

I don't know when it was the last time you took a look at Blazor, but Blazer server is extremely fast. I built some big corporate apps with it and never had any latency problems.

Were they internal or external apps? Because latency was the problem last time I looked, and it won't be super noticeable if you have the servers that close to you.

Because last time I looked, the Blazor binaries were huge, and had performance issues?

It's also irrevocably attached to that specific dotnet framework? Want to evolve parts of your stack? Too bad.

* The payload of WASM makes it a difficult choice if serving mobile or regions with poor internet and you want a good first impression.

* Server side needing a constant socket for everything presents it's own limitations.

* It has hot reloading, but it pales in comparison to the JS experience at best and in my own experience has a lot of edge cases leading to full rebuilds.

* C# tooling is fantastic; Razor however I've found to be slow and well behind the experience of popular JS libraries.

* When you do need JS interop (e.g. browser API's) the experience is, IMO, awful.

I feel Blazor's niche is internal, simple LOB apps and I can understand the appeal if you don't already know JS or have some serious regulatory requirements around vendors and need to avoid NPM.

Personally, I find the DX and quality of the end product in svelte kit trump the code sharing of Blazor.

Blazor is a non-starter if you care about payload size and startup time. Fine for intranets but not much else.

For local development do you run two servers, next and asp and then for dynamic api calls by the client do you proxy the request through next or go directly to the asp server by its port number?

Similarly in production do you use a reverse proxy for the asp server so that requests to like /api go to the asp server?

I agree with the sentiment--and with most of your comment--except the assertion that "I don't think it's possible to beat this stack".

I have something similar: Kotlin on the server-side with my SQL DSL generated by jOOQ and Flyway running my schema migrations. I don't have any experience with LINQ--but it looks to be of a similar idea to jOOQ such that you get an autogenerated, injection-safe, type-safe, compile-time-checked SQL DSL.

If you like LINQ, you'd probably really like jOOQ. It's uber-powerful and the only queries that I've not been able to completely write in jOOQ are geo-spatial queries--and even for them, I can use string SQL for just the one where-clause predicate where I need to go off-the-rails--the rest of the query still being standard jOOQ. The thing I like most about it, is that the queries that I write in the DSL are sooo close-to-the-metal of pure SQL--I'm not even context-switching between SQL and jOOQ really. Check it out!

Also have to sing praise for Kotlin, flyway, and some type-safe db framework.

I’ve recently been migrating projects from jOOQ to SQLDelight. While not as feature complete, being able to write queries in sql and then generate type safe code has been amazing. My biggest issue with jOOQ has been joins where you lose some null safety and general issues with the generated POJO (which admittedly has improved over time). With SQLDelight, it has felt like the database just fades away when writing Kotlin.

jOOQ is not even close to EF LINQ, I worked with both.

I think parent meant “stack” for every similarly high level, statically typed language. I can vouch for Spring (Data) with JPA. The criteria api is also very great.

> I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease of long-term support

It's easy to beat Open API, it adds friction, generates ugly code and has a suboptimal UI. If you use https://servicestack.net you don't to rely on an intermediary external tool, you can generate clean TypeScript DTOs directly from strong C# typed models, that only needs to generate the clean DTOs for your typed APIs (i.e. without the ugly client proxy) as all generated DTOs can be used with the smart generic Service Client, which works the same way across 9 popular languages [2], maximizing reusability and reducing any porting efforts if needing to support Mobile Apps in future. It works even better in .NET languages where if you properly design your Service Layer [3] into a impl-free project you can avoid code-gen entirely and share the DTOs that define your typed Service Contract with .NET clients enabling an end-to-end Typed API without code-gen, which dramatically improves Dev UX in C# clients like Blazor [4] since you can add/modify APIs whilst your Service is running.

We also maintain a better integrated and UX Friendly API Explorer [5] that Open API's Swagger UI which generates richer, validation bound customizable Forms directly from your Typed DTOs, better discovery and API docs and a "Code" tab which gives API consumers step-by-step instructions for how to easily call your Typed APIs in their preferred programming language [6].

[1] https://docs.servicestack.net/typescript-add-servicestack-re...

[2] https://servicestack.net/service-reference

[3] https://docs.servicestack.net/service-complexity-and-dto-rol...

[4] https://servicestack.net/blazor

[5] https://docs.servicestack.net/api-explorer

[6] https://docs.servicestack.net/api-explorer#code-tab

Look, mate, I do unironically appreciate a good enterforaprize sales pitch, but this is a nerd space so corporate marketing wank is in fact actively counterproductive for the purpose of evangelising what's actually pretty neat tech.

To everybody else reading this - mythz' tone deaf bullshit wasn't my favourite way to be reminded I have a gag reflex but the URLs are well worth a look.

Add a `String.Equals(thing, thing2, StringComparison.OrdinalIgnoreCase)` in your where clause and now you're full table scanning.

LINQ makes things easy, but has traps.

I generate backend and frontend types in 2 seconds with Go, after I define the model structs.

I laugh at your slow running, resource wasting .net

Personally, I'd remove tRPC on down (and choose a database).

It's nice there's type-safety between layers, but that's a bunch of layers that you don't even need. (A layer that doesn't exist takes is 100% type-safe and takes 0 hours to develop and maintain).

In Mongo you don't need to manage a schema, because it's SCHEMALESS! /s

> A layer that doesn't exist takes is 100% type-safe

How are you ensuring your database accesses are type-safe in this case?

That's fair... I do typically have a layer that sits at the level of an ORM, whose purpose is to reduce boilerplate and handle/verify types.

So I can't really claim I have nothing at the ORM level... However...

In my experience, when you pull in an off-the-shelf ORM and an off-the-shelf RPC framework you end up building app-level wrappers anyway to deal with the complexity and impedance mismatch between what you want your app to use for data access code and what layer provides.

So I think you might as well put your app-level database wrapper as directly around the database as you can manage (that probably means using the common, unopinionated client for your db... e.g., node-postgres for server-side javascript and postgres, or whatever the equivalent is for your backend/database).

I use the same, but with Hasura and Next.js with GraphQL

+ Next.js

+ GraphQL Zeus / GraphQL Code Generator (typed calls between frontend/backend)

+ Hasura (generates GraphQL API for database)

We do something similar. GraphQL type generation is pretty amazing, especially with heavy use of co-located queries on the FE and a typed ORM like prisma on the BE.

Same here. I use Apollo Client. React. Hasura

I'd love to hear about your testing story with Prisma. I recently looked into it but was disappointed to see the recommended approach was more or less to nuke the contents of the DB (https://www.prisma.io/docs/guides/testing/integration-testin...) instead of just rolling back a named transaction at the end of a test (a la https://hexdocs.pm/ecto_sql/Ecto.Adapters.SQL.Sandbox.html, or just about every other framework I've used with Ruby or Elixir).

> This is how I move fast and break nothing

Absolutely impressive how you are one of the first to find a approach that leads to a 100% bug-free development methodology.

Or, you still have bugs right, so sometimes things break? Maybe you meant something like: This is how I move fast and don't have a certain section of bugs anymore?

I bet they don't even move "fast" since that's relative and we haven't determined any baseline paramters. Very misleading. The comment should be "This is how I move (metaphorically speaking, not physically e.g. increased typing speed) with what I perceive to be faster than alternative stacks that I have explored and that doesn't have a certain section of bugs anymore".

I wonder if with Next.JS server components, we can just get rid of tRPC + trpc-sveltekit.

I'd love to browse a sample codebase.

Do you know of any non-trivial open source projects using this stack?

Thanks. Here's the SvelteKit example linked on that page:

https://github.com/icflorescu/trpc-sveltekit-example

Anyone know a good way to solve Prisma memory usage? We use a database per customer and each one adds 50-80mb of RAM. Our backend currently consumes 2-3GiB of RAM to host less than 100 customers...

App server has GC pauses of 50-80ms as a result of the memory usage.

how many customers do you have?

If you use a database per customer you should also run a node process per customer. I don't know what exactly you're selling, but that bit of RAM should be in budget alone for the reason that you don't want the requests of customers slowing each other down

I recently jumped over that "trying to minimize resources" hurdle myself because it's just not economically correct for me to spend even an hour of my time when I can host a few months worth of servers for that money

Curious how you handle `request.formData()` in Form Actions and ensuring type safety there.

> Curious how you handle `request.formData()` in Form Actions and ensuring type safety there.

Hopefully the same way typed programming languages do it: parsing and type checking.

We use and recommend Zod for that:

https://github.com/colinhacks/zod#error-handling

Like any user input, you do runtime type-checking and validation. TypeScript is especially great for that because it has type narrowing [0].

[0] - https://www.typescriptlang.org/docs/handbook/2/narrowing.htm...

How are you liking Prisma compared to a pure SQL approach?

When I used prisma a few years ago I was not impressed and it couldn't do a lot of what I needed so I had to dump into raw sql queries anyway. It was easier for me to use knex and get the types mostly right.

You should take a look at ts-sql-query [1] - it is not as popular as the older alternatives that have been around for a while, but it is a very feature rich query builder that takes type safety very seriously and supports most mainstream databases.

[1] https://ts-sql-query.readthedocs.io

A lot has changed in the past years of Prisma, it's a really great tool, to be honest, "raw sql" escape hatches to do anything raw when you need it, if you haven't tried it in years, I'd recommend you to try again since if you tried it years ago, it was a very different maturity level.

Do they (Prisma) still rely on a Rust sidecar? This caused multiple issues with container deployment and the CI/CD pipeline of my employer.

I believe the sidecar is optional now, and I think even the one that exists comes in the form of their paid service called Prisma Proxy. It doesn’t seem necessary for most use cases.

I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything. One example is our ODATA query and client library, which makes it incredibly easy to debug issues related to it, because everyone uses it.

Anyway, the one place where Typescript isn't great in the fullstack approach is the Database stuff. We used Prismo for the better part of a year, until we eventually moved on to Mikro-orm which has been great so far.

I'm personally not a big fan of OOP or "over architecture", because I've seen how bad it can go too many times. Instead I favour functional programming and keeping things as simple as possible, even having "almost duplicate" code once in a while. So with this in mind, it may strike you as odd that we moved from Prisma to Mirko-orm, but Prisma just clashes with the way we want an ORM to work in so many ways.

Maybe this is by design. Prisma doesn't want to be a "real" ORM after all, but things like having to put everything in a single schema file is bothersome. Yes, you can put it in different files and then cat them together, but that leads to other issues. Like the VSC Prisma extension highlights not working outside the main Prisma.Schema file. More than that though. We like to have "ID, UpdatedAt, UpdatedBy, CreatedAt" sort of things on basically all our models, and since Prisma doesn't have the inheritance I almost never use, that means you need to duplicate it soooo many times. It's also hard to write generic methods for basic CRUD stuff because of the way Prisma uses the Prisma Client Classes it auto-generates to operate. On top of that, migrations can't go backwards in Prisma.

Some of these issues are on the Prisma road map, others aren't, and you're always going to bang heads with an ORM, but Prisma just didn't feel as mature as it's extremely excellent documentation (and marketing) might lead you to believe in my experience.

I can certainly see myself using it again, once their roadmap is a little further ahead though.

Duplicate code is one of the biggest near-non-problems programmers waste a ton of time trying to address.

Sure, duplication isn't a goal, but DRY shouldn't hold back work as long as it has no meaningful consequence on performance. In some cases, duplication is a good thing, but your average programmer will address duplication by making a routing more complicated and further away from where it's being used. This is often a mistake.

Worse yet is when programmers DRY up tests. Tests are the worst place to be applying DRY. The point of testing isn't to write an entirely new application on top of your actual application. If you're DRYing up your tests a lot, you're probably writing a second application and should probably stop doing that.

> I'm not the person you ask, but we use fullstack Typescript in our dev department. We're a weird mix of a green energy company and an investment bank, so inhouse development is very small-scale, and this means you share resources. Using one language for everything helps with this, since the one person who is really good at React can take a vacation or a sickday without being glued to a laptop since everyone else can also work on the front-end even though it's not their daily thing (and vice versa). More than that though it lets us do things like code reviews, troubleshoot solutions and generally work together really well, even though we're working on very different projects. It also lets us build libraries that can be used for everything.

We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend. It's very nice.

> We do this the other way around, by using Scala.js so we can use Scala on the frontend as well as the backend.

I've wondered about this approach for a while, but have yet to actually try it in any meaningful context. Do you use a framework like React via Scala.js, or are you doing something different?

Yeah it's React and some component library etc.. Library interop is pretty good if the library has type information available, and most of them do these days.

I'm using prisma with postgres. It's pretty nice. You define all your tables in their custom schema format which has VS Code integration and lots of type checks so it will tell you if there's a problem with the schema. You can generate types from the schema file automatically and also a statically typed ORM layer that will let you write queries against those tables with full code completion. It also will generate migration scripts for you when your schema changes.

It's not as good as EF by a long shot (nothing really is), but for most queries it works fine. You can also use SQL or stored procs for the exception cases which no ORM ever fully replaces anyways.

Very interesting to hear some feedback on how Prisma is compared to like EF. Perhaps better to use EF + graphql layer?

How do you typically deploy such a stack?

You should also mention Zod, which acts as the type safe glue between the different boundaries.

I have been using Google Sheets as a kind of hacky database. By defining the schemas in Zod I am able to automatically validate my sheets data and coerce the string cell values into their proper types.

Zod schemas can be used all over the stack, imported for form validation, and avoid heaps of duplication and tests.

While Zod is hyped by Next.ja developers (I think mostly because Theo Brown has such a huge reach), I think Ajv is better, because it lets you generate OpenAPI documentation and it fully json schema compliant.

I really like nextjs for its opinions on the frontend part, but it is lacking these strong, but great opinions on the backend. Wish love to see some design decisions from fastify adopted here. Matteo did really do some great stuff.

Zod has plugins that let you generate OpenAPI specs (and TS types, and JSON Schema, etc.) from your Zod schemas, so if that's the only reason you think Ajv is better, then it might be time to take another look at Zod? It really is great, especially if you buy into the "parse, don't validate" principle that it's built around.

Fastify is excellent. I wish these new full stack frameworks were closer to that.

What is the benefit of tRPC over built-in SvelteKit data loading?

I prefer static types all the way, but my looser rule I've come up with in order to play nicely with others is that you're not allowed to interface something with poor type definitions/enforcement with another thing that's also bad at that. Including transport/wire formats, so if you're presenting JSON you'd better be able to tell me a good story about type safety on both the sender and receiver.

That at least keeps the blast radius of type-related bugs very limited, and makes it easier to figure out where the problem is.

Might I recommend https://jawj.github.io/zapatos/ to remove the last 3 lines of your stack.

Nice share!

Postgresql > PostgREST > Elm

Openapi, then codegen on both ends — frontend (orval) with TS and react-query, and backend with golang (openapi codegen) for the server's request and response objects.

Works a treat.

How well does tRPC work if the API consumer isn’t built with TypeScript?

I haven't used this, but check: https://github.com/jlalmes/trpc-openapi