Busy experimenting with replacing transpile modules in place of some simple patches to nexts loaders for workspace packages. For packages that import css from npm, I’ll adjust css loader rules. Don’t need full transpile of js only css handling.

https://twitter.com/ScriptedAlchemy/status/1608656350195908608

So far, dropping next transpile modules for my custom loader shims took another 10 seconds off the build. Heavily inspired by next transpile modules, but I only need it to run over .css, not my 600 module component lib which is already babelified. only applied to 2 of 20

I’m thinking about integrating OpenAI into Medusa. This is what powers ChatGPT, but I’m able to train the AI models.
“Deploy remote A to stage, I want to test it in host B”
“Share all the common dependencies between apps A B C, treeshake the unused exports between them” “Will this pull request break any contracts with applications consuming it?”

In 2023 I’m going to try and build out a edge worker native, Module Federation based platform for the community.
Single command to scaffold and deploy it all in seconds.
Collaborating with @Netlify and combining Medusa - we are going to completely remove manual configuration. You won’t need to know anything about Module Federation. You won’t even see it. It will be like next or create react app. It will just work. Just import code. Absolutely nothing to setup or think about. An enterprise level platform would take about 60 second to create and deploy

@vercel thank you for correcting the article.
After the holiday I’ll publish a comprehensive document that makes it easier for users to evaluate their options. I recommend incremental monorepo always, they work well with federation - which can be added later if mono hits limits Here’s why monorepo is always a good idea. The workspaces have their own builds. Things have a better chance of not getting tangled. It encourages devs to build modular, more isolated parts. Splitting an app or repo is much easier, consolidating a split is easier.

Well at least Vercel finally uttered the forbidden words. Pity the information is wildly distorted. Makes UX worse? Performance worse? My next apps have half the cold start when federated vs monolith. Fully load in 500ms. Time to write an article 🤩

vercel.com/templates/next… Multi zones is still the answer they’re pushing. A page refresh between apps ranges between 3-6 seconds. A federated load is like 600ms. Using zones would cost me several 100 million a month in revenue.

@leeerob @ecyrbedev Comes down to design, but yes. Since I can pin any host at a previous deploy. MF can load any commit ever pushed in the last 5 years. A push of a button to change anything anytime. Checkout can just stay on header v2 during freeze while the community hub is on v3. @leeerob @ecyrbedev MF also enforces better patterns, that align with your perspectives. But now its mandatory not a "please write clean code" federated modules are wrapped in error boundaries, are able to fetch data if needed, expose a minimal API for props, use recoil for communication

Only feat remaining for federate edge workers is figuring out how to “hot reload” them. They are short lived - but I still need a way to force a code pull when something’s updated.
In node I could just clear require cache and re require the webpack runtime This is tricky with deno as it’s esm and the import cache isn’t exposed. So I might have to “back boot” the worker - have host use its own remote, then dispose of it as needed. Letting me restart webpack on demand without killing processes.

Aight working on my federated netlify workers at the moment. Ive created two workers, which will act as host/remote pairs - to be able to perform a code pull, I've set the publish directory to be the same as the worker edge function directory. Now for the big part, adding NodeFederation & setting up the remotes I want to pull. Then ill see what breaks and start updating the runtime modules & code loading in such a way that's not dependent on node-specific APIs.

I don’t have the bandwidth but I’m looking to see if anyone would want to join a group effort to build something new. @sebmarkbage made a tweet about browsers should ship with the top 1GB of npm packages. This got me thinking… please read thread 👇 Shipping with browser unlikely, version issues. But module federation share scopes already handles multiple versions. Like the old jQuery CDN days - we could create a federated module + supplemental chrome extension (optional). Rather than loading all those common dependencies…

Resolving a MONSTER bug in WMF SSR - took all day to even understand what was wrong This one tested me lol. The sheer amount of webpack runtime knowledge required to understand the problem was insane. A typical complex challenge takes about a day. This one took nearly 3 days to diagnose and trace. Brutal

That one time I needed to save a company from itself and sneak some heavy repairs into the codebase…by rewriting git history and applying a patch to force pull on all local machines so nobody notices. Or that other time where I had to craft a supply chain attack to sideload infrastructure repairs across an organization. Nobody ever reads the source of an npm package nor do they really scrutinize a patch release

This next plugin SSR plugin is going to be the death of me. 🥲
My shared module chunks are somehow disappearing but the runtime still points to it. The incompatibility between Next.js and Module Federation is absolutely infuriating. I’m going to have to hire some devs for this I’m like a few loaders and plugins away from a completely seperate webpack config. At this point Next is basically a page folder and router. It would probably be easier to just write new entry points and completely stop using the next build altogether.

🚨Big Announcement 🚨 No, I’m not joining Vercel :/ HOWEVER.
Federated SSR comes to Edge Workers. But it’s not just SSR… it’s code streaming! That means full scale support for any federated code, at runtime, right on the edge, with no origin servers. This is a big deal 🧵 Code streaming was one of the first things we built, but it never worked well on node.js. Once a federated module was imported, it becomes “stuck” - you can’t retrieve new remote updates unless you restart the process. That changes today! 🧵

The more recruiters and companies that react out, then more i find myself agreeing that JDs should include compensation upfront. My first response is almost always something like “what’s the comp” or I’ll just send back “comp neg needs to start at X USD” I hate interviewing, and I’m not expending any time or effort unless I know upfront it’s worthwhile.
Check LinkedIn, check GitHub, send me a formal offer & let’s do the culture fit interviews. The rules can be bent or broken. Whatever your process is, it can be overridden

💡 Thinking about organizing federated code like this in next.js - might be useful for others dealing with scale.
🧵🪡
- Create a /federated folder, similar to /pages.
- plugin loops over the folder same way next does pages.
Why this is useful - you can specify a pattern🧵 Like next has getInitialProps, you could specify a pattern for exposing code to consumers. Like if it depends on some provider that’s usually set elsewhere in the parent app, you’d be able to export out a self-sustaining encapsulation with a consistent api. 🧵

Took my cookie read times from 100ms to 0.4ms.
I track what cookies we actually get(), when those cookies are updated, I refresh the in-memory object containing all cookies. Cookie.get vs Cookie.get(cookie) costs the same computationally, so getting all of them and storing it ends up being more efficient.

Especially since most of the cookies I'm reading internally are set by the server, so I almost never actually write new cookies to memory