Néstor's Blog

Federation of Specialists: From Module Federation to AI Orchestration

Fri, 17 Apr 2026 00:00:00 GMT

Frontend teams already learned how to split monoliths without breaking product experience. AI systems are going through a similar shift.

This talk traces the move from federated UI and composable runtime systems to a federation of AI specialists. It focuses on why production AI works better when agents have clear roles, controlled tools, workflow hooks, shared collaboration context, and policy boundaries.

Event source

Module Federation in Practice: Microfrontends Across Frameworks and Bundlers

Thu, 16 Apr 2026 00:00:00 GMT

A practical workshop on using Module Federation across different frameworks and bundlers.

The session compares implementation approaches, shows how Module Federation supports microfrontends and adjacent architecture patterns, and explains how Zephyr Cloud simplifies orchestration for federated applications.

Event source

Superpositioned Infrastructure and Distributed JavaScript

Wed, 15 Apr 2026 00:00:00 GMT

Serverless reduced operational burden, but it never fully removed infrastructure. This meetup talk explores superpositioned infrastructure and how Module Federation turns distributed JavaScript into a runtime-defined system.

The central idea is to decouple compute and code so services can compose dynamically instead of being tied to one fixed deployment surface.

Event source

Federated Systems at Scale with Zephyr Cloud

Sun, 12 Apr 2026 00:00:00 GMT

A conversation with Dan Neciu and Zack Chapple about deploying federated frontends globally, the operational model behind Zephyr Cloud, and how Module Federation maps to edge delivery.

We cover Zephyr's build-to-edge workflow, reverse tree shaking, local development workflows for microfrontends, federated MCP servers for enterprise AI orchestration, and the Node.js module unloading work needed for better server-side hot reloading.

Episode source

Service as a Software

Fri, 03 Apr 2026 00:00:00 GMT

Ok, so. Here's the weird part: I think the next big software category might look like less software, not more.

The obvious story is "AI will make SaaS better." Sure, probably. But I don't think that's the interesting story.

The interesting story is that the contract is starting to change.

For the last twenty years, the playbook was clean: find a painful business workflow, wrap it in a dashboard, sell seats, add admin controls, add reporting, and call it a category. Salesforce did this for CRM. Zendesk did it for support. NetSuite did it for finance. The customer wasn't buying completed work. They were buying the cockpit for doing the work themselves.

Service as a Software flips that. The pitch is no longer "here's the interface, your team handles the rest." The pitch is closer to "send us the task, we'll send back the result."

That's not a feature change. That's a business model and trust boundary change.

SaaS sells outputs.

This new thing tries to sell outcomes.

The Old Magic Was That the Human Was Still the Runtime

Classic SaaS was such a good business because the software improved the workflow without actually taking responsibility for the final step. It made people faster, more organized, more measurable, less error-prone. But the human operator was still the one closing the loop.

That detail mattered a lot.

It explains why seat-based pricing fit so naturally. More operators meant more value. More value meant more licenses. It was still, at heart, a tool business.

You can see this pretty much everywhere:

the CRM creates and organizes the lead
the support system tags and routes the ticket
the finance product assembles the invoice

But the software stops one level short of the actual business promise. Someone still has to decide, approve, send, reconcile, follow up, or clean up the weird edge case from Thursday afternoon.

That's the part getting eaten.

The Category Shift Is Not AI Features, It's Operational Ownership

This is where I think people flatten the whole thing into "AI SaaS", which is a bit too neat.

Adding a chatbot to the sidebar is not the shift. Autocomplete isn't the shift either. Even a very good copilot may not be the shift.

The shift happens when the software starts absorbing enough of the operational loop that the customer relates to it more like a service provider than a tool vendor.

Not "help my team do this."

More like "just get this done."

That's the center-of-gravity move.

An output is what the product produces: a record, a draft, a classification, a generated invoice.

An outcome is what the customer was actually trying to buy: the meeting got booked, the refund got processed, the ticket got resolved, the books got closed without drama.

SaaS made operators better at producing outputs.

Service as a Software tries to own enough of the path to the outcome that the customer stops thinking in clicks and starts thinking in completed work.

What This Looks Like When You Zoom All the Way In

Take invoice processing.

In the SaaS version, the pitch is familiar: here is a cleaner queue for your AP team, better search, better approval flows, maybe some OCR so the PDFs stop being awful. Still useful. Still software. Still your team doing the job.

In the Service as a Software version, the promise gets much more specific:

ingest the invoice from email or vendor portal
extract line items and tax fields
match it against the PO and vendor record
push straight-through cases into the ERP
route the suspicious 6% to a human with context attached
keep an audit trail for every decision

Same workflow. Very different product.

The thing being sold is no longer "finance software." It's closer to "we help you close AP without staffing every step manually."

And once you frame it that way, a bunch of product decisions invert.

The Interface Gets Demoted and the Invisible System Gets Promoted

In classic SaaS, the dashboard is the star. You demo the UI. You count active seats. You brag about time spent in product (well, maybe not publicly, but you know what I mean).

In this model, the ideal reaction is almost the opposite:

That's a very different success condition.

The visible app gets thinner. The invisible machinery gets much more important:

orchestration
retries
confidence thresholds
escalation paths
audit logs
human review queues
fallback logic for when the model gets weird

Because the work is the product now, not the screen.

The Real Moat Is Not the Answer, It's Owning the Miss

This is the part I keep coming back to.

The hard part is not generating something plausible. Models are increasingly good at that. The hard part is being on the hook when the result is wrong.

A normal SaaS vendor can still say, in effect, "we provide the controls; your team decides what to do." A Service as a Software company has to say something much scarier:

That's why I don't think the moat here is "we have access to model X."

The moat is everything around the model:

confidence calibration
exception routing
rollback and replay
compliance posture
auditability
good human handoff when automation should stop pretending

In other words: operational taste, turned into software.

That's the asset.

If You Want to Build This, Usage Metrics Stop Being the Main Story

This also changes how these companies should probably be measured.

If your product is still basically software, you care about seats, time in app, feature adoption, expansion by team, all the usual stuff.

If your product is drifting toward service, the better questions start sounding more operational:

what percentage goes straight through without human touch?
where do failures cluster?
how quickly do exceptions get resolved?
how legible is the audit trail?
can a customer trust the handoff when the system says "I don't know"?

That's why this category feels so awkward to people looking at it through a pure SaaS lens. The product metrics start blending into service metrics. The app becomes part software, part operations console, part policy engine, part accountability surface.

Messy category. Real shift.

Software as a Service Was an Abstraction Win; This Is the Next One

Software as a Service took us from installing boxed software to renting capabilities over the network. Huge abstraction win. One of the best business-model upgrades the industry ever got.

Service as a Software feels like the next step. Not because dashboards are dead. They aren't. And not because every workflow should be fully automated. Absolutely not.

But because more buyers are going to ask a much simpler question:

Do I want another tool for my team?

Or do I want this problem mostly gone?

That seems like the real shift.

The companies that matter in the next wave won't just build nicer admin panels with better AI affordances. They'll build systems that quietly eat repetitive service businesses from the inside, one workflow at a time.

I don't think we fully have the language for this category yet.

But I think this is the layer that matters.

Bad Apple on Module Federation

Sun, 15 Feb 2026 00:00:00 GMT

This one started the same way a lot of dumb fun ideas start: with me wondering whether something that absolutely should not exist could still be made to work.

So I gave 5.3-codex a ridiculous prompt and asked it to turn Bad Apple into a Module Federation experiment. Not a normal one either. I wanted the whole thing broken into tiny pieces and loaded through a single runtime like the most unreasonable version of a microfrontend demo possible.

The result was 5,258 microfrontends being loaded and unloaded at a steady 24fps.

What surprised me was not that it rendered a couple frames and then exploded. What surprised me was that it just kept going. No weird collapse halfway through, no immediate stutter-fest, no runtime tantrum. It just kept up with every boundary and played through like this was somehow a perfectly normal thing to do.

That is why I like this project so much. It is half joke, half stress test, and half me being unable to leave a terrible idea alone once I realize it might actually work.

<div class="relative w-full overflow-hidden rounded-lg shadow-lg" style="padding-top: 56.25%;"

If you want to watch the full thing, the demo is on YouTube. If you want to inspect the mess, the code is on GitHub.

Superpositioned Infrastructure: Build Anywhere, Deploy Everywhere

Fri, 06 Feb 2026 00:00:00 GMT

This talk explores a simple idea: "serverless" did not remove servers, it mostly hid where artifacts land. Building on lessons from Module Federation and Zephyr, I argue for overlay infrastructure where services are not pinned to fixed nodes and can materialize exactly where they are needed.

I cover single-node and multi-node overlays, decoupling the filesystem from computation, and what becomes possible when CI can stream work into any environment instead of targeting one predefined place.

The goal is less orchestration, fewer hard infrastructure boundaries, and a path toward intent-driven systems.

Module Federation and Infrastructure Superposition

Thu, 15 Jan 2026 00:00:00 GMT

This session looks at Module Federation as more than a microfrontend pattern: a deployment model that can reduce the operational weight of shipping software and move infrastructure closer to a dynamic, request-shaped system.

I start from the limits of classic serverless: servers still exist, regions are still fixed enough to matter, and deployment pipelines can become heavier than expected. From there, the talk explores infrastructure superposition, where services stay dynamic and materialize where they are needed instead of being pinned to a single deployment surface.

Event source

The Four Chips of AI Supremacy

