> In 10 nautical miles (19 km; 12 mi) the aircraft lost 5,000 feet (1,500 m), giving a glide ratio of approximately 12:1 (dedicated glider planes reach ratios of 50:1 to 70:1).
> Air Canada Flight 143 came to a final stop on the ground 17 minutes after running out of fuel.
cell surface protiens go through a turnover in similar fashion to mRNA. protiens are chemically and phsyically more robust than mRNA however due to thermokinetic damages etc. protiens must eventually be decommisioned and replaced by new updates [likewindows10]. cell membrane turnover also occurs. this is a recovery of the cell toward its central tendency. in strictest terms the expression of the novel protien is damage, but not to the extent that the cell must be destroyed. Cells have timeline leading to proceedural, and also programmed cell death, this is a case of the needs of the many [tissues, whole organism] outwieghing the needs of the one or few.
there are many quotes regarding ~every Xmonths you are a new person.
The client can do `makeRequest('createProduct', ...)` and the Express server can use `registerEndpoint('createProduct', ...)` which must adhere to the schema defined above.
TypeScript's structural typing helps a lot here.
Of course, I can "lose" typing through things like raw SQL queries (working on a mini db helper library to help with that), but so I'll have to validate that the endpoints return what they say they do through tests (probs using io-ts).
I'm just getting started (coming from Rails). Not sure what the "correct" way to do this is, but my approach works so far. Would also be nice to have a generic way to create REST endpoints for a given resource, but meh.
Let me give you a head start: what you want in TypeScript is type guards. You pair runtime validation with type refinement, and if you start with good composable primitives, you can declare runtime structures and get compile time safety for “free”. That’s how io-ts and the various other libraries in that space work.
If you combine that with generics on whatever function defines your routes, you can validate API boundaries and business logic boundaries in the compiler. This applies to any boundary (I could link to Gary Bernhardt on that topic but I’m on phone), and you can do it as generically (like you said, io-ts) or specifically (take a look at zapatos for type safe SQL) as you like.
For HTTP boundaries, I’ll drop some pseudocode of how I’m doing this in my library:
type HTTPVerb =
| 'delete'
| 'get'
| 'head'
| 'options'
| 'patch'
| 'post'
| 'put'
| 'trace';
interface HTTPRequest {
readonly method: HTTPVerb;
// ...
}
type HTTPRequestDecoder<I> = (request: HTTPRequest) => I;
type HTTPResponseEncoder<O, R> = (output: O) => R;
type HTTPRoute = IrrelevantForThisPost;
type Handler<I, O> = (input: I) => O;
type HTTPRouteFactory = <I, O, R>(
path: string,
decoder: HTTPRequestDecoder<I>,
handler: Handler<I, O>,
encoder: HTTPResponseEncoder<O, R>
) => HTTPRoute;
type Route = {
readonly [K in HTTPVerb]: HTTPRouteFactory;
};
Fwiw I didn’t type all of it on my phone, I copypasta’ed from a draft blog post then manually indented lol. The approach you’re showing makes sense and it’s not unlike how I’d approach a one off/internal project where I know the routes are all defined in a predictable structure. The benefit of the pseudo types I shared is that the only predetermined structure is the route factory call. It only needs to know input output and serialization types. It can be extended to use TS 4.1 template literal types to validate path parameters. But it’s application agnostic.
