When a handler raises a non expected error we get unknown comparison, it should instead mention that the error can't be accepted. I believe this can be done by adapting the signature of the handle function

It seems like the the hard-coding of /docs as the base path for the swagger router is preventing mounting an application using Router.mountApp('/api', server) from platform. To be more specific, the docs .html loads fine, but all of the assets fail to load at /docs/{filename} when I'd really want for them to load from /api/docs/{filename}

I'm attempting to create a full-stack implementation of the "realworld" application, and the specification requires the API portion to run at /api/*, while the client rendering happens at /*.

I think just adding some kind of base path configuration would be totally sufficient, or maybe there's a way to adjust it with SwaggerFiles already?

Hey there. I love the proposal here, thanks and kudos.

Are there any plans to have a proper browser-only/client-derivation version of this?
It seems to me that the lib depends on @effect/platform (and @effect/platform-node) which forces us to go through hoops and loops to polyfill stream on a vite build.

The documentation is pretty clear that

[...] effect-http is intended to be primarly used on the server-side

but here I am, wishing for a way to use this as a browser http client.

I'll take no for an answer alright; mostly wondering if you have any comments on how hard it would be to extract (or better, isolate) that portion of the functionality.

Cheers.

Single query parameter must be treated as single element array for appropriate schema.

export const GetManyUsersRequest = {
  query: Schema.struct({
    id: Schema.array(IdUserSchema)
  }),
};

Return 400 for GET /users?id=123
But 200 for GET /users?id=123&id=456

I have tried Schema<string[], string> for 123 -> [123] but it breaks swagger UI - it renders string input instead of several inputs for array of strings

It would be nice to expose /openapi.json endpoint that returns the OpenAPI spec, as then it could be used to create http clients in other languages, or it could be used in postman, etc.

Having a cli might be handy(I'd be happy to create a PR if there's interest. I don't suspect that it would be too much work):

effect-http.config.ts

import { Router } from "src/router.ts"

export default createConfig({
    router: Router
})

Dump openapi def to file:
npx effect-http codegen openapi -o api.yml

Start test server:
npx effect-http serve -p 8000

It would be awesome if this lib migrated to the @effect/platform html client+server api now that that has seen some progress. :)

I've been continuing to work on a Realworld example application for Typed. Some endpoints will make slightly different queries to the database given if there is a current user or not. For example, if a current user is available, articles return whether or not the user favorited the article, or if they follow the author of the article.

The one thing I've stumbled across so far is that I can't define a route which has been the ability to specify optional security schemes.

I'm not as familiar with the internal of how everything comes together, but I could kind of see at least a few different APIs that could make sense. I'd love to hear your thoughts as well

Follow a little more closely to the OpenAPI Spec

I think we'd just need to allow the ability for all of the SecurityScheme fields to be optional

export const jwtToken: SecurityScheme<*> = {
  type: "http",
  options: {
    scheme: "bearer"
  },
  schema: ...
}

Api.get(..., ..., ..., { security: {  jwtToken, none: {}  }  })

I suspect staying close to that of the OpenAPI may help with generating the appropriate output, and will probably do better when your endpoint has more than 1 security scheme using an OR style relationship.

Variation

Maybe we be a bit more explicit as well, as it's hard to type an empty object in TS, and would be easier to create a discriminated union type across

Api.get(..., ..., ..., { security: {  jwtToken, none: { type: "none" }  }  })

Extend the current SecuritySchema

In this variant, I'd see adding an optional: boolean flag to the existing SecurityScheme type. I guess I'd intuit that with optional:true, your Schema would be wrapped in something like sort of nullish/optional type.

I don't know this is great when it comes to generation, because I think it'd require de-duplicating multiple optional: true schemes to map to a single "empty" entry in the OpenAPI specification. I'd also assume building and validating that schema would be more costly at runtime as well.

Ancillary thought

I don't have a real use-case for this stuff, but I think that the current definitions of security are more limited than that of OpenAPI itself. As I hinted, hopefully correctly, in the first variant, today we can we can only define OR style relationships between security schemes, but in the specification its also possible to specify AND style relationships. I don't see this as necessary for my own use cases, but I suspect it'll be asked for at some point.

I could see this happening a few different ways in itself, but I feel like just adding the ability for non-empty arrays as values in the security record would open the way up to AND relationships.

It'd all culminate to something like the following

Api.get(........., { security: {  one: [ A, B ], two: [ A, C ], three: D, none: {}  } })

In a case where there is an AND style relationship, I would generally expect the same shape to be available when writing your handler functions