Sat, 06 Dec 2025 00:00:00 GMT

What if every AI company is playing a game with four rules they didn't write?

There's a framework going around among people who actually build AI systems. Not the evangelists, but the engineers watching their training budgets vanish. It says the AI race isn't about who has the best model. It's about who owns four infrastructure layers that decide who really runs this space.

Here are the four "chips." Not literal silicon, but the four layers of power every AI company ends up depending on.

Chip 1: The Silicon (The Compute Layer)

This is the foundation: Tensor Processing Units, the hardware that runs the math. While everyone obsesses over Nvidia's latest GPU, the real power move is owning the whole compute stack. TPUs aren't just accelerators. They're the physical foundation that decides how fast you train and how much it costs to run models. Whoever owns this decides who can even afford to build the big models.

Why it matters: If you don't control your silicon, you're paying rent to someone who does. Every AI company is either designing chips (Google, Amazon, Meta), buying them at scale (OpenAI via Microsoft), or getting squeezed by both. Your model is only as good as the compute you can access, and the price you pay for it.

Chip 2: The Data Centers (The Physical Layer)

This is where power gets physical. Data centers aren't just buildings with servers. They're about who has the money and power to actually build them. The key detail: GCP is profitable today, and those profits fund tomorrow's expansion. No investor rounds, no begging for cash. It just keeps growing on its own.

Why it matters: Training a big model costs around $100 million in compute. If you don't own the data centers, you're not just paying for electricity. You're funding your competitor's expansion. Every dollar you spend on AWS, Azure, or GCP makes them stronger for the next training run. You become a customer of your own rival.

Chip 3: The Models (The Intelligence Layer)

This is the layer everyone thinks matters most. But here's the trap: models don't last. Gemini is impressive today, but it'll be obsolete in 18 months. What matters isn't the model itself, but the ability to keep making better ones forever. Duplex in 2018 proves they solved core LLM challenges years before the "AI boom." They just didn't ship it until the market forced their hand.

Why it matters: Building a better model than GPT-4 is a temporary win. Building the system that produces better models indefinitely, that's what actually matters. Every AI company is either building that system or hoping their current model's lead lasts long enough to raise the next round.

Chip 4: The Distribution (The Reach Layer)

This is the layer that wins the game. You don't need distribution deals when you have 2.5 billion devices waiting for updates. While OpenAI needs Microsoft's enterprise sales team and API partnerships, others can flip a switch and their AI is in every pocket, browser, and email client overnight.

Why it matters: The best AI model in the world is worthless if no one uses it. Distribution is the difference between a research paper and a product. Every AI company without their own way to get to users is just a feature waiting to be absorbed or replaced.

The Uncomfortable Truth

Here's what the framework reveals: every AI company is stuck in this four chip system. You're either:

Renting the first two chips (compute and data centers) from Nvidia or Amazon
Fighting it out on the third chip (models) in a race you can't sustain alone
Begging for access to the fourth chip (distribution) from those who own the platforms

Even the most hyped AI labs are just third chip companies paying rent on the first two and praying their distribution partners don't change the terms.

How One Company Stacks All Four Chips

Let's look at what happens when you actually own the whole stack: Google.

Chip 1, Compute: They've been making TPUs for seven generations. They control everything from the compiler to the networking, so they can tune power, speed, and cost together instead of waiting for an OEM to update firmware.

Chip 2, Physical: They treat data centers like products. They pick sites for cheap power and build with cash flow, not investor money. Because GCP is already profitable, every training run a customer buys funds the next building, which makes everything cheaper. That cycle is hard to catch from the outside.

Chip 3, Intelligence: Their research pipeline is a conveyor belt: foundational work (BERT, Transformer) → big models (Gemini) → specialized versions (Med-PaLM) → product features (Workspace, Pixel). The whole organization is built to ship the next model, not just defend the current one.

Chip 4, Reach: This is the checkmate piece. Android, Chrome, Gmail, Maps, YouTube, and the Play Store give them billions of ready to update devices. Server side rollout (Search, Ads) plus client updates means new AI features can land in days without asking anyone's permission.

The Real Moat

The insight isn't that any single company is invincible. It's that real AI power requires all four chips working together. You can be the best at one layer, but without the other three, you're a specialist in a generalist's world.

The four chips don't care about your model's benchmark scores. They care about who owns the stack. And right now, most AI companies are just tenants.

Lessons from a Keyboard Basher

Fri, 28 Nov 2025 00:00:00 GMT

A candid session with students at CIFP Rodolfo Ucha. I walk through my career path—the wins and mistakes that opened doors—and how they can replicate it: what to learn first, how to build a portfolio that shows real skills, where to find opportunities, and what to prioritize in interviews. I also cover why collaborating with community, writing about what you learn, and choosing projects that tell a clear story to employers makes such a big difference.

Microfrontends deployments in 10ms with Zephyr Cloud

Tue, 14 Oct 2025 00:00:00 GMT

10 milliseconds. That's not a build time—it's a production deployment. At Zephyr Cloud, we reimagined microfrontend delivery from first principles, building a platform where frontend updates ship at the speed of memory access. This talk reveals how we layer Module Federation with our edge-native runtime to achieve sub-second deployments, the pipeline architecture that makes 'push to prod' instantaneous, and the safety mechanisms that empower teams to move fast without the traditional risks. Learn how we eliminated the infrastructure tax on frontend releases and what it takes to make millisecond deployments production-ready.

From Light Bulbs to AI Agents

Wed, 01 Oct 2025 00:00:00 GMT

Remember debugging MQTT topics for smart-home gateways?

kitchen/temp → 21.5 °C
garage/door → closed…

The reason we loved MQTT back then was dead-simple:

One broker, n-many clients
Pub/sub decouples who talks to whom
Wildcards + retained messages give discovery for free

In my opinion, those same three super-powers turn out to be exactly what large-scale AI systems are crying for today.

When every micro-service, RAG pipeline, and LLM wrapper can show up, disappear, or change price in seconds, you need a routing layer that is:

Stateless on the broker side
Embeddable in fire-walled environments
Able to notify 500k nodes in sub-linear time

Sound familiar? It's called MQTT.

The Problem No One Tells You About "AI Orchestration"

Classic tool-chaining frameworks are stuck in the HTTP era:

A central router holds open connections to every worker → file descriptor explosion
"Who can do what?" becomes a never-ending polling loop → rate-limit hell
Exactly-once and redelivery? DIY retries, exponential back-off, circuit-breakers… all in your code base

We fixed these pains for thermostats years ago by moving to MQTT.

It's about time to apply the same medicine to language models and vector stores.

Agent Resumés As Retained Topics

Publishing a sensor value is old news. Publish an agent's capabilities the same way:

agents/{agentId}/resume ← retained JSON:

{
  "skills": ["sql-optimiser", "nl2chart"],
  "cost": { "usd": 0.02, "p95_ms": 350 },
  "region": "eu-central-1",
  "accredit": ["ISO27001", "gdpr"]
}

Any orchestrator (or CLI) that subscribes to agents/+/resume builds a real-time registry without HTTP calls, without polling, without a single line of server code.

Task Requests Fly Over Wildcards

A client publishes a complex request to tasks/{uuid}/request
Capable agents auto-reply with proposed sub-task DAGs onto tasks/{uuid}/proposal/+/
(wildcard plus means anyone can read, but only proposal-owner can write)
The orchestrator chooses the merged DAG and publishes individual assignments under tasks/{uuid}/assign/{agentId} with QoS 2
Results come back via tasks/{uuid}/output/{stepId} – again retained, so late-join nodes never miss state

Because MQTT has three built-in QoS levels, the exactly-once path for critical steps costs you one flag, not a weekend of re-write.

Scaling To 100k Clients Without Boiling the Broker

Eclipse Mosquitto 2.x already demonstrated 200k+ concurrent connections on a $5 VM. Memory usage per idle client? <4 kB.

Publish payload for a capability update or intermediate JSON result is typically under 2 kB, smaller than the average JPEG thumbnail we once pushed for camera snapshots.

If your broker handled 100k temperature sensors, it will handle 100k agents without breaking a sweat.

Security & Compliance Out-of-the-Box

Topic ACLs support wildcards, so a hospital can forbid any agent advertising gdpr=false from subscribing to PHI topics:

pattern readwrite +/gdpr/false/#
pattern deny +/patient-data/#

Add X.509 client certs and you've got mutual TLS plus topic-level policy enforcement, all broker-native.

From the Edge to the Cloud With Shared Subscriptions

Need a GPU-heavy task but the edge device is a Pi? Create a shared subscription group:

$share/gpu/tasks/+/heavy

Cloud nodes join the group, messages are load-balanced among them yet still replied to over the original task UUID.

Another personal example

A video encoding job came in while I was traveling with just my laptop. My home server cluster was idle but my laptop battery was running low.

I prefixed the topic:

$share/media/encode/+/video

The home servers in the same share group picked up the encoding task, my laptop stayed cool and quiet, and the processed video was ready when I got back online.

Shared subscriptions are MQTT’s built-in load balancer.

No HA-proxy of any kind
No Kubernetes service mesh

Just a dollar sign.

What You Must Actually Reconfigure

Nothing. Your favourite broker (Mosquitto, EMQX, HiveMQ, Nanomq) already supports every pattern above.

All that changes is perspective:

Retained messages → the single source of truth
Wildcards → declarative queries
QoS levels → reliability without code
ACLs → policy enforcement at wire-speed

