jaredgorski

Whether or not you care about your code being used, other people do care about theirs. They have a right to represent these concerns and see how they fare in the legal system.

At any rate, let me try to cut through your visceral anger and invite a discussion. :-)

"Is ML training sufficiently transformative that the model should be considered fair use?" - a burning question in many of our minds (maybe)

Firstly, this isn't yet clear from a legal perspective. Whether or not you agree with the class action, we need to clarify how IP law views ML training as it regards source -> model.

Anyway, here's a thought experiment: given an extremely overfitted model (to keep it simple, we can achieve a basic overfit by training only on a single piece of source data), predictions will generally replicate the training data. Indeed, one could accuse an overfitted model of being an over-engineered copying algorithm.

Therefore, the question of whether outputs are "sufficiently transformative" must at least consider the fit achieved by an individual ML implementation.

But what about a well-fitted model that generalizes to novel data? Back to the thought experiment. Let's expand and diversify the training source. In other words, we're cutting the training data with other training data to end up with a less "pure" (more general) result. Training time and the complexity of intermediate layer data (e.g. weights) skyrockets but, if you can reduce loss enough (which happens to be the goal of ML algorithms), we'll still end up with a model which reflects the aggregate training source. There's no magic: ML algorithms simply create an incredibly large/complex statistical model based on mathematically visible patterns in the source material. If the goal is to descend the loss gradient, the identity of a model is (100 - loss)% relative to the aggregate training source.

So, as for the "sufficient transformation" question, I think this question is clarified by considering ML training to be a form of "dilution" (in pursuit of model generality): if I dilute source material with other source material from different authors and compose a resulting work, am I cleared of all copyright responsibilities to the individual source works? How much dilution is necessary to put me in fair use territory? Personally, I think these sorts of cases can only be litigated on an individual basis. Also, a fairly obvious solution to clear this question is to generate your own training data, whether or not you believe this should be required.

But all that stuff isn't really what this class action case is specifically about. The root question of the case is this: do FOSS license holders reserve the right to prevent (or at least opt-out) other entities from building commercial products out of their licensed code without honoring those licenses and/or providing any compensation/attribution?

I believe we do reserve this right, and it doesn't require quashing Copilot or kneecapping the (IMO limited) potential of AI/ML. It simply requires clarifying laws and licenses accordingly and then determining whether damages have already occurred. The class action lawsuit is an assertive step to check this via the legal system, particularly considering that Microsoft is a giant corporation making gobs of cash off of this model. It's a way to answer questions and solve problems in the real world.

I was being tongue-in-cheek. Didn't mean to sound like a smartass. Thanks for reading!

Oddly enough, I just realized I do both

For clarity, this post was more creative writing exercise than technical treatise. Thanks for reading!

For clarity, this post was more creative writing exercise than technical treatise.

Maybe you should write a web blog post nobody will read about it

Your exasperation is absolutely shared. Thanks for engaging

I did mention that our clients are enterprise-level.

But I did fail to address a more general decision-making process regarding choosing frontend architecture. If I did (and I probably will soon), I would talk a lot about the egregious initial load times on too many blogs that roll crazy dynamic tools for what should be a completely static site.

Right?! Yeah, the title should be “A few patterns we implemented lately”. I do have more thoughts specific to practical frontend architecture though, so I guess I’ll just hope you see the next post.

Using Tailwind alongside anything is pretty simple. It just generates stylesheets for you based on what you use. All you need to do is set up the build (so that it knows which style rules to include and which to purge) and then start using Tailwind classes in your markup.

As for “best practices”, I’d say there’s not many problems you’ll run into using something like Tailwind. Any configuration improvements you make probably won’t break anything, but you should still read the docs before you get started.

Ha! Yes. It’s pseudo code though. Please don’t copy and paste it.

Thanks for the positive vibes.

Great question. In fact, that question has more to do with “architecture” than most of my post.

The primary reason we went with Apollo is that it’s flexibility-minded and well-documented, making it easier for new engineers to work with. If everything was ideal, we’d use Relay. Relay’s patterns are better (IMO) but it can be confusing for new folks to use it idiomatically. So, it’s primarily a dev-experience consideration for us.

Specifically, are you referring to JWT with Apollo client on the server-side?