RouterBuilder.handle('opId', ({...}, { one: [aType, bType] }) => ...) 

A slight variation of this would be to accept a record instead of tuples, and I'd expect similar rules to apply in that case as well.

Api.get(........., { security: {  one: {a: A, b: B } , two: { a: A, c: C }, three: D, none: {}  } })

RouterBuilder.handle('opId', ({...}, { one: {a: aType, b: bType } }) => ...) 

At present a Client derived from an API loses all type-safety in regards to any non-2xx status codes which are returned directly when making use of the Client's methods.

The way to recover access errors are via ClientError. The server-side ClientError's, which do have a status, are typed as unknown and must be re-validated manually to ensure type-safety on the client-side by hand.

In an ideal world I think these would be strongly typed by default by using the "success" channel of Effect to return all "expected", as defined by your API, instead of only 2xx status codes. This allows for type-safe transformation of all "expected" status codes into domain-specific values and/or failures to correspond with these other expected conditions.

Prior Discussion: #515

It would be awesome for testing if effect-http could generate an msw server for testing purposes w/ fast-check arbitrary data. Or maybe just make it easier to create one yourself.

https://www.npmjs.com/package/msw

It looks like new URL().toString() has some interesting behavior...

new URL("http://google.com").toString()
'http://google.com/'

This ends up with the client sending requests to /search as //search

For now we're using a string which works fine.

It would be great if there was a fn to export the generated OpenApiSpec. The schema-openapi library could then potentially be extended to render it to a yaml string.

Hello! Thank you for this library.

I am receiving the following typescript error on 0.12.1:

TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("effect-http")' call instead.   To convert this file to an ECMAScript module, change its file extension to '.mts', or add the field "type": "module" to 'package.json'.

I was not seeing this error in past versions.

Is the library no longer commonjs compatible?

Issue Description:

Currently, there's a challenge regarding the modularity and scalability of routes within the presentation layer of the application, particularly when employing DDD (Domain-Driven Design). The goal is to enhance the architecture to better separate concerns and facilitate maintainability and extensibility.

To address this issue, we aim to refactor the code to achieve a more modular approach, allowing for greater flexibility and abstraction in handling routes.

there's a way to build the routes in a way to be modular with a native technique with Effect or there is a bit limitation for now of effect-http to do that?
this is the structure of the folders
📦src
┣ 📂data-access
┃ ┗ 📜user.repository.ts
┣ 📂domain
┃ ┣ 📂user
┃ ┃ ┗ 📜user.model.ts
┃ ┗ 📜models.ts
┣ 📂entry-points
┃ ┣ 📜routes.ts
┃ ┗ 📜server.ts
┣ 📂presentation
┃ ┗ 📂user
┃ ┃ ┗ 📜user.route.ts
┣ 📂test
┃ ┗ 📜.gitkeep
┗ 📜env.ts

in order to be scalable and preserve the modularity i tried this way per example using DDD, having three layers, first the presentation layer, the domain layer and the data-layer, the main issue is in the presentation layer i need to pull up the implementation of the route away from the main pipe to run the effect

src/entry-points/server.ts

import { findAllUsers } from "@api-gateway-app/presentation/user/user.route";
import { NodeRuntime } from "@effect/platform-node";
import { Effect, Layer, LogLevel, Logger, pipe } from "effect";
import { RouterBuilder } from "effect-http";
import { NodeServer } from "effect-http-node";
import { PrettyLogger } from "effect-log";
import { AppRouter } from "./routes";

export const debugLogger = pipe(
  PrettyLogger.layer(),
  Layer.merge(Logger.minimumLogLevel(LogLevel.All))
)

pipe(
  RouterBuilder.make(AppRouter, { docsPath: '/api', parseOptions: { errors: "all" } }),
  RouterBuilder.handle("findAllUsers", ({ query }) => findAllUsers(query)), // ==== i want to move this handle away from 
  // the pipe ( the best i can do for now is this passing the callback with the implementation but isn't the goal )
  RouterBuilder.build,
  Effect.provide(debugLogger),
  NodeServer.listen({ port: 3001 }),
  NodeRuntime.runMain
)

src/entry-points/routes.ts

// this implementation of definition of the AppRouter is Ok because from here we 
// can define from each scope int presentation layer in this case is user but can be 
// added others scopes / collections
import { userApi } from "@api-gateway-app/presentation/user/user.route";
import { Api } from "effect-http";

export const AppRouter = Api.make({
  title: "API Gateway",
  servers: [{ url: "http://localhost:3001" }],
}).pipe(Api.addGroup(userApi));

