Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
wundergraph-demo
This Repository demonstrates how to combine 7 APIs (4 Apollo Federation SubGraphs, 1 REST, 1 standalone GraphQL, 1 Mock) into one unified GraphQL API which is then securely exposed as a JSON API to a NextJS Frontend.
-
next-rpc
makes exported functions from API routes accessible in the browser. Just import your API function and call it anywhere you want.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Types can be asserted at runtime (parsed) at IO boundaries (reading http request or response, websocket message, parsing json file etc). Once they enter statically type system they don't need to be asserted again.
The difference it makes is illusion of type-safety vs type-safety this article touches on.
You can try to bind service with client somehow but in many cases this will fail in production as you can't guarantee paired versioning, due to normal situations by design of your architecture or temporary mid-deployment state or other team doing something they were not suppose to do etc. It's hard to avoid runtime parsing in general.
Functional combinators [0] or faster [1] with predicate/assert semantics work very well with typescript, which is very pleasant language to work with.
[0] https://github.com/appliedblockchain/assert-combinators
[1] https://github.com/preludejs/refute
Types can be asserted at runtime (parsed) at IO boundaries (reading http request or response, websocket message, parsing json file etc). Once they enter statically type system they don't need to be asserted again.
The difference it makes is illusion of type-safety vs type-safety this article touches on.
You can try to bind service with client somehow but in many cases this will fail in production as you can't guarantee paired versioning, due to normal situations by design of your architecture or temporary mid-deployment state or other team doing something they were not suppose to do etc. It's hard to avoid runtime parsing in general.
Functional combinators [0] or faster [1] with predicate/assert semantics work very well with typescript, which is very pleasant language to work with.
[0] https://github.com/appliedblockchain/assert-combinators
[1] https://github.com/preludejs/refute
Alternatively, you can also just run "wunderctl init --template nextjs-starter" to start with the NextJS template. (Obviously you need to install it first: yarn global add @wundergraph/wunderctl@latest)
We're going open source with this solution soon. So, any feedback is appreciated! You can also join our discord and shoot questions. =)
[0]: https://github.com/wundergraph/wundergraph-demo
> with an implicit type contract (potentially generated) through the creation of these files
Racket is able to automatically convert static types of Typed Racket into contracts when values flow between typed and untyped worlds. This happens automatically and transparently, which means you don't have to worry about almost at all. One advantage Racket has over JS is the module system (well, it holds the same advantage over almost all the other languages), which allows typed and untyped code to reside in the the same file, yet have a clear boundary between them.
I can't find it right now, but there was a paper describing how it works. It's probably somewhere here: https://github.com/samth/gradual-typing-bib (if you're curious enough to read many tens of abstracts...)
I recommend "next-rpc" [1] which is a small library allows the nextjs client-side pages to call the API function using a type-checked function interface.
[1] https://github.com/Janpot/next-rpc