Support for next middleware function

[solidjs]

Support for next middleware function

[btakita]

I was able solve my use case by making ApolloServer lazy load:

import { ApolloServer } from 'apollo-server-express'
import { ApolloServerPluginDrainHttpServer } from 'apollo-server-core'
function graphql_plugin_(path) {
  /** @type {import('vite').ServerHook} */
  const configureServer = async server=>{
    /** @type {Promise<import('express').Router>} */
    let router_promise
    server
      .middlewares
      .use(async (req, res, next)=>{
        if (!router_promise) {
          router_promise = new Promise(async resolve=>{
            const { typeDefs, resolvers } = await server.ssrLoadModule('@app/service-domain')
            const apollo = new ApolloServer({
              typeDefs,
              resolvers,
              plugins: [ApolloServerPluginDrainHttpServer({
                httpServer: server.httpServer
              })],
            })
            await apollo.start()
            resolve(
              apollo.getMiddleware({
                path
              })
            )
          })
        }
        const router = await router_promise
        router(req, res, next)
      })
  }
  return { configureServer }
}

[nksaraf]

The issue with something like this is that now you have to figure out how to integrate this into the adapters since they don't use vite middleware to build their server.. so doing stuff with the vite server creates a split where u need to setup the build step and dev step separately. Maybe we can brainstorm how to do this from within entry-server itself without involving vite.

[btakita]

In the case of Apollo, there's a different adapter for each platform. I don't know if having to support the dev & prod adapters separately can be avoided in all cases. Making it easier to manage each adapter by creating the right abstractions seems doable & will form a base layer if a universal api is created.

Perhaps it would make sense to start with the most complicated api, probably being node/express, as a base for a universal abstraction. I'm not very familiar with the other platform apis other than Lambda, but if there is any use case unique to the other platform, then it can be added to the universal abstraction.

I like the idea of handling as many use cases with solid-start (entry-server, api routes, etc), since the logic will be usable across all adapters. But I do think it should also allow full usage of the adapter's platform, as solid-start apps will be used in many different circumstances.

[nksaraf]

We do want to enable you to use platform specific primitives where you want, and you would be consciously opting out of universal deployment for that app. I see Cloudflare workers KV or Durable Object beings examples of this. But I don't think the vite config is the correct place for this since that's working in dev only. In prod your entry-server is the main place to initialize these things. including lazy loading via dynamic imports..

Could you try what this might look like via a dynamic import in entry-server. We do support middleware in there so this might work.

Closing this for now, but you can open it again if things don't work as you want!