This commit is contained in:
Atridad Lahiji
2023-05-18 20:04:55 -06:00
committed by Atridad Lahiji
parent 84591f3a2d
commit 3d719132f1
96 changed files with 3422 additions and 4793 deletions

View File

@ -0,0 +1,18 @@
---
name: "Thoughts on Cognitive Load and Programming Language Syntax"
date: "February 07 2024"
tags: ["article","thoughts"]
---
Recently, I started to pick up a new language in my spare time: Go. Was it partially influenced by the surge in HTMX popularity and how often Go is used alongside it? Almost certainly. But at some point along this journey, I noticed something: This is _so_ much more fun and _so_ much less draining. This whole post won't be me gushing about how much I love Go as a language, not directly. I started to notice a few things...
# Oh, what fun...
I come from the JavaScript and TypeScript world with frameworks like Remix and Next.js. And the DX (Developer Experience) for these is lovely! For reasons I could not quite pin down, I was having much more fun with Go + HTMX despite the hacks to get close to the same DX. It came down to how darn easily I could pull off things I had previously relied on services for. Need a message queue to run on the edge? Easy, write a wrapper over Redis to use its PubSub. Need real-time updates to the UI? No problem, write a basic Server-Sent Events system with subscriptions and channels. Anything I wanted, I could build. That, and the way concurrency _"just works"_, and I could make anything I wanted happen. This brings a level of satisfaction that is hard to convey in an article.
# What changed?
So this isn't meant to be a post to bash JavaScript, as much as I do have my reservations about the language. That being said, JS makes basic things like concurrency an afterthought. Go's lightweight threads, called goroutines, make it easy to write concurrent programs without worrying about the overhead of heavyweight threads. Even better, Go has channels that provide a simple and effective way of synchronizing communication between goroutines, making it easier to write concurrent programs free from race conditions. Similar concepts are present in Java, Rust (Tokio), C#, etc. Even better, error handling! Now, this is controversial, but forcing errors to be valued and allowing functions to assert that there _may_ be errors is a game changer for writing safer code. All of this amounts to a much lower cognitive load. I am less worried that my code is inefficient, error-prone, etc. I can just _write_.
# What does this mean?
As a field, we can and should investigate and identify key points in programming languages that increase or decrease the mental load or overhead for developers. Imagine if we could identify these points and work to reduce the overhead. This has been on my mind as I reflect on my experience learning Go. I want to dive deeper into the details of what we can do to reduce this overhead and get back to writing good software without unnecessary restrictions.
# Thanks!
Do you have any thoughts on this? Do you want to have a chat about the topic? Feel free to reach out by email at [me@atri.dad](mailto:me@atri.dad). Until next time! 🫡

6
content/contentfs.go Normal file
View File

@ -0,0 +1,6 @@
package contentfs
import "embed"
//go:embed *
var FS embed.FS

78
content/goth-stack.md Normal file
View File

