You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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. 🙌
The text was updated successfully, but these errors were encountered:
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.
+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.
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):
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 canonicaldream
package depends on it, and N additional optional bits.As always, greatly appreciate the utility and fundamental vision of dream. 🙌
The text was updated successfully, but these errors were encountered: