Reduce production build size

[mattkrick]

Get the entry chunk down to 300kB. Low hanging fruit includes taking Joi out of initial bundle.

[mattkrick]

SSR is served at ~15kB Main entry < 300kB Vendors < 600kB

[0]                     Asset     Size  Chunks             Chunk Names
[0] 0.2ef0eef8362620831bf1.js   106 kB       0  [emitted]  
[0] 1.2ef0eef8362620831bf1.js  3.98 kB       1  [emitted]  
[0] 2.2ef0eef8362620831bf1.js  2.71 kB       2  [emitted]  
[0]                 vendor.js   546 kB       3  [emitted]  vendor
[0] 4.2ef0eef8362620831bf1.js   138 kB       4  [emitted]  
[0] 5.2ef0eef8362620831bf1.js  3.97 kB       5  [emitted]  
[0]                    app.js   269 kB       6  [emitted]  app
[0]                _style.css  2.35 kB       6  [emitted]  app

[pe3]

Haven't tried this myself but are you aware of Yup.

Yup is a JavaScript object schema validator and object parser. The API and style is stolen heavily inspired by Joi, which is an amazing library but is generally too large and difficult to package for use in a browser. Yup is a leaner in the same spirit without some of the fancy features.

[bartekus]

You can use it on the server as well, but in that case you might as well just use Joi.

Joi is used as part of auth process which is universal in nature, both client and server. So while technically it is possible to use Yup, considering the current implementation and the Yup authors statement above, I believe it would be a step back. However you are free to give it a shot and report your findings back; should the solution prove to be just as effective but lighter in terms of size then considerations would be made to switch the current implementation from Joi to Yup.

[abastardi]

You can use it on the server as well, but in that case you might as well just use Joi.

I'm not familiar with Yup, but another possible interpretation of the above is that there is no reason to choose Yup over Joi if you need it on the server only (as the main benefit of Yup is lost there), but that Yup would be appropriate for any scenario where you need validation on the client (including univeral apps requiring both client and server validation).

[mattkrick]

I like where this is going, thanks for bringing this up! Now that I'm using graphql on the server, I use custom scalars to do validation there, eliminating the need for JOI on the server. Once I get a client cache built, my intent is to use those same custom scalars on the client. It'll take a little tweaking to eliminate the dependencies that the custom scalars need, but the end result will be using graphql as a query language and validator universally. Stay tuned

On Mon, Feb 1, 2016, 3:02 PM abastardi notifications@github.com wrote:

You can use it on the server as well, but in that case you might as well just use Joi.

I'm not familiar with Yup, but another possible interpretation of the above is that there is no reason to choose Yup over Joi if you need it on the server only (as the main benefit of Yup is lost there), but that Yup would be appropriate for any scenario where you need validation on the client (including univeral apps requiring both client and server validation).

— Reply to this email directly or view it on GitHub https://github.com/mattkrick/meatier/issues/13#issuecomment-178188392.

[jquense]

quick note (as the author of yup), yup works great on the server (we share schema that way) but as @abastardi mentions if you _only_need server validation/parsing might as well use the more heavily featured joi. if you need both client and server or just client yup is a good choice.

one of big advantages for us to using yup for validation is that it also works great for parsing API responses, but I imagine that's less of a need with graphQL.

awesome project btw! looking forward to seeing more :) as it shapes up

[mattkrick]

@jquense awesome work on yup! It's great to see a validator that offers what we've been needing so desperately from joi :+1: I'm not sure what it would look like, but it'd be nice to see a validator that piggybacks on graphQL schemas. Custom GraphQL Scalars have a ton of boilerplate, but you can use them for coercion (eg make emails all lowercase before saving), validation, and cleaning (trimming, etc). Maybe a yup babel plugin that creates a yup schema from a graphql introspection? I did something similar to make a normalizr schema (see https://github.com/mattkrick/cashay/blob/master/src/babel-plugin/transform.js) Don't wanna put work on your plate, but if you're open to it, it'd be fun to collab on something.

[jquense]

@mattkrick I don't have a ton of time, but that does sounds like a fun project :) i'd also give me a chance to finally dig into graphQL. I don't quite see how it's helpful to go from gql schema to yup schema though? If you are trying to avoid boilerplate wouldn't you want to go the other way?

In any case if it is something you think would be valuable feel free to open something up on the yup repo.