Take from someone who already speaks MQTT

Today the "things" are no longer light bulbs, they're containerised LLMs that spin up in Ohio, complain about GPU quota, then vanish.

The chatter is still:

birth message → “I exist, here’s what I can do”
telemetry → “this is my current cost, latency, license”
command → “execute sub-task 7”
last-will → “I died, don’t route to me”

Your old topic patterns already cover 90% of that lifecycle.

The only new ingredient is intent: instead of °C you publish embeddings, instead of toggling a relay you toggle a 4-bit quantised model.

Turns out the Internet of Agents just needs the same boring stack we trusted to keep the porch light on.

My Bizarre Dev Adventure: Atlanta to Austin Arc

Mon, 01 Sep 2025 00:00:00 GMT

So I just spent almost two months traveling across the US, hitting conferences, meeting customers, and somehow managing to live-debug production code mid-pitch. Let me take you through this absolutely wild journey that started with a customs interrogation and ended with me shooting guns in Texas for the first time.

Atlanta: The Great Luggage Swap & RenderATL

Day 1: Welcome to America lmao

Left Madrid, landed in Atlanta. Got through customs clean, then plot twist, got stopped halfway out. They put me in a room for 30 minutes. Asked what happened and they told me "we can't tell you, goodbye". Welcome to America, I guess?

My boss Zack Chapple picked me up and immediately took me to Costco. Yes, Costco. First stop in America. Bought some pecans that made it all the way back to Spain (they were incredible, btw). After Chinese food and meeting his wonderful family, we headed downstairs to unpack.

Here's where it gets hilarious: IT WASN'T MY LUGGAGE. Same exact suitcase, shape, color, everything, but someone else's entire life inside. And apparently, the one I accidentally grabbed was a rush order (urgent baggage). Whoops. We hustled back to the airport at midnight, apologized profusely, got mine back. Crisis averted.

Day 2-4: RenderATL Madness

Next day we also picked up a shiny new Apple M4 Max. Sweet.

Day two kicked off in properly American fashion: Wendy's Breakfast Baconator.

Then straight to RenderATL where I finally met my coworkers Shane, Lois, and Sika in person. Also Xavier and Ptah from Southern Glazer's, and Joannier from Microsoft.

First day was mostly networking, but I got to meet Luca Mezzalira, the microfrontends guy. We hit up the Makeswift and BigCommerce booth and met Sani Yusuf, who knew Zephyr from the early days when the company was starting.

Day two was an absolute blast. Went around all the booths meeting with the Cloudflare, Google, Vercel, Netlify, and Figma people. All super nice!

The speakers' dinner was where things got interesting:

