Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: push non-essential functionality into optional packages #168

Open
cemerick opened this issue Oct 15, 2021 · 3 comments
Open

Comments

@cemerick
Copy link

As I get closer to deploying a dream app into production, and things like deployment package size are top of mind, it occurs to me that dream includes some bits that could reasonably be shuffled into optional packages to enable slimmer default deployments (quite analogous to one needing to pull in the caqti driver corresponding to the database(s) actually in use):

  • ssl/https support; it's been a long time since I've terminated SSL/TLS at the application server level (and tbh I'm not sure how wise it is to make doing so easy; IMO I'd rather have such stuff handled by larger groups responsible for nginx or whatever cloud load balancer one is using)
  • graphql support; definitely a nice-to-have for those that are using it, but wouldn't it be entirely equivalent as a separate library? (i.e. the dream/graphql integration is standalone, and wouldn't even need a modular shim, maybe in contrast to the ssl support)

Obviously this suggestion is somewhat in tension with the stated tagline of "a feature-complete web framework" (i.e. I assume by their inclusion so far, you believe that making some of these features optional would diminish the "feature complete" part of that). But there might be a "why not both?" approach, i.e. have a dream-slim package that omits such things, and the canonical dream package depends on it, and N additional optional bits.

As always, greatly appreciate the utility and fundamental vision of dream. 🙌

@aantron
Copy link
Owner

aantron commented Oct 16, 2021

I'll take a look at this.

Have you looked at how much space would be saved by removing TLS support or GraphQL? Just asking — I can take a look later.

Ideally, I think, we would have some kind of link-time dead code elimination just get rid of these if they are not used. I think that should be readily applicable to GraphQL. The way TLS is "integrated" into Dream might be hard for DCE to discover it is not used.

@ReallySnazzy
Copy link

+1 I think this would also be useful for Windows users. During building a project using Dream with DkML, it seems like it's able to compile all 3rd party dependencies except for the ssl package. If ssl was optional, then it might be easier to do development on Windows.

@aantron
Copy link
Owner

aantron commented Sep 9, 2024

For the SSL failure specifically, was it an instance of savonet/ocaml-ssl#155? Also reported in ocaml/setup-ocaml#856.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants