seamapi / edgespec Goto Github PK

Middleware should be allowed to declare parameters that get merged with route-level parameters.

For example, if there's an authentication middleware that relies on a property called access_token being present in the JSON body, it should be able to declare this directly on itself and receive the parsed value.

Alternatives:

• await req.clone().json() (.clone() is necessary to avoid consuming the body). Simple but untyped, adds overhead, and dependent properties will not propagate to codegen.
• parse request input, run user middleware, then run internal request validation middleware. Requires auth dependencies to be declared at the route level rather than the middleware level for types to propagate correctly.

Should generate:

• OpenAPI spec
• TypeScript route spec
• Zod types?

We should come up with a better API here

and test

Internal conversation: https://hello-seam.slack.com/archives/C067LNPPKR7/p1707068927166089

Originally posted by @codetheweb in #67 (comment)

edgespec bundle should accept a --platform flag. To start out, the only available option will be vercel. When it's vercel, edgespec bundle will output Vercel's Build Output format. This can also be specified in edgespec.config.ts.

import type { EdgespecMiddleware } from "edgespec" or import { Middleware }

useful for typing something like this:

throws a type error:

export const withDb: Middleware<{ db?: Database }, {db: Database}>

export const withLanAuth: Middleware<
{ db: Database },
  { device: StoredDevice }
> 

Right now it's loaded for every test worker, and requiring the config isn't free as esbuild needs to transform edgespec.config.ts to edgespec.config.js.

Using node imports fails

Due to using the next based middleware model, we can't easily ensure type-safety on next(req), since the request we get will be of a different type than the one we return.

If you're serving static assets, the api prefix is confusing, my projects have api/api/health.ts a lot

Currently a 500 is thrown but not enough information is given to resolve the error.

Here's an example of how Hono does it:

https://github.com/honojs/create-hono (combined with https://github.com/honojs/starter)

and test

Setting auth in edge specs doesn't currently do anything

Would be nice to have CI checks for build, typecheck, format, etc. Especially now that we have a lot of cooks in the kitchen.

A number of files seem to not have formatting applied for instance...

cc @razor-x

Currently when you don't provide a json response, you get a type error if you return a response.

We need an adapter that allows you to host an EdgeSpec application on a Node server that's already running (the current Node adapter starts its own server).

If your route spec is:

withRouteSpec({
  queryParams: z.object({
    filter: z.string().transform(s => s.split(","))
  })
})

edgespec will write the type as

{
  queryParams: {
    filter: string[]
  }
}

instead of the correct

{
  queryParams: {
    filter: string
  }
}

Zod provides z.input<typeof schema> for this use case when using types. There's also a _input property available on schemas that seems to be the same thing as a value.

I was confused for a bit because I forgot a return statement, for some reason it also wasn't type checked, but I think having a nice runtime error is good

This is causing a type error in the node adapter right now

For now I'm probably gonna introduce WithEdgeSpecRequest<T> = T & { pathParams?: ... } or something like that, since that seems like the least controversial option for now

Emulating WinterCG is a way forcing endpoints to be maximally compliant with the standard, but just like with databases, people rarely build for multiple targets. We will suffer from the Lowest Common Denominator problem because every environment has additional features that users will want to access.

We should be the best standard for building APIs, and allow users to build for multiple targets and make usability a higher priority than compliance to maximize adoption and reduce initial onboarding struggles.

However, in edgespec init we should allow users to select this constraint.

As an anecdote, wintercg-minimal failed to build one of my projects, the build error was difficult to parse #35 so I gave up using edgespec. When I woke up this morning I felt a bit more confidence so I dug in and figured out it was the wintercg emulator and figured out it could be disabled, but our users won't have this same determination- this is mostly unrelated to the issue above since the emulator will eventually stabilize, but there is something to be said about being generous with emulation by default (lifting environments to the WinterCG standard without constraining them)

and test

And test

I think this is not happening right now, we might need to include it as part of tsc or something

https://hello-seam.slack.com/archives/C067LNPPKR7/p1707069122710619

and test

It's currently not possible to use pg if you're running edgespec bundle, this limits the ability to package module services for use in Lambdas.

We could do dependency exclusion, but I think it would be better to just disable compatibility entirely and only bundle dev dependencies.

Error in withErrorResponse middleware: InputParsingError: Error while parsing JSON body