import { Criteria, getPaginatedResponse } from "@api-gateway-app/domain/models";
import { User } from "@api-gateway-app/domain/user/user.model";
import { pipe } from "effect";
import { Effect } from "effect";
import { Api, ApiGroup, Security  } from "effect-http";

// this is perfect because in the presentation layer we define the interface of the endpoint
export const userApi = pipe(
  ApiGroup.make("Users", {
    description: "All about Users",
  }),
  ApiGroup.addEndpoint(
    ApiGroup.get("findAllUsers", "/api/users").pipe(
      Api.setRequestQuery(Criteria),
      Api.setResponseBody(getPaginatedResponse(User)),
      Api.setSecurity(
        Security.bearer({ name: "mySecurity", description: "test" })
      ),
    )
  )
);

// this is my concern and the ugly part (its working though) that only can
// export the callback of the implementation but no the actual implementation definition, 
// this should be place the RouterBuilder.handle()
export const findAllUsers = (query: Criteria) => Effect.succeed({
  data: [{ name: "mike", id: JSON.stringify(query) }],
  cursor: "x",
  hasMore: false,
});

there's a way to achieve this ? i'm new on Effect and I am very interested in learn and contribute on examples with TDD, DDD and monorepos with Effect

Thank you in advance!

Best regards,

Hello,
I want to set content-type header to text/plain in a response to a get request. I tried your example but without Schema.struct it does not compile. The code below compiles but the response has still application/json. Could you please tell me how to set content-type header correctly?

import {Effect} from "effect";
import {NodeServer} from "effect-http";
import {PrettyLogger} from "effect-log";
import {RouterBuilder} from "effect-http";
import {Api} from "effect-http";
import * as Schema from "@effect/schema/Schema";

export const api = Api.api({title: "Example API"}).pipe(
  Api.get("root", "/", {
    response: {
      status: 200,
      content: Schema.string,
      headers: Schema.struct({"Content-Type": Schema.string}),
    },
  }),
);

export const app = RouterBuilder.make(api).pipe(
  RouterBuilder.handle("root", () =>
    Effect.succeed({
      content: "Hello World!",
      status: 200 as const,
      headers: {"content-type": "text/plain"},
    }),
  ),
  RouterBuilder.build,
)

const program = app.pipe(
  NodeServer.listen({port: 3000}),
  Effect.provide(PrettyLogger.layer()),
);

Effect.runPromise(program);

{
"dependencies": {
    "@effect/schema": "^0.48.3",
    "effect": "2.0.0-next.55",
    "effect-http": "^0.39.0",
    "effect-log": "^0.23.1"
  },
  "devDependencies": {
    "prettier": "^3.1.0",
    "tsx": "^4.1.3",
    "typescript": "^5.2.2"
  }
}

I am currently working on an Express based codebase and I am trying to switch to effect-http in a non-breaking way.
I wrote a small adapter to wrap Express and be able to do that, I thought this could be of interest.
Not sure this deserves its own package but it could be useful as an example somewhere?

This is what it looks like:

const expressApp = express();

const app = pipe(
  Api.make({ title: 'Users API' }),
  Api.addEndpoint(...),
  RouterBuilder.make,
  RouterBuilder.handle(...),
  RouterBuilder.mapRouter(Middleware.from(expressApp).apply), // <-- where the magic happens
  RouterBuilder.buildPartial,
);

The implementation:

// request.ts
import { HttpServer } from '@effect/platform';
import { NodeHttpServer } from '@effect/platform-node';
import { Data, Effect } from 'effect';
import { IncomingMessage } from 'http';

export class Request extends Data.Class<IncomingMessage> {
  static ask() {
    return Effect.gen(function* (_) {
      return Request.from(yield* _(HttpServer.request.ServerRequest));
    });
  }

  static from(req: HttpServer.request.ServerRequest) {
    return new Request(NodeHttpServer.request.toIncomingMessage(req));
  }
}

// response.ts
import { HttpServer } from '@effect/platform';
import { Data, Effect } from 'effect';
import { EventEmitter } from 'events';
import { Response as ExpressResponse } from 'express';
import httpMocks from 'node-mocks-http';

export class Response extends Data.Class<
  httpMocks.MockResponse<ExpressResponse>