Met Eric Wendel (we'd met before in Madrid but neither of us remembered, classic)
Finally met my long-time friend Chris (TrashDev) from Netflix in person
Francesco Ciulla and I geeked out about Rust and the dynamic tree-shaking stuff we're cooking at Zephyr

J Chris Anderson from Vibes.diy blew my mind by creating and deploying apps from his phone on the spot

After-party queue was insane, wrapping around the building. Shane, Chris, Lois, and I said "screw it" and went for a walk instead. Shane spots some guy and goes: "Dude, that's a fucking actor."

IT WAS MICHAEL PEÑA from The Martian and Shooter. Got a pic and everything.

We ended up at a Japanese place for ramen, then stumbled into a hotel room party hosted by Ryan Furrer and Chris Nowicki. Free drinks, great conversations, perfect night.

The Cloudflare Incident™

Day three at Render was comedy gold. While working from our coworking space with Xavier, Luca, Zack, and Joannier, Cloudflare had a massive outage. Watching Luca and Joannier frantically checking internal Amazon and Microsoft channels to see if it was global was hilarious.

Back at the conference, everyone crowded around the Cloudflare booth demanding answers. Then we found out it was actually GCP's fault, so the entire mob migrated to Google's booth. I've never seen anything like it.

Met the absolute legend Ken Wheeler at the Netlify booth. Most charismatic person I've ever met, hands down. Caught Zack Chapple's microfrontends talk (really solid), then tried bison meat for the first time at dinner while Ken entertained everyone with his stories.

Last RenderATL day: early demos with Miguel from Makeswift and Ali Tas from PayPal about Zephyr.

First-ever Waffle House experience (another American checkbox ✓).

Caught talks from Xavier and Lois.

Later that night, I hit another party where I met tons of people including Roy Tan, Sterling Chapman, Shashi Lo, Dillon Goetz, and Ethan Arrowood. Stayed until past midnight just talking tech and life.

Bonus Atlanta day: breakfast with Chris and friends including TypeSafeUI and Max Kless from Nx. Later, Max, Lois, and I hung out with Altan Stalker, another Nx engineer, exploring Atlanta.

Miami: Gators, Cuban Food, and Southern Glazer's

First Day in Florida

Flight to Miami. Amazing Uber driver gave me life advice the whole ride. King, if you're reading this, you rock.

Pulled up to my hotel and there's a fucking alligator just chilling at the entrance. Of course there is. Welcome to Florida. We all stood around for 15 minutes until animal control relocated it. Sad I didn't get any pictures.

The Cuban food and juice shops in Miami? Incredible. I'm still dreaming about those fresh juices.

SGWS Office Week

First day at Southern Glazer's offices: sat with Javier Oropesa diagramming Zephyr architecture and explaining our infrastructure implementation in detail. Later met Jeff to discuss Module Federation specifics.

That evening, finally met coworker Kelly Hull in person. Dinner at a Cuban place nearby.

Day two brought the whole crew: Zack arrived along with Xavier and Ptah. Argentinian steakhouse for lunch (amazing meat).

Then my first Chinese hot pot that night. Loved it so much I ended up having hot pot in multiple cities after this.

We left with the Hard Rock Hotel lighting up the entire Miami sky behind us.

Spent the next days deep in planning: Zephyr + SGWS architecture, CDN optimization, infrastructure decisions. Met Hrayr Mirzoyan, one of their architects who became an instant friend.

Jordan Powell from Nx joined us and we improved their CI times with Nx caching. Always satisfying watching those build times drop. Wrapped the week clearing knowledge silos and making sure everyone understood Zephyr's full capabilities.

Kelly and I found a Spanish restaurant one night that had all the provincial shields of Spain on the walls. Nice touch for a homesick Spaniard.

Weekend in Brickell: changed hotels, walked around Miami, did touristy stuff, bought clothes in the crazy heat. Massive thanks to Hrayr who took an entire day to show me around Miami: beaches, neighborhoods, the whole Miami lifestyle. You're the best, man.

New York: Vercel Ship & Everything Else

Empire State Views to Spotify Offices

First stop: offices with a perfect Empire State view. Ended up talking about Ember.js (throwback!) and speedran a plugin to make it deployable to Zephyr. Still got it.

Spotify offices at the World Trade Center. Gorgeous views, amazing space. Had great conversations with Ilya Lyamkin from the Backstage.io team.

Hit a Callstack React Native meetup where I met CEO Kris Lis and cofounder Mike Grabowski, amongst other people from Callstack. Super nice people, great energy.

Vercel Ship

Vercel Ship 2025 was an absolute vibe. They know how to throw a conference. Met up with my friend Javi (who I knew from before), and also met Guillermo and Malte. Got this cool pin with an NFC tag that I still carry around.

Worked from a coworking spot with Yagiz from Cloudflare, addressing some infrastructure questions we had.

Later I hit a LightningAI meetup and rooftop drinks where I met Jorge Sancha from Tinybird, one of the few Spanish startups killing it internationally.

Also hung out with Derek and took him to this amazing Galician restaurant in NYC. Always fun sharing Spanish culture with friends, especially when you're thousands of miles from home.

Rest of NYC was pure tourism. Hit all the spots, ate all the food, walked until my feet hurt.

Seattle: Module Federation Deep Dives & July 4th

Landed in Seattle and immediately met up with Zack Jackson, creator of Module Federation and infra architect at ByteDance. We spent days together going deep on everything: distributed backends, JavaScript engines, and this wild idea about superpositioned infrastructure technology with Web3/blockchain elements. I'll write about that separately because it deserves its own post.

Quick visit to ByteDance offices, tourism around Seattle, and then July 4th at Gas Works Park watching fireworks. Pretty epic way to experience American Independence Day.

The Tweet-Worthy Moment

The next week, while visiting a customer, I was mid-pitch demonstrating Zephyr when I spotted an issue in their docs. The customer challenged me directly: "If Zephyr is that fast and good, prove it. Show us." So I did. Without missing a beat, I found the issue, patched it IN PROD, and kept going with the demo.

Zack tweeted about it

The longest part was that I'd never used that codebase before and had to find the problem. The patch was live before the commit hook even finished. Sometimes you just gotta ship.

Also took a stroll through the Microsoft campus, saw all the Minecraft stuff in the offices. Really cool to see where the magic happens.

San Francisco: The Gang's All Here

Quick office tours, then met our interns at True Ventures: shoutout to Nitin, James, and Miles. You guys rock!

Cluely offices were absolutely stunning. Loved the vibe and energy there with Roy Lee and the team.

At Cloudflare SF, got my photo with the iconic lava lamp wall (bucket list ✓) and talked more infrastructure.

Later, met Gary Qi from the Trae team back at True Ventures. Super chill guy.

An Evening at Theo's

The night at Theo's place was a "meet your heroes" kind of evening. Theo was super friendly and taught us a crazy amount of information about content creation and cameras. I enjoyed every last bit of it.

Also met Mark in person finally, we only talked a couple of times over Discord. Caught up with Ben (we'd met before but neither could remember from where LOL). Chatted with Amber from Trae and @itseieio, creator of onemillioncheckboxes.com. Big fan btw.

Austin: The Final Stop

Left SF at around 4 AM super sleep deprived even though we had slept a couple hours. Landed in Austin at 1 AM (love those late flights). Next day, straight to Cloudflare's Austin office to work and randomly bumped into friends who happened to be there.

Met Dane, Cloudflare's CTO and had some really exciting conversations about infrastructure and future possibilities. Super nice guy. It just so happens that the Makeswift team was there at the same exact time so we spent some time with them too.

Also met with my long time friend Josh from Manifold Labs. He took me for lunch to a really cool place. Cheers mate.

Before flying home, I went to a shooting range for the first time in my life. Adrenaline rush like nothing else. Very Texas way to end a very American trip.

Thanks to everyone who shared their time, knowledge, food, and last-minute party access. The tech community is incredible, and meeting so many online friends IRL was surreal.

Special thanks to Zephyr for making this entire adventure possible. Without this amazing opportunity, none of these stories would exist. Grateful to work for a company that believes in building relationships and experiencing the world firsthand.

Until next time! 🚀

P.S. - Still thinking about those Miami juice shops and that first hot pot experience. Some things just hit different when you're 5,000 miles from home.

IoT Gateway

Sat, 24 May 2025 00:00:00 GMT

Over the past few months, I've been working with Raimon and Oriol on something we're really excited about - IoT Gateway. It's an industrial IoT platform that completely changes how you deploy and manage edge systems. Let me walk you through what we built and why I think it's pretty special.

The Problem We Set Out to Solve

If you've ever deployed IoT systems in industrial settings, you know the pain. You're constantly juggling USB drives, manually configuring each device, and praying everything stays connected. When something breaks at 2 AM (and it always does), you're either driving to the site or walking someone through complex troubleshooting steps over the phone.

We wanted to fix this. Our goal was simple: make deploying and managing industrial IoT systems as easy as spinning up a cloud server. No USB drives, no manual configuration, just plug it in and it works.

How We Made It Happen

The magic starts with network boot. When you power on a device, it doesn't need any local OS or configuration. Instead, it boots directly from the network using iPXE. This might sound complex, but here's what actually happens:

Device powers on and asks for an IP address
Our DHCP server responds with network boot instructions
Device downloads a lightweight live environment
System automatically configures itself based on your requirements

The beauty is that this works with pretty much any x86-64 hardware that supports network boot - no special equipment needed.

The Architecture That Makes It Work

Let me break down how we architected this thing. We divided everything into four main parts:

The Provisioning System handles getting new devices online. We built this on top of iPXE and Clonezilla because they're rock-solid and work everywhere. When a device boots, it loads our custom environment that includes everything needed to configure the system.

The Control System is where the configuration magic happens. We use Ansible Forms (which dynamically generates web interfaces from Ansible playbooks) combined with Git for version control. This means you get a nice UI for configuration, but everything is still code under the hood. Every change is tracked, reversible, and reproducible.

The Application Layer runs your actual workloads. We went with Docker containers managed by Dockge because it gives you flexibility without complexity. Need to run Node-RED for automation flows? MQTT brokers for device communication? Custom applications? Just define them in a compose file and deploy.

The Monitoring Stack keeps tabs on everything. We integrated Grafana's entire ecosystem - Alloy for collection, Mimir for metrics, Loki for logs. This gives you enterprise-grade observability without the enterprise price tag.

What Makes Our Approach Different

Instead of building yet another monolithic platform, we focused on composability. Everything is modular - you can use just the provisioning system, or add monitoring, or go all-in with the complete stack.

We also made some opinionated choices that I think pay off:

OpenWRT as the base OS: It's tiny (100MB!), battle-tested, and designed for embedded systems
GitOps everywhere: Every configuration is in Git, making disaster recovery trivial
Layer 2 VPN support: We use ZeroTier in bridge mode, which means you can extend your network to non-IP industrial devices
Network-based recovery: If something breaks, you can restore from backup without touching the device

Real-World Implementation Details

Let me share some implementation details that make this work in practice.

For MQTT, we set up a hierarchical broker system. Each edge location runs Mosquitto locally for low-latency communication. Then we bridge selected topics to a central EMQX broker. This gives you the best of both worlds - local automation keeps working even if the internet dies, but you still get centralized visibility.

The backup system was interesting to implement. We use Duplicati with a clever twist - backups are stored remotely (S3, cloud storage, wherever), but restoration happens through the same network boot system used for provisioning. Device won't boot? No problem - it'll automatically load the recovery environment and restore itself.

For configuration management, Ansible Forms turned out to be a game-changer. Instead of writing web interfaces, we just write Ansible playbooks. The UI generates itself based on the playbook structure. Change a variable? Add a new package? Just update the playbook and the UI adapts automatically.

Performance and Practical Considerations

Here's what you can expect in real deployments:

Systems boot in under 30 seconds from cold start
The base image is around 100MB, with typical runtime memory usage around 512MB
We've tested up to 10,000 MQTT messages per second on modest hardware
Full system backups complete in under 5 minutes

These numbers matter because industrial sites often have limited bandwidth and older hardware. We optimized for these constraints from day one.

The Security Story

Security in industrial environments is tricky. You need strong protection but can't break existing workflows. Here's how we handle it:

Every device gets a unique ZeroTier identity and joins encrypted networks. No VPN configuration needed - it just works. The firewall runs in default-deny mode with explicit rules for allowed traffic. All management interfaces require authentication, and secrets are encrypted at rest.

For compliance, every configuration change is tracked in Git with full audit trails. Backups are AES-256 encrypted before leaving the device. System updates are atomic and can be rolled back if something goes wrong.

See It In Action

I've recorded a series of videos walking through each component of IoT Gateway. These demos show real deployments and actual workflows - no marketing fluff, just how things actually work.

Infrastructure & Networking

Network Architecture Overview - Here's how we implement ZeroTier VPN with bridged networking for OT device connectivity

System Provisioning - Watch the iPXE network boot process and base image deployment in action

Configuration Management - This shows how Ansible Forms provides the UI for centralized system configuration

Operations & Recovery

Backup and Restore - Our automated backup process with network-based restoration

Live Rescue System - Remote debugging capabilities through the Clonezilla live environment

System Management Interface - Tour of OpenWRT LuCI, web terminal (ttyd), and SSH access

Application Stack

Container Orchestration - Docker stack management with GitOps and Dockge

Observability Platform - How we integrate Grafana Alloy for logs, metrics, and OpenTelemetry support

Service Monitoring - Uptime Kuma deployment with Grafana integration

Data & Integration

Backup Telemetry - Duplicati with Telegraf metrics collection to InfluxDB

MQTT Architecture - Setting up Mosquitto to EMQX bidirectional bridge configuration

Flow Automation - Node-RED with Git-based flow management

Development

Base Image Creation - The Ansible-driven OpenWRT image build process

Core Team

IoT Gateway is developed and maintained by Industry 4.0 Systems:

Raimon Figueras - System Architecture
Nestor Lopez - Platform Development
Oriol Rius - Industrial Integration

If you're dealing with industrial IoT deployments and tired of the traditional approaches, give IoT Gateway a try. We built this because we needed it ourselves, and I think you might find it useful too.

For technical details and deployment guides, visit the GitHub repository or contact the team at iotgw@industry40.systems.

Feel free to reach out if you have questions or want to discuss industrial IoT architectures. I'm always happy to talk shop about edge computing, automation, and making industrial systems less painful to manage.

Edge-Native Deployments with Zephyr Cloud

Sat, 05 Apr 2025 00:00:00 GMT

Breaking SQLite Boundaries with libSQL

Sat, 22 Mar 2025 00:00:00 GMT

Revolutionizing WordPress: Headless Architecture with Next.js, GraphQL and Vercel

Fri, 21 Mar 2025 00:00:00 GMT

An exploration of how to transform WordPress into a modern headless architecture using Next.js, GraphQL and Vercel to create fast and scalable websites.

RadioVoz Interview on Technology Trends

Tue, 18 Mar 2025 00:00:00 GMT

My Planetary Datacenter I: Architecture

Sun, 05 Jan 2025 00:00:00 GMT

Welcome to the first post in what I’m calling my “Planetary Datacenter” series. Essentially, I’ve got a homelab that I’ve been tinkering with for a while, building, refining, and sometimes breaking it (on purpose!) to learn how to make it better. Now, I’m ready to share everything I’ve learned so far.

I jokingly refer to my setup as a “Planetary Datacenter” because it stretches beyond just my house. Thanks to clever networking and tools like ZeroTier, I can place services just about anywhere on the globe (hence “planetary”) and still have them communicate as if they were right next to each other on my local LAN. If you’re into homelabs, networking, or just curious about how to structure your own multi-machine environment, stick around.

I’ll walk you through all of it.

What is the “Planetary Datacenter” anyway?

I first introduced this idea at a CNCF Galicia talk, where I discussed how I use ZeroTier and WireGuard to interconnect various machines. Over time, I realized that combining ZeroTier with my local hardware gave me a pretty powerful setup: everything in one “big” virtual LAN, accessible anywhere.

So, if you picture your typical data center with racks and servers, now shrink it down to something you can manage in your living room or home office, then magically extend it worldwide. That’s basically the idea.

Why bother with something this complex?

Learning & Fun: I love experimenting. Homelabs are a great way to learn networking, virtualization, and new software.
Centralizing Services: With this setup, I can keep my personal data and services under my control, especially stuff like media servers, backups, and specialized containers.
Planet-Wide Access: I can spin up a new service on a VPS, at home, or in a cloud provider. As soon as I hook it up to my ZeroTier network, it feels like it’s right there on my LAN. And in a worst case scenario, migrating can be done with a click of a button.

Physical Infrastructure at Home

I’ll start by breaking down the hardware so you know what I’m working with.

ISP Router & Ubiquiti hardware

My ISP router is basically acting as a pass-through device. I’ve set it up with DMZ mode pointing straight to my UDM Pro Max. The UDM is the nerve center of my home network. It handles VLANs, firewall rules, and all the fancy Unifi-based management. If you’re familiar with the Unifi ecosystem, you know it’s pretty user-friendly yet powerful enough to do some advanced stuff if you know how to hack it enough.

Switches & Access Points

USW 16 PoE Switch: Handles both power (PoE) for devices like Wi-Fi access points and general switching duties.
U7 Pro AP: My main Wi-Fi access point.
USW Mini: A tiny switch I use for some client machines (like my Mac and a Windows machine).

Main Machines

NAS TrueNAS Scale
- CPU/RAM: Intel i5-7600K, 16GB RAM
- Storage: 1×1TB SSD for the OS + 4×16TB HDD in a ZFS “striped mirrors” arrangement.
- Role: Holds all my data, shared mainly over NFSv4.2.
MS01 Proxmox Server
- CPU/RAM: Intel i9-13900H, 32GB RAM
- Storage: 2×1TB NVME in RAID1
- Special Trick: I fitted it with a modified Intel ARC A380 GPU for hardware transcoding (swapped in a smaller heatsink from an ARC A310).
- Role: Runs Proxmox, which hosts multiple VMs for all sorts of services (media, networking, Portainer, etc.).

VLANs & Wi-Fi Networks

VLANs (or Virtual LANs) let me split up my network into smaller segments, keeping different types of traffic isolated from each other. Here’s what I have:

LAN: The default network for my local machines and most VMs.
Guests: For visitors, restricted access, minimal privileges.
IoT & IoT Private:
- IoT: For general smart bulbs, plugs, and devices that do need internet access.
- IoT Private: For devices that are strictly local (no external communication needed).
Surveillance: Dedicated for cameras. They don’t need broad network access or the internet, so this VLAN keeps them isolated.
Services & DMZ: These VLANs exist in the UDM Pro config but are primarily used in conjunction with ZeroTier.

Wi-Fi Networks

Cardinal (Main Wi-Fi): Tied to my LAN VLAN.
Cardinal Guest: Segregated, on the Guest VLAN.
Cardinal IoT: A 2.4GHz-only SSID for IoT devices. It uses pre-shared keys for network segregation based on SSID password.
- Cardinal IoT: For IoT devices that uses the internet somehow.
- Cardinal IoT Private: For local-only IoT devices with no internet access.
- Cardinal Surveillance: For camera devices, same concept as the private one but as a separate VLAN.

The Role of ZeroTier

I create two VLANs in ZeroTier, VLAN 2 (Services) and VLAN 3 (DMZ), then I bridge them back into my local Services and DMZ VLANs on the UDM Pro.

This bridging is done via some custom scripts and the UDM’s “persistence” system. Because ZeroTier operates at Layer 2, it's not just simple routing, it's effectively replicating the broadcast domain. It might be a bit of a hack, but it allows ZeroTier traffic to flow in and out of my local VLANs as if they were physically plugged in.

Additionally, ZeroTier includes a powerful rules engine. This allows me to define custom firewall-like policies, such as disallowing certain VLAN-tagged traffic, restricting specific ports, or enforcing IP-based rules, directly within the ZeroTier network. That means I can shape traffic based on my exact security needs while still giving devices full Layer 2 connectivity when appropriate.

Why ZeroTier Is at the Core

ZeroTier basically gives me an encrypted overlay network that all my devices, home-based, in the cloud, or in someone else’s data center can connect to. It creates a “planetary virtual switch,” letting me hand out IP addresses on VLAN 2 (for general services) or VLAN 3 (for internet-exposed services).

For example, if I spin up a VPS in some random location, I just install the ZeroTier client, join my ZeroTier network, and give it an IP in VLAN 2 or VLAN 3 and boom, it’s as if it’s plugged into my home switch. That’s the “planetary” part!

I self-host the ZeroTier controller instead of relying on the official ZeroTier infrastructure. Since ZeroTier is open-source, I can run my own controller node on my Network VM.

To make management easy, I use a community-built UI that gives me a web dashboard for seeing which devices are connected, assigning IP addresses, and approving or denying new join requests. It’s containerized using a Docker MacVLAN trick we will talk later about, so it’s directly available on VLAN 2 without any weird network hoops.

This approach also ensures I’m in full control of my environment: if the official ZeroTier services ever go down, I’m still good to go, and I can customize every aspect of my network as I see fit.

TrueNAS & Proxmox

TrueNAS Scale

On my NAS, I’m not using many of TrueNAS’s built-in virtualization features. Instead, it’s mostly:

Storage: A few major datasets.
Network: I install ZeroTier directly on TrueNAS to ensure it can talk to other machines over the overlay network.
Performance: The 1TB SSD is for the OS, and the 4×16TB EXOS drives are in ZFS striped mirrors. This gives a nice balance of capacity, speed, and redundancy.

I also have a direct SFP+ connection between my NAS and the Proxmox server (MS01) for faster data transfers. That means all my VMs can access NFS shares at 10GbE speeds, which is super handy for big data or media workflows.

Why NFSv4.2?

I’m using NFSv4.2 mainly because it builds on earlier versions while adding a bunch of super handy extras. Here’s a quick rundown:

NFSv3 has been around forever and is rock-solid, but it doesn’t include modern security or integrated locking (it relies on separate protocols like NLM).
NFSv4 unified the protocol, locking, and security into one standard, making life easier and reducing extra sideband protocols.
NFSv4.1 introduced Parallel NFS (pNFS), which lets you read and write data in parallel across multiple servers for better performance when you need to scale out.
NFSv4.2 takes it all a step further with features like server-side copy, improved sparse file handling, and extended attributes. This makes it especially handy for virtualization and container workloads where you need faster data movement without pounding your network.

Basically, NFSv4.2 gives me a modern, flexible, and efficient setup, perfect for my homelab needs.

Proxmox Server Node (MS01)

This is my “big” server with an i9-13900H and 32GB of RAM. I also popped in a custom Intel ARC A380 GPU for hardware transcoding (like Jellyfin) because Intel excels at that. Here are some highlights:

Microcode Patches: If you’re using a new-gen Intel CPU, you might need microcode patches to avoid weird performance or stability issues. Here's the Proxmox microcode script if you want to have a look at it.
GPU Passthrough: Proxmox makes it pretty straightforward. You just enable Intel IOMMU in the grub config, load the vfio modules, and pass the GPU through to whichever VM needs it.
VMs: I run four main VMs. Portainer, Network, Media, and Misc.

VM setup

One of the key pieces of this setup is a Docker MacVLAN interface approach that allows my containers to attach directly to the ZeroTier VLAN interfaces.
It keeps host networking simpler and gives each container a dedicated IP isolated to the ZeroTier VLAN.

How it works

In Docker, I create a MacVLAN interface bound to the ZeroTier interface. That way, each container in that network appears on the ZeroTier VLAN with its own MAC address (and IP) instead of piggybacking on the host OS. This method isolates container traffic cleanly from the VM’s main interface, which helps when bridging or routing across different VLANs.

Portainer VM

Runs on Ubuntu 24 nothing fancy installed.
Docker + Portainer so I can have a nice web UI for managing all my containers.

Network VM

Also Ubuntu 24, but here’s where I keep network-related containers:
ZTNET a cool community-built ZeroTier controller UI (built with the T3 Stack!!)
Pi-hole for my private DNS.
Nginx Proxy Manager reverse proxy for my services.
Authentik my identity provider, or IdP.

Media VM

This is my entertainment hub. It has the full *Arr suite. If you have no idea what that is, take a look at the wiki.
GPU passthrough is set up here, so Jellyfin can do hardware transcoding with the Intel ARC card.
All config folders and downloads get mapped to the NAS’s NFS shares, so everything is in one central spot.

Hardlinks & NFS

I’m using hardlinks so that I can have a file appear in multiple places (like the “downloads” folder and the final “TV Shows” folder) without doubling the storage cost.

You just have to be consistent with your paths in Docker Compose, NFS shares and your *Arr apps, so everything references the same “root” mount point.

Misc VM

A catch-all for small projects or services that aren’t big enough to warrant their own machine.

GitOps and Docker Compose

I’m a huge fan of Docker Compose because it’s easy, fast, and reproducible. I keep a Git repo with all my Compose files and volumes declared. If I ever blow away a VM or want to spin up a new environment, I just clone the repo and run docker compose up.

Why Portainer?

I like to pair this Git-based workflow with Portainer because it gives me a simple, intuitive UI on top of my Docker environment. While Docker Compose keeps everything version-controlled and scriptable, Portainer ties it together with a dashboard that shows all my containers, volumes, networks, and logs in one place.

It even has built-in GitOps-style features, like pulling changes directly every so often from your repo or using webhooks, so you can keep everything updated automatically. That means I don’t have to drop into the CLI just to check container statuses or tweak settings. I can do it all from my browser.

If you know of any other tools that offer a similar UI-driven approach and integrate well with GitOps, let me know! I’m always on the lookout for alternatives.

Why not LXC?

While LXC can be more lightweight and can potentially yield better performance, it’s just trickier to replicate consistently. If you know a way to make LXC more reproducible, I’d love to hear it! Hit me up on Twitter.

Also, hooking up NFS inside an LXC can get messy with permission issues and restricted container access.

With Docker Compose, I can easily map volumes from my NAS (especially the config volumes) and keep the setup modular.

Coming Up Next

This was just the general overview. In future posts, I’ll dive deeper into specifics like:

UDM Pro VLAN Bridging: Exactly how I got ZeroTier VLAN 2 and VLAN 3 to mesh with the UDM and hacking the UDM’s persistence system.
GPU Passthrough Step-by-Step: The commands and configurations I used in Proxmox.
Arr Services and Hardlink Magic: A deeper guide on making *Arr apps handle hardlinks smoothly.
Nginx Proxy Manager + Authentik: How I secure external services while letting them stay easy to reach from anywhere.
ZeroTier: More on how I set up ZeroTier.
GitOps: How I manage my Docker Compose files and volumes with Git.
Monitoring & Alerts: How I keep an eye on everything through Grafana, Alloy, and other tools.

Wrapping Up

So, that’s the broad overview of my Planetary Datacenter, my homelab that thinks it can conquer the world (or at least my corner of it).

As I keep iterating on this setup, I’ll share everything I learn, mistakes, discoveries, and hopefully some cool tips. If you have any questions or want to suggest your own improvements, drop a comment (or tweet, or smoke signal, whichever you prefer). I’d love to hear how you’re tackling similar homelab challenges.

Stay tuned for more detailed breakdowns, and thanks for reading!

Service-Oriented Architecture with tRPC

Thu, 12 Dec 2024 00:00:00 GMT

An exploration of how to implement service-oriented architectures using tRPC to create typed and efficient APIs between client and server.

Multi-Cloud Architecture with Wireguard and ZeroTier

Thu, 14 Nov 2024 00:00:00 GMT

A talk on the CNCF, Cloud Native Computing Foundation about how to use Wireguard and ZeroTier to create multi-cloud networks.

My Obsidian workflow

Sat, 20 Apr 2024 00:00:00 GMT

Obsidian has changed my workflow dramatically over the past year, I'm going to share with you today, how and why I'm committed to using it, hopefully, for ages.

Have you tried Obsidian or any other note-taking tools? What setups have worked best for you? Hit me up on Twitter with your thoughts, I'd love to hear them.

The Trigger for Change

I am a tech enthusiast, I'm constantly on the lookout for the latest advancements in technology. Every day brings a flood of new information, and honestly, it's more than I can handle sometimes.

For years, I've been scrolling through Twitter, Youtube, HackerNews, ByteByteGo, and more. Add to that the roster of tech content creators, shoutout to Theo, Primeagen, Melkey, Dreams of Code, CodeAesthetic and many more.

It's overwhelming. Cool, but overwhelming.

I've got stuff to do and this chaos is killing my focus.

So, after many discussions with my good friend Oriol, about a year ago, I decided to take control and start my own digital notebook.

Initially, I went with Notion, as it was familiar and somewhat effective, but it lacked certain features, also, it is often lagged, which was frustrating. Then, an idea struck. I remembered Obsidian a tool that had been on my radar for a while. It was appealing, especially the idea of owning my files as plain markdown. Despite the learning curve looks complicated, I decided to dive in and see what I could make of it.

My files were a mess, scattered across folders with random nesting, creating chaos in the root of my vault. The plugin system kinda helped in some cases, there are a few plugins we can talk about later that has helped me organize my stuff. but there is one in particular that I want to talk about. There is a few tools I use on a daily basis that are crucial to me, one of which is Excalidraw, there is a community plugin that integrates it directly into Obsidian, saving money and keeping everything local. Game changer, I thought.

This last bit is more important than it seems, thanks to said plugin I got to discover Zsolt.

Developing a Personal Knowledge Management System

Zsolt is the brains behind the Obsidian Excalidraw plugin and a creator of content on YouTube focused on Personal Knowledge Managers (PKM). His channel was a goldmine, exactly what I needed to see.

Inspired by several videos and the broader PKM community, I've built my own kind of management system. Here’s what I came up with;

Detailed Breakdown of Note Types

My workflow consists of three parts: how I write notes, where I save them, and the habits I've cultivated.

Manual Notes: Like this very article. Each note includes metadata like timestamps and tags to keep my graph organized and sometimes, more specific metadata for particular cases.
Clippings: The bulk of my vault. Remember the daily info madness? It’s manageable now, thanks to the 'Obsidian clipper' a plugin I developed (find it on my GitHub!). It captures full page metadata, creating detailed notes that help me recall and review later. It's a bit lacking still, I kinda need to update it.
Habits: Here’s where it gets a bit wild. Monday through Friday, my vault is a chaotic mess—notes everywhere, no real order. Come the weekend, I sort through the week's accumulation, organizing and refining as I go.

Exploring the Folder Structure

For my folder, I use a hybrid system inspired by PARA and Zettelkasten, to fit my style.

0. Maps: This is essentially the dashboard of my vault. It's where I visualize analytics and other overview elements of my note collection. Although it's still fairly poor, since I don't have many notes made here yet.
1. Projects: Here, projects are just projects; they're ideas and initiatives I'm actively working on or planning. I prefer to keep individual notes rather than folders here to maintain simplicity.
2. Areas: This section is to store different types of notes that need to be isolated from the general pool. For example, I keep all the architecture documents and diagrams for Nexiona, my current employer, here.
3. Resources: This folder is like my second brain, really. Here I drop everything I find interesting every day, most of my notes lie in here and they're structured in many different folders; Tweets, books, articles, webpages, OSS tools, videogames, videos, tools, slides, prompts, manuals, documents… The list goes on.
4. Permanent: To me, permanent notes are a kind of note that are meant to be hydrated from time to time yet do never die. Here lies for example my 'people' folder where I a list of the people I know and care about. Some meeting notes that I think need to be saved, or some diagrams that I find relevant to keep in hand.
5. Fleeting: As the name suggests, this folder is for ephemeral notes that are relevant only for a short period. These include brief ideas, temporary observations, and initial thoughts that either evolve into more substantial notes or get discarded.
6. Daily: My daily notes, split into two main parts: general notes and to-dos. Each day gets its own note, each one has relevant stuff I've done on the day and a to-do list that rolls over to the next day, thanks to a handy plugin.
7. Archives: This is where notes go to retire. It mirrors the main structure almost completely but is reserved for notes that are no longer active or relevant.
8. Meta: This folder is a bit of a backstage area. It houses templates and static elements like images that I embed in other notes.

My Plugin Ecosystem

I don't particularly use a large number of plugins, but there are a few that I consider crucial:

Excalidraw: Very self-explanatory. It allows me to embed Excalidraw diagrams into Obsidian and save them locally.
Advanced Slides: This plugin is essential for my presentations, as I create my slides in Markdown using Obsidian. It significantly enhances the experience.
Dataview: One of the major plugins in Obsidian, Dataview enables SQL-like queries on your notes to display them in tables or various formats.
Homepage: It simply displays my graph automatically if I close all tabs.
Day Planner: This plugin integrates directly with my various calendars, allowing me to view all my work events in one place.
Iconize: Adds icons to your folders (yes, I still need to add them, lol).
Omnisearch: An important tool, Omnisearch is a fuzzy finder for Obsidian, enhancing the search functionality to better locate notes.
Rollover Daily Todos: As mentioned earlier, this plugin automates the transfer of my todos to the next day's note.
Templater: Enhanced templates !.
Tag Wrangler: I use this to better organize my tags, which I tend to repeat too often.
Style Settings: Allows me to apply the Vesper color scheme to Obsidian.

Additionally, I am currently using the Minimal theme.

Conclusion

I've been talking about Obsidian for a while to some friends, and I've told them many times I'd like to share this in an Obsidian Post. So here it is. Hope you enjoyed.

Effect: TypeScript for Production

Tue, 09 Apr 2024 00:00:00 GMT

Effect is a powerful TypeScript library designed to help developers easily create complex, synchronous and asynchronous programs.

Reflections on a Github Contribution Graph

Sat, 17 Jun 2023 00:00:00 GMT

Ever been on a roller coaster that just doesn't seem to stop? Yeah, that's been my life lately.

Take a peek at my Github contribution graph and you'll find a barren landscape. My once somewhat vibrant field of green squares, each marking a day of my life dedicated to coding, is now just a digital ghost town.

Why the sudden change in scenery, you ask? Life happened. And not just the usual life-stuff, but a gigantic, heaping helping of it. I'm talking about the kind of work that makes your plate look like a Thanksgiving dinner for giants.

Here's the deal. I’ve been diving headfirst into a sea of projects that have stretched me to my limits. The responsibilities have been numerous, the deadlines merciless, and there's a whole battalion of folks counting on me to do my bit so they can do theirs.

On top of that, there's the silent weight of my own ambition. I'm not just in this for the thrill of the game. I've set my sights on loftier goals. I'm aiming to climb the career ladder, not just for the view from the top, but to hoist my team and my company up there with me. I'm striving to mold my colleagues into better engineers, support my company's rise to the top, and carve out a niche in the tech world where we can proudly stake our claim.

But, with everything spinning around me like a tornado of responsibilities, something had to give. And looking at my desolate Github graph, it’s clear what took the hit.

It's not a sight for sore eyes, but it's the wake-up call I needed. Looking at my barren field was like catching my reflection and not recognizing the person staring back. It was a reality check that I had been so swept up in the hurricane of work that I’d lost touch with a vital part of myself.

But here's the thing: I’m not about to let the story end here. This isn't a tale of defeat, but a call to action.

Lost and Found: My Love for Open Sourcing

Picture this: You're standing in a room filled with tech maestros. The air is buzzing with energy, ideas are whizzing around, and the sheer talent in the room is nothing short of jaw-dropping.

But let's rewind a bit, to a time when my enthusiasm for open sourcing was running on fumes. Why, you ask? Two words: impostor syndrome. Yeah, that sneaky little voice that whispers, "You don't belong here" every time you’re in the presence of super talented colleagues. When you're navigating the vast tech sea, it's easy to feel like a tiny fish, completely out of your depth. And let me tell you, it's a crummy feeling.

Now, fast forward to JSDay at Canarias. You might have heard of it - it's only one of the coolest tech conferences out there! But for me, this wasn’t just a conference. It was the life-raft that pulled me out of my self-doubt and put the wind back in my open sourcing sails.

Why? Because I had the chance to rub shoulders with some of the biggest names in the industry. I'm talking about the likes of Kent, Tejas, Aleksandra, Sandrina, and my T3 community buddy, Stoyko. Just being in their presence was like mainlining a hefty dose of motivation.

Their passion, their creativity, their drive, it was all so contagious. It was as if they reached into me and reignited the dormant flame of my love for open sourcing. I saw in them a reflection of who I used to be and who I knew I could be again.

So this post? Consider it a massive shout-out to this stellar gang. A heartfelt thanks for being my guiding light in the foggy sea of self-doubt. Their brilliance not only lit up the path but also sparked a fire within me, reminding me of my love for open sourcing and why I chose this path in the first place.

The Comeback Plan

Alright, let's switch gears and talk about my life calendar from WaitButWhy.

To some, it might seem a bit grim. Imagine a calendar filled with tiny boxes for each week of your entire life. It’s like a visual timeline from your birth date to... well, let's just say a very, very long time from now. Some of my friends look at it and get cold sweats. But for me, it's more like a treasure map.

Yeah, seeing your whole life laid out might freak some folks out. But me? I see stories. Each little box is a week of wins, losses, lessons, and adventures. It's like a diary, but instead of "Dear Diary" entries, there are tick marks for every week I've lived.

For me, it's not a countdown to doom. It's a progress bar. It's a tool that shows me where I've been and where I'm going. When I hit a slump, like these past two months, it's a kick in the pants. It's a wake-up call saying, "Hey, get back in the game and back to work!"

So yeah, my life calendar isn’t a ticking time bomb of anxiety for me. It’s more like a coach, a cheerleader, and a reality check all rolled into one. It keeps me focused, driven, and excited for what's coming next.

Laying Out the Strategy

Shifting focus to my action plan, the first item on the agenda is: it's time to get all my tasks in order. To help me do this, I'll be leveraging a to-do list app. It's a powerful tool that can instantly help me get a grip on my daily responsibilities, allowing me to jot down every task, big or small, and arrange them based on their priority.

It may seem rudimentary, but it's a game changer. By having everything written down and easily accessible, I can alleviate the mental load, reduce stress, and keep my workflow moving seamlessly.

Next up, I'm reigniting my passion for personal projects. In the past, they've been subjected to an endless cycle of idea generation, scribbles, and half-hearted beginnings, without ever reaching the finish line. This ends now. It's time for each project to move beyond the "just started" phase and come into its own. I'll be fully committing to each initiative, treating them with the seriousness they deserve, and seeing them through from inception to completion, no matter the hurdles along the way.

Lastly, I'm also carving out time for personal development. I'm going to dedicate a portion of my day to reading, specifically books that can help me expand my knowledge and better understand my field. Currently, I have "The Personal MBA" by Josh Kaufman and "Staff Engineering" on my reading list.

A final message

To everyone reading this who might be feeling overwhelmed, stuck, or just looking for a way to regain control over their life and work:

Remember, you're not alone.

We all hit bumps in the road, face times when our passion falters, and find our task lists spiraling out of control. But, there are tools, procedures and strategies we can use to reclaim our lives and reignite our passions.

The journey of getting our tasks in order, reigniting our passions, and striking that elusive work-life balance starts with a single step. Start small, perhaps by writing down your tasks in a tool like Microsoft To Do or setting aside time to read each day. The important thing is to take that first step, and before you know it, you'll be well on your way to getting things done and finding fulfillment in your work again.

Remember, life is filled with ups and downs, and it's okay to falter. It's the getting back up that truly counts.

So, let's get back up, together. Let's get started, and let's get things done.

Embracing the New World Order of Server Components

Sat, 25 Mar 2023 00:00:00 GMT

Web development is a rapidly changing field, with new technologies and frameworks being introduced all the time. It can be challenging to keep up with the latest trends and best practices, but attending events like the recent discussion with Dan Abramov, Ryan Carniato, Sophie Alpert, and others can provide valuable insights into the latest developments.

As someone who contributes to OSS, I found the discussion to be particularly interesting and informative.

From the power of stateless React components to competing patterns and the future of web development, there were many fascinating topics covered. The React team's delicate balance was also discussed as well as the challenges of teaching server components and the future of them.

The discussion was a pleasure to be a part of, and the collaboration between Dan and Ryan was inspiring. Regardless of whether you're a React user or not, the developments in the world of React Server Components and Astro components are worth taking note of, as they will undoubtedly shape the future of web development.

In fact, I have compiled a list of my top takeaways from the event.

The Power of Stateless React Components

Stateless components are those that do not manage their own state and instead rely on receiving data through props from parent components. These components can be utilized in server components, running on the server, or imported into client components to run on the client-side. This versatile authoring experience, referred to as "knitting" by Dan, allows for smooth code movement across different boundaries.

Both RSCs and Astro components adopt a server-only mental model, which enables the usage of "top-level await" for data fetching on the server side with Astro, and an async function as a React Server Component.The fetched data can be utilized in two different ways, depending on the situation. First, it can be directly serialized and passed to client components as props, integrating data fetching within the component tree itself. This allows for seamless data management within your application.

Alternatively, you can also choose to render a server component directly, which will send HTML to the browser with the data already incorporated. This method is particularly useful when you want to optimize performance and reduce the amount of JavaScript sent to the client, as the server takes care of rendering the component with the fetched data.

To clarify, a stateless component:

Does not manage its own state.
Relies on receiving data through props from parent components.
Can be used in server components or imported into client components.

Competing Patterns and the Future of Web Development

Although RSCs are becoming increasingly popular, the loader/action pattern, championed by Remix Run, SvelteKit, and SolidStart, still has a prominent place in web development. This is because the loader/action pattern has been around for longer and has a proven track record of success.

It is worth noting that just as JSX couldn't completely replace other templating languages, RSCs will not fully replace the loader/action pattern. While RSCs offer many benefits such as seamless code movement across boundaries and support for top-level await for data fetching on the server, the loader/action pattern provides developers with greater control over data fetching and caching in their applications.

Loaders are responsible for fetching data and preparing it for the components, while actions handle client-side logic, such as user interactions and updating data. This separation of concerns enables more precise control over how data is fetched, manipulated, and cached, allowing for better optimization and customization.

For a deeper understanding of the loader/action pattern, you can refer to the following resources:

Remix Run Documentation
SvelteKit Load Function & SvelteKit Actions
Solid Start Data Fetching & Solid Start Actions

React Server Components and the RSC Protocol

The RSC protocol enables the server to expose a special endpoint that clients can use to request a part of the component tree. The server then generates, serializes, and sends the requested part back to the client. This process allows for a SPA-like routing experience within an MPA-like architecture.

In other words, you can create a fast MPA that feels like an SPA because you don't need to send a large amount of JavaScript code all the time, and you can also navigate without a full page reload. This approach combines the best of both worlds, offering the smooth navigation of an SPA while maintaining the performance and efficiency of an MPA.

The React Team's Delicate Balance

The React team, like any team in charge of a popular software library, must carefully balance their desire to excite their audience with new features with the need to deliver a reliable and consistent product.

On one hand, early promotion of new features can generate buzz and excitement, and can help the team get feedback and improve the product. However, the team must also take into account the risk of changing the implementation later, which can cause confusion and frustration among users who were expecting a different behavior.

On the other hand, waiting for a more confident delivery can help ensure that the product is stable and consistent. However, this can also lead to a lack of excitement and engagement from the community, which can make it harder to get feedback and improve the product.

The React team must carefully weigh these considerations and find a balance that works for them and their users. This delicate balance requires skill, experience, and a deep understanding of both the technical and social aspects of software development.

Teaching Server Components

The most natural approach to teaching server components is to introduce them first, just as Astro components are taught before client-side interactivity. By starting with the basics of server components, students can gain a solid understanding of the underlying principles and architecture before diving into more complex topics.

There's an alternate history where React started as a server-side component framework and only later added client-side functionality. In this alternate scenario, developers would have a more balanced understanding of both server-side and client-side components from the beginning, making it easier to grasp the full potential of the React ecosystem. But unfortunately that isn't the case.

React Ecosystem and Suspense

React's implementation of Suspense and related features (transition, use) came later in the development process, which led to some popular libraries not initially adopting Suspense. This happened because the React team was focused on other areas of the library during the early stages of development. While this approach allowed the team to build a strong foundation for React, it also meant that routers and data fetching solutions weren't built on top of these primitives.

This left the ecosystem in a tricky spot compared to Solid, a similar library, where everyone built on top of Suspense from the beginning. Therefore, React developers had to find workarounds and alternative solutions to achieve similar functionality. Popular libraries that emerged as a result include React Query, which Suspense support is currently experimental, SWR, another library for data fetching and caching without Suspense, and Apollo Client, a state management library for React applications using GraphQL that also has Suspense in an experimental alpha.

As React continues to evolve and Suspense becomes more widely adopted, it is possible that these libraries may integrate Suspense in the future or that new libraries built on top of Suspense will emerge.

The Future of React Server Components

React Server Components are a hot topic among developers at the moment. Although there are some challenges that the React team is currently facing, such as the potential for slow server rendering times and the need for frameworks to implement the new features, there is a lot of excitement around what this technology can do for the future of web development.

While there is still some uncertainty around how widely these new features will be adopted, the React team remains optimistic. As more developers begin to experiment with them and explore their capabilities, it is likely that we will see more widespread adoption in the community. Overall, the future of React Server Components looks bright, and we can't wait to see what developers will create with this exciting new technology.

References & Credits

Huge thanks to the following people for proofreading the article and giving new ideas.

Chris
Nexxel

Vue Covid

Sat, 19 Jun 2021 00:00:00 GMT

Recently on my crusade of learning new stuff I've been reading through a lot of jobs around my local city and nearby. And realized that most of the open offers have a few things in common.

Either A: They have some kind of stack hugely related to PHP and Java.

Or B: They're about Angular or... surprisingly, Vue.

Hey, don't get me wrong, Vue is pretty cool I quite like it in fact, it does things differently and, unlike its other two massive pals, Angular and React, it's community-driven which makes it even cooler.

I've never really done anything with it besides practice and check out and how it works. The last time I did that was back when v3 was still in development, when I heard they went live a few months ago, I wanted to give it a try, that's how this app was born.

It's not much of a thing, quite something you could make in an afternoon with little to no effort, but it served me quite well to check out most of the new features v3 adds. Most of them did not make it through to the end, again, it's a really simple app, but you know, it ended up quite nicely. The API is pretty cool as well, it's available at here if you wanna check it out.

Instagram Clone

Thu, 22 Apr 2021 00:00:00 GMT

This is my second clone of a famous platform. First i started with my Netflix clone and now an Instagram clone.

The sole purpose for me to make these clones is to learn how to manage a page that is commonly used in production-ready environments, and since I use Instagram quite a bit, I decided to try to replicate it.

Since I wanted the project to be as straight-forward as possible I decided to use React with create-react-app (CRA). I'm quite used to work with it and it seemed like a good option to build and learn new things on the way.

Later on, I realised that Vite 2.0 got released and thought about migrating to it, it did not happen at the end because the project was already sort of half-made already and I was honestly too lazy to move everything.

I quite recommend you give it a look next time you want to start a new React project, it really is blazing fast.

Talking about technologies used, one of the reasons that this project was used for is an excuse to learn TailwindCSS since it's on everyone talks lately. Tailwind is a CSS framework based on classes. Working with it has been cool, it makes development quite easy, although if I had to say something about it, is that it really makes code a lot less legible and quite chaotic at some point.

This time I have used Firebase again, just like in the Netflix clone, it just makes thing way easier for me, though, this time I decided to use more than what it offers, and not only do I use auth but also decided to upload data referring to followers to Firestore. Although this might be one of the last projects I use it. Don't take me wrong, Firebase is great, but lately I want to use my own data layer built on other DBs and with other approaches.

Another reason that I took a project like this one is to put to practice my knowledge on testing libraries. On my other clone I just used testing-library and called it a day, they were not really complex tests or really useful at all, so I decided to make something different on this project.

This time I used a classic approach of testing-library + Jest and end-to-end testing with Cypress.

This project has been quite a lot of fun. From managing the comments and the auth with Firebase to testing everything is running smoothly on any case as well as making the entire page as responsive as possible. This would probably be my last clone for a while, since I want to focus on making something different from the usual as a way to push myself further of my comfort zone as well as practicing other topics of project management.

Thanks for the read and hope you have a good day :).

Hello World

Wed, 14 Apr 2021 00:00:00 GMT

Here I am. Pretty much my very first post so nothing to see here.

for now.

Netflix Clone

Fri, 16 Oct 2020 00:00:00 GMT

This is essentially a clone of the famous streaming platform Netflix, but built my way. I decided to get more comfortable with React building a quite complicated at the time project. The idea was simple. I wanted to copy a famous streaming platform design and logic but with my own stack. The whole front-end is managed with a React app and the backend is a very basic Firebase setup with auth enabled.

The app consists of a main page, login and signup pages, and a browse page where you can see a few of stock shows gave to the app.

At the time when I built it I was planning on just making the “visible” part of it, but it ended up taking more than that. The auth part was probably the most tedious. Although it uses Firebase and it’s quite easy to setup I had never done anything like it and was quite an experience.

For the whole communication it was a really nice practice for the useContext hook. Pretty much the whole app is managed through it and gave me a really good glimpse of where and when is a nice idea to use it.

Talking about hooks I also made my owns with this project! The hooks I’m talking about is the useContent and useAuthListener. Both made for the Firebase provider to be a little easier to work with and to access the localStorage for the auth sessions.

Design-wise I tried to make the app as close as the original as possible, I believe I made a really accurate clone of it, the part where I struggled the most is the browse page where the shows are displayed once you log in. It’s not as accurate as I’d like to, but I believe it turned out nicely. On the other hand, the video player ended up being quite complicated, understandably, since it’s the key to the service, so I just made it play a stock video and called it a day.

I also got to know styled-components, which is the styling library used for the whole app. Pretty much my go-to library since then, I love it, works flawlessly and it puts you in control at the same time as give you a good way to structure your components.

nst.sh

Mon, 05 Oct 2020 00:00:00 GMT

Time ago, I was in a party with some friends. I told one of them about one of my apps that I had hosted at the time, nothing really big or fancy, but something I wanted to show him.

At that moment I asked him to get his phone and type out the IP and port where I had it on my VPS, and then, I realised that it was awfully inconvenient to host my apps that way. That's a turning point when I decided to actually host all my apps in subdomains like I do right now. But even then, once again, it was somehow inconvenient to just give someone a long URL to type. That's where this project came in mind.

I found that this domain name was untaken and it really fitted my idea.

Something you can type quick to led you somewhere else.

And so I decided to invest into finding out how URL shorteners worked and how to host a proper database for it. Ended up quite nicely and it's something I use frequently.

It's made with Express attached to a MongoDB and Vue as a fronted. It will probably be remade not long from now since it need to be improved. I will change this when it's done.

Demon Harem

Mon, 14 Sep 2020 00:00:00 GMT

This project was pretty much born as an excuse for practicing my knowledge on basic HTML + Vanilla JS. It ended up quite nicely I'd say.

I decided to make it based on Helltaker, which is a free game that came up recently that people really liked it, if you want to give it a try it's free on Steam.

The project was heavily inspired by Satania.moe, since it has such a wonderful boilerplate and design for the page I wanted to make. Props to Pizzacus.

Score Analyzer

Wed, 29 Jul 2020 00:00:00 GMT

Although very simple I found nobody had made anything like this before.

In this game people keep track of huge scores of 100+ people MANUALLY to excel pages and other sheets. So I decided to make this app to make their life easier.

Functionally is very basic, just takes a screenshot from one of the scores and Tesseract OCR them into a pdf file so you can actually copy paste its data to anywhere else.

GitHunter

Thu, 09 Jul 2020 00:00:00 GMT

This was pretty much on of my very early projects. In fact, it was partially broken until not long ago, when I asked a friend to help me out fix it. It came out nicely in fact, there’s a few things that could be improved, like the way sorting works and the actual display and organisation of the different lists. But if it works it works.

The project uses React, ChakraUI, a really clean component library and use-http, a hooks-based fetch library for isomorphic http requests.

The idea for the project came from a Youtube video from Kamran Ahmed, with a few aditions made by my side. Which in my opinion has one of the best roadmaps for every developer there is, you can check that roadmap here if you want.

Yet another React Todo List

Tue, 03 Sep 2019 00:00:00 GMT

Pretty much one of my very early projects with React, just a simple Todo list with categories.

When I built it back in the day I decided it would be way better to have something different that every other tutorial around, so I invested some time on looking how exactly localStorage worked on the browser, and at the end, decided to store the Todos that way.

GameBoy Zero

Tue, 09 Apr 2019 00:00:00 GMT

I made this project around 2016. it's basically a fully capable Raspberry Pi Zero made to play games on Retropie, it features 3 USB A ports (1 outside, 2 inside) and a direct connection to the Pi in case you want to run it to a screen to play with a controller instead of the built-in screen.

As an addon it has the SD card slot lined to the only cartridge reader of the original Game Boy, so if you like you can route a SD Card directly inside a Cartridge and use it to make it more aesthetic.

It also have a 3DS Stick in the middle of the case, so you can play different games that requires one.