On the client-side, you can just use a link and get the cookie into an auth header that way. On the server-side, you need some way of getting that auth token from the cookie and passing it into the server-side runtime so that you can insert it into the auth header via a link in each server-side Apollo client instance.

I see what you mean.

By way of clarification, I see route validation and pageload validation as potentially separate. For example, a given route parameter may govern a whole scope of pages in the app, so it makes sense to centralize that route validation logic rather than duplicate it in each page’s validation hook. In a more traditional server (like Express), we can just handle requests which contain that route parameter with a particular middleware function that validates the route. However, if we’re just using Next.js’ filesystem router, we have to add validation in the component tree, in a wrapping component. You’re right that we could make a HOC, but then we would either need to apply it to each page file in that directory or just put it in the App render as a wrapping component, which is what we elected to do.

On the other hand, an individual page may need to run some specific logic to validate that particular load. That’s where the page validation hook comes in. We have a centralized permissions spec in the runtime which contains fallback rules for each page, so we can just update the “abort” callback with each route change so that the page can just bail out of the pageload and redirect the client appropriately.

Totally. With Next, your page component can export a getServerSideProps function which is used by the Next server to fetch any props necessary for the page component server-side on-demand. There’s a variation of this function for static builds called getStaticProps, which runs at build time to fetch data for props. So, even if we don’t render anything server-side, we can still run logic/fetches/etc. on the server side when a particular page is requested. This could be useful for dealing with sensitive data, for example.

Sounds like a cool app. I definitely see plenty of opportunities for static content there, like you said, but proper state management is vital for the real-time stuff.

I’d love to hear more about your experience with that “with-apollo” pattern. I decried it without using it first, but I see the problem as a coupling/cohesion imbalance.

What has it looked like in practice for you?

I’m with you :)

It’s certainly nothing new, but the “buzz factor” impresses people who don’t know what it’s for and they implement it everywhere thinking it’s an improvement. The trend/gimmick culture in frontend is a real thing.

“Hey look, the browser loads each new page one at a time instead of loading them all in the initial load.”

Good! We need to get back to the basics and stop shoehorning React into every application.

I regret that my post is yet another React promotion. Not intended: architecture depends on use-case. I’m hoping to write more soon about selecting tools appropriately, which probably doesn’t mean React in many cases.

Great feedback.

I’ve been wanting to write more about most everything you mentioned, but ended up writing about a few interesting patterns we implemented recently. I probably should’ve titled the post “A few interesting patterns we implemented recently”.

As for state management solving the problems of pageload validation (instead of our error boundary and redirect mechanisms), can you provide an example?

> So, why are you using an SSR framework then?

Great question; I should’ve mentioned this more concretely in the post.

I would’ve nuked Next completely, but we like the filesystem-based server and the ability to add imperative server-side logic cohesive with each page (getServerSideProps). In the past, this logic ends up on a separate server file and it’s less cohesive. Next keeps things a bit more organized for us.

I like your stack. What’s your use-case?

I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be approached soberly and prudently. Not every site needs React and GraphQL.

Absolutely.

The trends and gimmicks have caused this “walled garden” effect. It’s made both “practical frontend engineers” and “practical frontend architecture” a rarity. If I could write this post again, I’d talk more about how most use-cases simply don’t need a “modern tech stack”.

React is basically a glorified templating engine that attempts to enable reactive mechanisms on the client. Need “reactive”? Consider Svelte as well. Don’t need it? Consider moving the render to the build and use a lighter templating engine.

I’m hoping to write a more general post soon about selecting tooling per-use-case, which certainly should not result in this overpowered and complex stack in most cases.

I probably should’ve clarified that this stack is geared toward our enterprise-facing cloud dashboard. There’s a lot of data flying around and it needs to be displayed real-time. But most websites really don’t need this stuff. Front end needs to learn what backend has figured out: the stack has to fit the use-case.

I probably should’ve titled this post better, since I’ve been wanting to write more about how to make appropriate front end tooling decisions in general... not just our extremely dynamic use-case. The entire web seems to be running bloated React apps despite most sites’ needs being solved by the old stuff or new things like 11ty.

Just to clarify as well (since I didn’t in the post), we’re still using Next despite nuking the SSR because the filesystem-based server is useful to us and we like the patterns they provide for running server-side code.