> {
  static make() {
    return new Response(
      httpMocks.createResponse({
        eventEmitter: EventEmitter,
      }),
    );
  }

  resolve = () =>
    Effect.async<void, Error>((resolve) => {
      this.on('end', () => {
        resolve(Effect.void);
        this.on('error', (e) => resolve(Effect.fail(e)));
      });
    });

  into = () =>
    HttpServer.response.text(this._getData(), {
      contentType: 'application/json',
      headers: HttpServer.headers.fromInput(
        this.getHeaders() as HttpServer.headers.Input,
      ),
      status: this._getStatusCode(),
      statusText: this._getStatusMessage(),
    });
}

// middleware.ts
import { HttpServer } from '@effect/platform';
import { Data, Effect, pipe } from 'effect';
import { Express } from 'express';

import { Request } from './request';
import { Response } from './response';

export class Middleware extends Data.Class<{ express: Express }> {
  static from(express: Express) {
    return new Middleware({ express });
  }

  apply = <E, R>(
    router: HttpServer.router.Router<E, R>,
  ): HttpServer.router.Router<E | Error, R> =>
    HttpServer.router.all(
      router,
      '*',
      Effect.gen(this, function* (_) {
        const request = yield* _(Request.ask());
        return yield* _(this.request(request));
      }),
    );

  request = (request: Request) =>
    Effect.gen(this, function* (_) {
      const response = Response.make();
      this.express(request, response);
      yield* _(response.resolve());
      return response.into();
    });
}

Would be great to be able to define default headers in Api.post. This would help with external api usage where you often have a Bearer token in env and don't want to pass it into the request each time you want something from the api.

Given that to create a client you need the API spec and the api spec includes handlers you'll end up including server code in the client

I am opening this issue to ask if it is possible to register endpoints conditionally. I have been unsuccessfully looking around for a way to do this and I am beginning to think it is not possible.

Referenced code can be found @ jrovira-kumori/http-effect-optional-endpoint.

Attempt 1

Trying to add a ternary condition when defining the API with process.env.SOME_FEATURE_FLAG ? ... : e => e produces a runtime error when running with npm run serve.

Error: Operation id optional not found
    at getRemainingEndpoint (http-effect-repro/node_modules/effect-http/dist/cjs/internal/router-builder.js:77:11)
    at http-effect-repro/node_modules/effect-http/dist/cjs/internal/router-builder.js:82:20
    at pipe (http-effect-repro/node_modules/effect/dist/cjs/Function.js:352:17)
    at Object.<anonymous> (http-effect-repro/build/index.js:34:34)
    at Module._compile (node:internal/modules/cjs/loader:1376:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1435:10)
    at Module.load (node:internal/modules/cjs/loader:1207:32)
    at Module._load (node:internal/modules/cjs/loader:1023:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:135:12)
    at node:internal/main/run_main_module:28:49

const api = pipe(
    Api.make(),
    Api.addEndpoint(pipe(Api.get("info", "/info"), Api.setResponseBody(S.string))),
    process.env.SOME_FEATURE_FLAG ? Api.addEndpoint(pipe(Api.get("optional", "/optional"), Api.setResponseBody(S.string))) : e => e,
);

  
const server = pipe(
    RouterBuilder.make(api),
    RouterBuilder.handle("info", () => Effect.succeed("info")),
    RouterBuilder.handle("optional", () => Effect.succeed("optional")),
    RouterBuilder.build,
)

pipe(
    server,
    NodeServer.listen({ port: 8080 }),
    NodeRuntime.runMain
)

Attempt 2

Also adding a ternary condition when defining the API with process.env.SOME_FEATURE_FLAG ? ... : e => e produces a compilation error building with npm run build.

index.ts:19:5 - error TS2345: Argument of type '<R, E>(builder: RouterBuilder<R, E, never>) => Default<R | SwaggerFiles, E>' is not assignable to parameter of type '(c: RouterBuilder<never, never, ApiEndpoint<"optional", Default, ApiResponse<200, string, Ignored, never>, Empty>>) => Default<...>'.
  Types of parameters 'builder' and 'c' are incompatible.
    Type 'RouterBuilder<never, never, ApiEndpoint<"optional", Default, ApiResponse<200, string, Ignored, never>, Empty>>' is not assignable to type 'RouterBuilder<never, never, never>'.
      Type 'ApiEndpoint<"optional", Default, ApiResponse<200, string, Ignored, never>, Empty>' is not assignable to type 'never'.

19     RouterBuilder.build,
       ~~~~~~~~~~~~~~~~~~~

