Add unsafeRunServer method

[kyri-petrou]

No description provided.

[paulpdaniels]

How would the user do a provide for this?

[kyri-petrou]

@paulpdaniels Just to make sure I understood your question correctly, do you mean if they have a GraphQL[R] where R is not Any?

[paulpdaniels]

Yeah, I think we only have provide for the interpreter or for the resulting ZIO but on this case you can't specify a graphql wide environment

[kyri-petrou]

Perhaps I'm wrong, but the way I see it is that if you're already propagating services via the ZIO environment, you're already familiar enough with the ZIO ecosystem to go for the normal object Main extends ZIOAppDefault way.

I don't think we should see this method as a substitute for it, but rather as a way for users that either never used ZIO before or just wanna prototype something without without too much fluff get started quickly. Having said that, in case we do think it's good to give this option to users, we can do something along these lines:

    def unsafeRunServer(
      port: Int = 8080,
      apiPath: String = "/graphql",
      graphiqlPath: Option[String] = Some("/graphiql"),
      uploadPath: Option[String] = None
    )(implicit trace: Trace, ev: R =:= Any): Unit =
      ZIOAppDefault(
        gql
          .runServer(port, apiPath, graphiqlPath, uploadPath)
          .provideEnvironment(ev.liftContra(ZEnvironment.empty))
      )
        .main(Array.empty)

    def unsafeRunServerR(
      env: ZEnvironment[R],
      port: Int = 8080,
      apiPath: String = "/graphql",
      graphiqlPath: Option[String] = Some("/graphiql"),
      uploadPath: Option[String] = None
    )(implicit trace: Trace, ev: R <:< Any): Unit =
      ZIOAppDefault(
        gql
          .runServer(port, apiPath, graphiqlPath, uploadPath)
          .provideEnvironment(env)
      )
        .main(Array.empty)

[ghostdogpr]

I agree if they use zio environment, they shouldn't need this. For demo purposes I think using zio environment is complex enough to show a full zio solution.

[paulpdaniels]

I think if you just went one level up to use ZIOApp instead it has an apply method that accepts a bootstrap method too

[paulpdaniels]

I guess we could take the wait and see approach, Im just wondering about the progression that each step gets taught. If we include a way to provide the layer you can teach Layers as a progression instead of first having to teach, well now we need to use this main class syntax before we can do the thing we really want which is adding service dependencies

[kyri-petrou]

I tried a couple of things, and ended up with introducing a .unsafe syntax method. That allows to do the following: gql.unsafe.provideLayer(???).runServer(...).

In case we don't need to eliminate the environment, we can run it unsafely as gql.unsafe.runServer(...)

@ghostdogpr @paulpdaniels are you OK with these changes?

[kyri-petrou]

PS: I'm actually thinking we should change the interpreter method to return an Either instead. I think it can be quite annoying to users to have to deal with the ZIO effect unnecessarily

[ghostdogpr]

Isn't an Either more annoying? With ZIO you can just call it in your current for-comprehension, with Either I feel it will make people have to call ZIO.fromEither.

[kyri-petrou]

I think it'll simplify things a lot for non-zio apps. I think this is the only method required for wiring the api that returns a ZIO effect