[xthrowawayxx]

>Decoupling your dependency seems reasonable, but you can do it much simpler.

> type GetProject = (...) => ... > type ProjectCRUD = { get: GetProject, set: ... }

> constructor(private projectCrud: ProjectCrud)

Yep that is a more concise way of doing the same thing. I've considered that approach and it seems perfectly reasonable, even cleaner. The only reason I haven't is because constructors offer a more standardised approach to object creation for service type objects that other developers are familiar with, rather than higher order functions or function constructors. Although my method is kind of bespoke anyway so I could go either way. Another advantage of your approach is composing finer grained functions or objects with methods into more expansive services becomes delightfully easy.

>[1]: https://news.ycombinator.com/item?id=31547975 - I'd love to hear opinions on that.

I've tried to use TypeScriot DI containers... Oh I've tried.. But eventually they all just feel gross.

These days I'm perfectly happy having a bootstrap / createServices method for the application, or with multiple entry points each requiring a subset of services with different configurations, different create<command>Services functions. Works well for CLI apps. Downside is when there are too many entry points with different depenencies, like an HTTP API, you don't want to create a bootstrap method for each entrypoint. In this case I create all services once on bootup. I pass the request context as method argument. Don't have a perfect way yet of doing request-level services like GraphQL caching. Currently I lazy load request level services on request context.

[SebastianKra]

Ah, I thought you were talking about _automatic_ DI. Apologies.

> Yep that is a more concise way of doing the same thing

Your interfaces still dictate a method name and signature that must be known by both parties. I would argue that this connection is the concern of the integrating layer. If either party changes, here's where the error should occur:

  const service = new ProjectService()
  const controller = new ProjectController({ 
    getProject: service.get.bind(service) // this is why I don't like js classes
    setProject: service.set.bind(service)
  })

Naturally, this needs some caution. If the boundaries aren't chosen well, the integration layer grows.

I think you're right that our fundamental difference is the desire to stick to a more standardized class-based architecture. I like js-classes to communicate that something is stateful. But conceptually, they're more hindering than helpful.

[eurasiantiger]

Don’t cache GraphQL at request level. Cache it at schema object level, like most (all?) off-the-shelf servers do.

[xthrowawayxx]

I cache at the schema level for each request.

How do GraphQL servers automatically cache objects? I was not aware servers do this. I generally avoid them because of their inflexibility (eg. Unable to support the two websocket subscription sub protocols simultaneously).

[eurasiantiger]

Typically by using the id field of objects as cache key. Even some clients do this, which is nice, except if your objects aren’t unique by their ids. It can usually be configured, however.

[xthrowawayxx]

How though do they know the ID before the object is created (/ fetched from db)?

Sounds like it's inferior to manually using a DataLoader within every resolver that fetches an object.

eg project has a client. In the resolver for a projects client, you fetch the client from DB. With DataLoader you manually cache the request for the client. With in-built caching you must resolve the client for the server to know the ID, and then on next resolve of the client, after fetching, it matches the ID and doesn't have to resolve it's fields again, but it still had to fetch both times?

[eurasiantiger]

Well, how could they cache something they haven’t fetched?