index.ts:24:5 - error TS2345: Argument of type '<R, E>(router: Default<R, E>) => Effect<never, ServeError, Exclude<Exclude<Exclude<R, ServerRequest | Scope>, Server | Platform | Generator | NodeContext>, SwaggerFiles>>' is not assignable to parameter of type '(a: unknown) => Effect<never, ServeError, unknown>'.
  Types of parameters 'router' and 'a' are incompatible.
    Type 'unknown' is not assignable to type 'Default<unknown, unknown>'.

24     NodeServer.listen({ port: 8080 }),
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

const api = pipe(
    Api.make(),
    Api.addEndpoint(pipe(Api.get("info", "/info"), Api.setResponseBody(S.string))),
    process.env.SOME_FEATURE_FLAG ? Api.addEndpoint(pipe(Api.get("optional", "/optional"), Api.setResponseBody(S.string))) : e => e,
);

  
const server = pipe(
    RouterBuilder.make(api),
    RouterBuilder.handle("info", () => Effect.succeed("info")),
    process.env.SOME_FEATURE_FLAG ? RouterBuilder.handle("optional", () => Effect.succeed("optional")) : e => e,
    RouterBuilder.build,
)

pipe(
    server,
    NodeServer.listen({ port: 8080 }),
    NodeRuntime.runMain
)

I've got an afterHandlerExtension defined as follows

const CorsExtension = Http.afterHandlerExtension("corsHeader", (_req, resp) => {
  resp.headers.set("Access-Control-Allow-Origin", "*")
  return Effect.succeed(resp)
})
...

export const ApiServer = pipe(
  Api,
  Http.server,
  Http.addExtension(CorsExtension),
  ...add handlers
  Http.exhaustive
)

If I make a call to a defined endpoint directly, then I can see the Access-Control-Allow-Origin header on the response. However, when a request is made from our front end and the browser initially sends the OPTIONS request, the header is not present on the response and we get a CORS Missing Allow Origin error.

Am I configuring this incorrectly?

I'm working on an application where the user is authenticated with an "http-only" cookie.

To make correct API calls, I'd like to configure the fetch options of my client with { credentials: 'include' }.

It seems that it's not possible at the moment, fetch options are empty :

Could the url of an entire ApiGroup be prefixed somehow?

Currently I have quite a few routes that look like:

GET /events
GET /events/:id
PATCH /events/:id
// etc.

It would be convenient to be able to set the /events prefix in one place only.

