@ts-rest/core - npm Package Compare versions

Comparing version 0.1.1 to 0.1.3

package.json

		{
		"name": "@ts-rest/core",
		"version": "0.1.1",
		"version": "0.1.3",
		"description": "RPC-like experience over a regular REST API, with type safe server implementations 🪄",
		"type": "commonjs",
		"license": "MIT",
		"keywords": [
		"rpc",
		"rest",
		"typescript",
		"typescript-rest",
		"http",
		"api",
		"type safe"
		],
		"main": "./src/index.js",
		@@ -8,0 +17,0 @@ "typings": "./src/index.d.ts",

README.md

		@@ -11,3 +11,3 @@ # ts-rest

		I _love_ [tRPC](https://trpc.io/), [KATT (Alex Johansson](https://github.com/KATT) and all the [other maintainers](https://github.com/trpc/trpc/graphs/contributors) have done some amazing work, and for applications with a single Next.js app, or an express server only consumed by TRPC clients, I whole heartily recommend using tRPC! Also I have undoubtedly taken inspiration from tRPC for ts-rest.
		I _love_ [tRPC](https://trpc.io/), [KATT (Alex Johansson)](https://github.com/KATT) and all the [other maintainers](https://github.com/trpc/trpc/graphs/contributors) have done some amazing work, and for applications with a single Next.js app, or an express server only consumed by TRPC clients, I whole heartily recommend using tRPC! Also I have undoubtedly taken inspiration from tRPC for ts-rest.

		@@ -18,12 +18,2 @@ One of the biggest differences between tRPC and ts-rest is that tRPC defines your API implementation _as the contract_, for some use cases it is beneficial to have a separate contract to represent the API.

		## Contract Abstraction

		Unlike tRPC, ts-rest-core aims to separate the contract from the API implementation, this adds another "jump" to go client->contract->server, however, this additional step provides a much better experience in Monorepos with NX.

		- Contracts should have no knowledge of the implementation
		- Contracts should exist within their own package, or within a shared library within a monorepo
		- Contracts should define all the types to be shared with the consumers

		Aside, if you really want there is nothing stopping you from building the contract alongside the implementation as you would in tRPC.

		## REST(ish) vs RPC
		@@ -30,0 +20,0 @@

@ts-rest/core - npm Package Compare versions

Worsened metrics