@ -0,0 +1,78 @@
---
name: "Introducing the GOTH Stack"
date: "January 08 2024"
tags: ["article","golang"]
---
# Enter the GOTH Stack!
The GOTH stack is something I've been trying to get to for a while now. It's not a specific repository with a fancy command that can scaffold a project for you. It's more like a set of pillars for building excellent, pleasant, full-stack web applications.
# The first pillar: Go
Go is something I learned to love later on in my career. I was mainly writing JavaScript, building on serverless platforms and growing frustrated at the performance and limitations. Go changed all of that.
What makes Go good?:
- Static types
- Incredibly easy concurrency
- Errors as values
- Incredible runtime and build time performance
- Tiny memory footprint
The tl;dr is that it is challenging to write Go code that is _not_ performant.
# The second pillar: Templates... well... Go templates
Go templates surprised me, to be completely honest. They offer just enough to get me going and perform exceptionally well. Sure, it's not as simple as a basic JSX file in Next.js since you need to make a route handler, but it works pretty well and supports basic control flow. I am interested in looking into alternatives such as TEMPL (which reads much like JSX for Go), but I need to find a real reason to move from the standard library here.
Here is an example of a route handler passing a slice over to a template for rendering:
```go
package pages
import (
"HTML/template"
"github.com/labstack/echo/v4"
"goth.stack/lib"
)
type HomeProps struct {
Socials []lib.IconLink
Tech []lib.IconLink
ContractLink string
ResumeURL string
SupportLink string
}
func Home(c echo.Context) error {
socials := []lib.IconLink{
{
Name: "Email",
Href: "mailto:example@site.com",
Icon: template.HTML(`<svg xmlns="http://www.w3.org/2000/svg" height="32" width="32" viewBox="0 0 512 512"><!--!Font Awesome Free 6.5.1 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license/free Copyright 2023 Fonticons, Inc.--><path d="M48 64C21.5 64 0 85.5 0 112c0 15.1 7.1 29.3 19.2 38.4L236.8 313.6c11.4 8.5 27 8.5 38.4 0L492.8 150.4c12.1-9.1 19.2-23.3 19.2-38.4c0-26.5-21.5-48-48-48H48zM0 176V384c0 35.3 28.7 64 64 64H448c35.3 0 64-28.7 64-64V176L294.4 339.2c-22.8 17.1-54 17.1-76.8 0L0 176z"/></svg>`),
},
}
props := HomeProps{
Socials: socials,
Tech: tech,
ContractLink: "mailto:example@site.com",
ResumeURL: "https://srv.goth.stack/Atridad_Lahiji_Resume.pdf",
SupportLink: "https://donate.stripe.com/8wMeVF25c78L0V2288",
}
// Specify the partials used by this page
partials := []string{"header", "navitems"}
// Render the template
return lib.RenderTemplate(c.Response().Writer, "base", partials, props)
}
```
As you can see, it really isn't that bad! It also comes with many of the benefits of Go and the flexibility of components!
# The third pillar: HTMX
So, up to this point, you may have been thinking: "Gee Atri... you can't do anything reactive here". Before HTMX, you would have been right. HTMX offers a more backend-centric developer a way to build complex reactivity to their front end through basic templating languages. It is one file you import in your template, and it enables anything from basic HTML swapping to WebSocket and Server-Sent Event support. It is really, really powerful and worth looking at all together.
With Go managing route handlers and API routes, the template language running the UI, and HTMX governing interactivity on the front end, you can effectively write a fully dynamic full-stack application without writing a line of JavaScript code. It even runs quite a bit faster than some of the JS world's frameworks (Astro, for instance). It is actually what powers this site right now! The fundamentals are essential here and come together for a clean and enjoyable developer experience. I encourage everyone in the JS world to give it a shot! Perhaps it is not your thing, and that's okay! But you might also just fall in love with it!
# Giving It A Shot
I have a [repository](https://github.com/atridadl/goth.stack) as well as a [demo](https://goth-stack.fly.dev/) ready to go with everything you need to start!
# Thanks!
If you found this helpful, please let me know by email at [me@atri.dad](mailto:me@atri.dad). Until next time!

View File

@ -0,0 +1,28 @@
---
name: "Build Scalable Real-time Applications on Fly.io + Remix!"
date: "December 04 2023"
tags: ["remix.js", "fly.io", "article"]
---
# Scalability... what is it?
You often think of vertical scaling for something to scale, adding more resources to whatever issue you encounter (CPU, RAM, etc.). While this is the simplest way to scale an application or service, it can only get you so far. Horizontal scaling involves adding more machines or "nodes" running the same application. These nodes sit behind a load balancer responsible for directing client traffic to the appropriate machine to optimize load. This will work well if the application is meant to do simple CRUD operations for individual users. What if you need collaboration in real time? This complicates things...
# The real-time problem:
Real-time applications require a pub/sub or publish and subscribe model. A client will send a request to the application to perform an operation. Once done, the server will broadcast an event to all subscribing clients to trigger a re-fetch of data. In the case of a multi-node application, you need to use a service outside of your nodes to synchronize messages across all nodes.
# The stack:
For this stack, I chose Remix for its close adherence to web standards and easy support for server-sent events. These web socket connections work one way: from server to client. Next, we must synchronize all Server Sent events across different requests to a single node. For this, Node.js has its own Event Emitter API, which we can use. Now, we can use something like Redis and its Pub/Sub commands for multi-node setups to broadcast across nodes.
This is what it would look like:
![Diagram](https://fly.storage.tigris.dev/atridad/articles/scalability.png)
# How does it work?
Once a client connects to a page with real-time enabled, a persistent connection via EventStreams is made. The client would request to make a real-time update. Once the endpoint completes the request, it triggers a Node.js event, which the EventStreams endpoint listens to. Once received, the application sends an event down to the client via a server-sent event while also passing that request on to Redis pub/sub. Every node listens to this Redis event stream, so every node will receive the event and trigger the event using Node.js events, which then start server-sent events.
As you can see, there are many moving parts here, and it can get quite complicated. I have a repo called Atash, which acts as a template to get started. You can check it out [here](https://atash.atri.dad)!
If you found this helpful, please let me know by email at [me@atri.dad](mailto:me@atri.dad). Until next time!