Hello! I was wondering if you would be interested in supporting an option to return all schema errors. By default schema returns the first one. All errors must be opted into with parse(Type)(x, {errors: "all").

Places I could find parse is called:

Hi,

I'm trying to understand how the logging works and what's currently available.

I was trying to search in examples but didn't find a solution to get these in the log:

• entries for 404s (atm incorrect requests are not showing up in the log, which might be a feature or a bug 😅 )
• remote IP address
• HTTP status code of the response

Are these supported or something that needs changes?

Thanks 🙇

I am trying to create a handler that, per API definition, can respond with different status codes and body types. Standard use-case I think. I'm not sure if I overlooked something in the examples or tests but this simple implementation throws a TS error: Type '400' is not assignable to type '201'.

import { Effect, pipe } from "effect";
import { Schema } from "@effect/schema";
import { Api, RouterBuilder } from "effect-http";
import { NodeRuntime } from "@effect/platform-node";
import { NodeServer } from "effect-http-node";

const api = pipe(
  Api.make(),
  Api.addEndpoint(
    pipe(
      Api.get("test", "/test"),
      Api.setResponse({ status: 200, body: Schema.String }),
      Api.addResponse({ status: 201, body: Schema.Number }),
      Api.addResponse({ status: 400, body: Schema.String }),
      Api.addResponse({ status: 422, body: Schema.String })
    )
  )
);

const app = pipe(
  RouterBuilder.make(api),
  RouterBuilder.handle("test", () => {
    if (Math.random() > 0.5) {
      return Effect.succeed({ status: 200 as const, body: "Hello" });
    } else {
      return Effect.succeed({ status: 400 as const, body: "Bad request" });
    }
  }),
  RouterBuilder.build
);

app.pipe(NodeServer.listen({ port: 3000 }), NodeRuntime.runMain);

What is the proper way to handle APIs with several possible response types?

I'm using effect-http to model an external Api that I'm calling using Client.make (which is a really cool feature!) and it works great. But now I want to generate a mock client to write some tests with, so I've got

const AnimalAdapterClientTest = Layer.succeed(AnimalAdapterClient, MockClient.make(animalAdapterApi))

And I get an error at startup:

/Users/bste/ghq/gitlab.com/ezyvet/application/hypr/launchpad/node_modules/.pnpm/@[email protected][email protected][email protected]/node_modules/@effect/schema/src/Parser.ts:273
  switch (ast._tag) {
              ^
TypeError: Cannot read properties of undefined (reading '_tag')

I've had a dig through the code and it looks like in effect-http/internal/utils when we check if the request params schemas is IgnoredSchemaId the test returns false so we try to call Schema.encode.

Printing the requestSchemas to the console from the utils file, I can see params is set to Symbol(effect-http/ignore-schema-id)

{
  query: SchemaImpl {
    ast: {
      _tag: 'TypeLiteral',
      propertySignatures: [Array],
      indexSignatures: [],
      annotations: {}
    },
    [Symbol(@effect/schema/Schema)]: { From: [Function: From], To: [Function: To] }
  },
  params: Symbol(effect-http/ignore-schema-id),
  body: Symbol(effect-http/ignore-schema-id),
  headers: SchemaImpl {
    ast: {
      _tag: 'TypeLiteral',
      propertySignatures: [Array],
      indexSignatures: [],
      annotations: {}
    },
    [Symbol(@effect/schema/Schema)]: { From: [Function: From], To: [Function: To] }
  }
}

Logging out the whole imported Api object shows that IgnoredSchemaId looks fine:

[Object: null prototype] {
  default: {
    ApiGroupTypeId: Symbol(effect-http/Api/ApiGroupTypeId),
    ApiTypeId: Symbol(effect-http/Api/ApiTypeId),
    FormData: SchemaImpl {
      ast: [Object],
      [Symbol(@effect/schema/Schema)]: [Object]
    },
    IgnoredSchemaId: Symbol(effect-http/ignore-schema-id),
    ...
  }
}

but if I print out the field with console.log(Api__namespace.IgnoredSchemaId) then I get undefined.
I'm not too sure what to check next.

Versions of packages are:
effect: 2.0.0-next.60
effect-http: ^0.45.1
@effect/platform-node: ^0.37.6
@effect/schema: ^0.53.1

The Security lib might work better as a separate (transport layer independent) library that works not only with with effect-http but also with pure @effect/platform http, rpc, and other transport layers. That's how I would like to use it anyway. :)

Api.api should probably accept the entire Info object vs just title and version.

As is, the library does not handle the case of a port already being in use, instead it just errors (presumably after a timeout) when it realises it's not listening:

timestamp=2024-05-05T16:54:44.745Z level=ERROR fiber=#0 cause="Error [ERR_SERVER_NOT_RUNNING]: Server is not running.

This provides almost no context for the actual error, and it's very hard to debug. I assume this is default platform behaviour, but I think this library is suited to handle this error too.

"Some descriptions are provided from the built-in @effect/schema/Schema combinators. For example, the usage of Schema.int() will result in "a positive number" description in the OpenApi schema. One can also add custom description using the Schema.description combinator."

I hope this isn't the case. Lol

Hello,

I've recently upgraded to a newer version of this package (0.46.2) and am now running into issues with the server failing to process requests with FormData content-types.

The requests fail prior to reaching our registered handler for the given endpoint with the following error. It seems like there may be a bug with how form-data requests are decoded/parsed prior to being passed on to the endpoint's registered handler:

{
  "_tag": "RequestError",
  "request": {
    "_tag": "ServerRequest",
    "method": "POST",
    "url": "/coi_request",
    "originalUrl": "/coi_request",
    "headers": {
      "authorization": "--redacted--",
      "user-agent": "PostmanRuntime/7.36.0",
      "accept": "*/*",
      "cache-control": "no-cache",
      "postman-token": "0b7ca553-40ef-48aa-94b1-866d638875ec",
      "host": "localhost:8080",
      "accept-encoding": "gzip, deflate, br",
      "connection": "keep-alive",
      "content-type": "multipart/form-data; boundary=--------------------------707399609773474252081923",
      "content-length": "318"
    }
  },
  "reason": "Decode",
  "error": {}
}

Are there any known limitations to using FormData content-types/are you aware of any breaking changes to FormData content-type handling since the big re-write post v0.32.0?

Likewise, is there any way I can register a handler that bypasses the default request payload decoding behavior and handle type validations manually within the endpoint's handler?

Thanks for any help you can provide.

While I really like the way that servers are defined in this library, the use of express is somewhat annoying. Especially for people interested in using this with edge/lambda functions. Hattip is probably a better target for this sense it abstracts away the request handler and is compatible with other frameworks besides express(e.g. aws lambda, etc.). Also, express is also a bit dated at this point and Hattip uses more modern js apis.

Hey,
I've noticed that when using a Schema.Date in a struct the example in Swagger doesn't produce usable date-strings: instead they produce "string".

Is it possible to get it to work like with S.UUID ?

Reproduction

const testSchema = S.struct({
  id: S.UUID,
  date: S.Date
})

This is what Swagger shows with the given Schema set as requestBody:

Which of course leads to an error when trying to execute in Swagger:

Question

Is it possible to get the current date as an iso string for the swagger documentation by setting some annotations in Schema for example? Or is this not possible at the moment?

Packages:
"@effect/platform": "^0.48.27",
"@effect/platform-node": "^0.45.29",
"effect": "^2.4.18",
"effect-http": "^0.60.7",
"effect-http-node": "^0.8.8",

Say I’ve got an API with endpoints /a and /b
How could I create a server which would serve them at /prefix/a and /prefix/b?

thanks!

Hello again 👋

I think I've encountered a small bug somewhere within the OpenAPI integration being unable to create "Components" with schemas containing identifiers when some of its property signatures are optional, but only a subset of them.

I think it has to do with the optionalToRequired transformation that takes place internally to Schema, but I'm not too positive after looking only a bit briefly.

import * as S from '@effect/schema/Schema';
import { Api, OpenApi } from 'effect-http';

const schema = S.struct({
  // Does NOT work
  // a: S.optional(S.Date, { nullable: true, exact: true, as: 'Option' }),
  // b: S.optional(S.Date, { nullable: true, default: () => new Date(), }),
  // c: S.optional(S.Date, { exact: true, default: () => new Date() }),
  // d: S.optional(S.Date, { exact: true, as: 'Option' }),
  // e: S.optional(S.Date, { nullable: true, as: 'Option' }),
  // f: S.optional(S.Date, { as: 'Option' }),
  // Does Work
  // y: S.optional(S.Date, { exact: true }),
  // z: S.optional(S.Date),
}).pipe(S.identifier('Foo'));

const api = Api.api({ title: 'Example' }).pipe(
  Api.get('getFoo', '/:foo', {
    request: {
      params: S.struct({
        foo: S.string,
      }),
    },
    response: schema,
  })
);

console.log(OpenApi.make(api));

When using a service inside a custom Security, it becomes a requirement of the client endpoint although it should be only used on the server side.

Look below how the effect has the type: Effect.Effect<string, ClientError<number>, UserStorage>

import { Schema } from '@effect/schema';
import { Effect, Layer, pipe } from 'effect';
import {
  Api,
  ApiEndpoint,
  Client,
  Middlewares,
  RouterBuilder,
  Security,
} from 'effect-http';

interface UserInfo {
  email: string;
}

class UserStorage extends Effect.Tag('UserStorage')<
  UserStorage,
  { getInfo: (user: string) => Effect.Effect<UserInfo> }
>() {
  static dummy = Layer.succeed(
    UserStorage,
    UserStorage.of({
      getInfo: (_: string) => Effect.succeed({ email: '[email protected]' }),
    }),
  );
}

const mySecurity = pipe(
  Security.basic({ description: 'My basic auth' }),
  Security.map((creds) => creds.user),
  Security.mapEffect((user) => UserStorage.getInfo(user)),
);

const api = Api.make().pipe(
  Api.addEndpoint(
    Api.post('endpoint', '/my-secured-endpoint').pipe(
      Api.setResponseBody(Schema.String),
      Api.setSecurity(mySecurity),
    ),
  ),
);

const app = RouterBuilder.make(api).pipe(
  RouterBuilder.handle('endpoint', (_, security) =>
    Effect.succeed(`Logged in`),
  ),
  RouterBuilder.build,
  Middlewares.errorLog,
);

const client = Client.make(api);

// BAD: Effect.Effect<string, ClientError<number>, UserStorage>
const effect = client.endpoint({});

I have written a quick type helper as a workaround:

type ApiClient<T> =
  T extends Api.Api<infer Endpoints> ? Api.Api<MapEndpoints<Endpoints>> : never;

type MapEndpoints<T> =
  T extends ApiEndpoint.ApiEndpoint<
    infer Endpoint,
    infer Req,
    infer Resp,
    Security.Security<infer A, infer E, unknown>
  >
    ? ApiEndpoint.ApiEndpoint<
        Endpoint,
        Req,
        Resp,
        Security.Security<A, E, never>
      >
    : never;

const client = Client.make(api as ApiClient<typeof api>);

// GOOD: Effect.Effect<string, ClientError<number>, never>
const effect = client.endpoint({});

I will try to do a PR when I find the time.

Hi, really enjoying exploring the lib!
I was wondering if there is any way to add in common response headers to the server?
E.g adding in CORS headers at the moment looks like it needs a header schema needs to be added to each response and then instantiated in each handler.
I though this could be achieved by creating an afterHandler extension but I'm not too sure how to modify the response object.

It might be useful to allow already handled routes to be overridden. Especially when you are already using ExampleServer for testing and want to progressively add real implementations.

I came across this when I was trying to use the Example server and also return Metric.snapshot. E.g.

pipe(
  ExampleServer.make(Api.api),
  RouterBuilder.handle("metrics", () => Metric.snapshot) // error
)

Hi @sukovanej 👋 First of all, this library looks super promising! I'm very happy to have started fiddling with it 🙂

I'm trying to migrate my own fp-ts-based HTTP clients to use effect-http. However, I've hit a wall since I'm unable to express optional query parameters. I was hoping the following (or something similar) would work:

import * as schema from "@effect/schema/Schema";
import { pipe } from "effect";
import * as http from "effect-http";

export const api = pipe(
  http.api(),
  http.get("userById", "/api/users/:userId", {
    response: schema.struct({ name: schema.string }),
    params: { userId: schema.string },
    // @ts-expect-error Type 'Schema<string | undefined, string | undefined>' is not assignable to type 'Schema<string, any>'.
    query: {
      include_deleted: schema.union(schema.string, schema.undefined),
    },
    headers: {
      authorization: schema.string,
    },
  })
);

Looking more at the REAMDE, I haven't seen any mention of optional query parameters or request headers. Is there a specific reason for the lack of optional inputs, or would this be an acceptable feature request?

What is the best way to use this with an external api eg stripe or twilio?

We're seeing some issues with the testing client and a multipart form data payload. I found this which makes it look like all requests with a body are transformed to json with application/json headers.

Is the testing client still a work in progress or is it ok to assume it has parity with the server?

Hello again.

I was wondering if you'd consider responses that allow type validation alongside status codes and headers.

Using Response allows a custom response status code and headers but allows a body that may violate the API contract:

For tracking / TODO list purpose.

Enable incremental adoption into existing express apps

• Express app derivation.
• (?) Add api for raw express handlers.
• Add ability to extend OpenApi schema manually.

Minimal feature set

• Provide a way to plug in an express middleware.
  • TODO: instead of support of middleware, document the express app creation and document it properly
• (?) Handling of application shutdown.
• Response headers.
• Mock client derivation.

I have an already existing Astro server, but I'm looking for a way to have type safety cross boundaries (RPC style).
This library seems like a good fit to build such foundation, but as I mentioned, I need to embed it inside my existing ASTRO backend.
Hono has a similar feature that allows to embed it within other servers. As far as I know, all I need is a function capable of dealing with a request (perform some routing too) and returns a response. Is this possible? Do you have any examples ?

Hi, first thanks for this great project! I'm hoping to replace https://github.com/BitGo/api-ts with it

however, running a simple http server example from Readme.md I get:

Error: isomorphic-ws tried to access ws (a peer dependency) but it isn't provided by its ancestors; this makes the require call ambiguous and unsound.

Required package: ws
Required by: isomorphic-ws

Installing ws in my project doesn't help. I believe ws should be added to peerDeps of effect-http in order to fix this

btw. it would be great if this was not required for simple http server as I guess it doesn't actually use the websocket lib

Hi, thanks for this amazing library. It's effective to use with effect-ts ;)

To perform a signature validation, I need to access the raw string payload of the request, before it gets parsed as JSON. This only needs to be done on a particular route, so I can't do the check across the application. Just wondering if there is a way to access the raw request from the handler?

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update all patch dependencies (@changesets/cli, pnpm)
• chore(deps): update actions/deploy-pages action to v4
• chore(deps): update actions/upload-pages-artifact action to v3
• chore(deps): update dependency eslint to v9
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hello! We recently upgraded to the latest version. We were wondering if there's still.a way to optionally disable the swagger ui functionality? I haven't been able to find it.

Hi! I just ran across this library and it looks great! I was playing around with the examples though and was having some type issues though. Specifically with the Http.get function. I get "Expected 0 arguments, but got 3". Currently I'm using version 0.1.0 but I've tested it with earlier versions.

https://codesandbox.io/p/sandbox/winter-field-30ikt5?file=%2Fsrc%2Findex.ts&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A9%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A9%7D%5D