Server or Serverless for a Go/TypeScript Backend? (& some TS vs Go Ranting)

Today's video is far less formal than most, I wanted to give my thoughts on the serverless vs server debate specifically in the context of TypeScript and Go. I think both patterns work well, and ultimately it comes down to the app. HOWEVER, I think TS favors Serverless and Go favors Servered.
This video is different from my normal stuff, let me know what you think! Regardless of if its positive or negative I want to hear it as its the only way I can make better stuff.
Twitter: / benjamin41902
Insiderviz: www.insiderviz...
#golang #typescript #servers

[@bmdavis419]

Would love you thoughts on this video, its different from what I usually do, more informal opinion based stuff. I'm not stopping with tutorials, breakdowns, guides, etc. but if you guys like this it would be a nice break for me to be able to make a rant or two like this a week.

[@bmdavis419]

@avfr yea I use it in prod with 20k+ users and 100s of concurrent requests, works like a charm. If you need http/2 and to use std lib then use something else, but if you want a fast easy to use framework I love Fiber

[@ayomidewilfred1864]

Thanks for this insight. I really learnt alot from typescript comparison with Go. Have been writing Golang couples of months now and I have really fall in love with that language. Can you make some videos on free hosting and deployment for Go application, and probably be specific about the Go framework you will use . Kudos🎉

[@andsribeiro]

Bro, I'm just thinking about building my first serious project, and all of you latest videos are so in touch with the doubts and questions that arise to a junior dev. Thank you a lot, i'm learning so much from these videos, please keep it up. The way you present information is super concise and educating. Subbed, and hope you get to 100k soon. 🙏

[@bmdavis419]

Good luck!

[@na3aga]

You are so often saying about the GO performance, so it sounds like for bigger applications it is the better choice, and I want to put my opinion on that. 1. In reality, NodeJS under the hood is very performant, ublocking I/O lets you write async code that will handle millions of requests, without thinking about concurrency. And once you design the code to run in a single thread manner with async, you can scale it by deploying multiple Node.js threads, workers, servers, etc, and balancing traffic to them. This design is closer to serverless in terms of every request being run as an isolated script (And if you design for serverless, you can migrate later if it is more efficient or cheaper for you). But it can become more like a big monorepo with many frameworks like Nest, which is again a good tool but maybe at some point you should consider moving to GO, or .NET, or another, and split your server into services. 2. While GO is even more performant, you should use concurrency and design with it to achieve useful benefits, which will impact you a lot on your design decisions, even though it is the more traditional approach for web servers. You should always choose what you like more, what is more, beneficial to your stack, and efficient to build with, and think not only about the cost per request of the small server but the cost of time and cost of the scale of the product., each choice gives benefits.

[@themarksmith]

I've got some catching up to do with watching your videos, but trust me, I will be watching each and every one of them!

[@ryszardmatula5821]

I’m so happy that I found this channel. Please keep up the good work 👏

[@rin_08]

Dang, 2k already keep it up!

[@salvaje1]

I am making a small passion project app and I am almost done with the frontend. Usually I begin with the backend and then tack on the frontend, but this time I decided to learn Vue, so I did it the other way around. I have been debating on which backend technologies to use and whether I want it to be serverless or not. At least this video made Go an option in my head. I never thought of Go as a backend language, tbh I didn't even know what exactly it's use case was.

[@tzuilee588]

Yo the new background looks great😁

[@bmdavis419]

It beats the bed lol, gonna play with it more try and make it as nice as possible

[@fueledbycoffee583]

I will put my 2 cents here. I am highly biased to server-less because they are ALOT easier to mantain and bring people in to do work on code deployed there. Mostly because configs of the serverless are pretty straight forward and usually just involve a simple YAML/JSON/TOML or in platform config that doesnt touch the code. Even our databases are serverless. We use Mongo Atlas and Rockset DB cloud solutions. A good example of why we prefer S-less over self managed a side project we are handling for a client of us that is Lottery that wants to integrate other gambling game sinto their system. The thing is that all their infra is self managed in azure vms over multiple k8 pods. They have over 110 different APIS (this is litteraly) and this was done by contract developers, so now that they are gone nobody knows how each linux server is configed and how the pipeline is set up. Also they use multiple MySQL DBs each hosted in a different VM whith a different config and permissions. So yeah, that...The worst part is more about the tons of documentation that self hosting needs to make sure anybody can come and work on your system while S-less lets you focus more on the code you are writting and less in how you will make it fit in the current infrastructure and if the config you already have support it thats why i hate K8, and self managed VM's. Unless they are strictly necessary (custom compute works that need a persisten environment/OS) i tend to steer away from them. All tho, the downside is that is that most of the time, serverless solutions tend to balloon in price compared to self managed VMs

[@OldKing11100]

I'm leaning towards your direction also. My stack looks like SvelteKit (Serverless) + FastAPI (Server) + Redis or PostgreSQL (No ORM server). The problem is of course FastAPI being python which is going to be slower and more intensive than compiled languages. My biggest struggle is picking a language that can either work with or act as replacement for FastAPI which has been narrowed down to either Go or Rust. My list for learning one has me on the ropes for which language I want to learn. Rust: Tauri (SvelteKit support), NGINX Unit Unofficial binding, Web last, syntax is harder, Python PyO3 binding. Go: Wails (No SvelteKit support), NGINX Unit Official binding, Web first, syntax is easier, no such python binding?. Your videos and Primeagen are helping me figure this out, but ultimately I think it's going to come down to making a couple applications side by side.

[@perc-ai]

Our company has moved exclusively to Rust, we used to have several microservices but now we are a monolith as a result of Rust's speed and memory safety

[@perc-ai]

we used Go in the past, love the simplicity but if you are in the game for the long run Rust is the language you want to invest in, you wont regret it. Ben is anti-rust because he is in startup hell where MVP and first-to-market is of the upmost importance

[@OldKing11100]

@@perc-ai That's a good point. I guess it doesn't hurt to try Rust first especially since I have downtime. WASM and Linux seem believe in it, but I honestly don't know if that means that much for its longevity. Thanks!

[@perc-ai]

@@OldKing11100 Honestly 2023 will be a huge year for Rust. Its truly revolutionizing alot of fields. WASM like you mentioned, Rust leads the forefront. For frontend Dioxus and Leptos are interesting are already one of the fastest web frameworks ever made. For backend Actix/Axum/Salvo/Hyper have no competition in benchmarks, You write once its all lightning fast and bug free. Tauri is already replacing Electron for desktop apps. Rust got introduced to the linux kernel recently like you mentioned.

[@bmdavis419]

Exactly, definitely gonna make a video clarifying this

[@lakshmitech4702]

Anyone want to know the difference between server and serverless here is explanation.love you Ben❤️.

[@chopfitzroy]

Solid video, good to see some education around this kind of stuff.

[@LoftwahTheBeatsmiff]

I got a lot of value out of this video thanks.

[@RemotHuman]

What's your opinion on OOP? A lot of webdevs seem to not like it.

[@bmdavis419]

I too am not really a fan, stuff like inheritance really just does not survive contact with the real world. Sure in a classroom its great, but in the real world? Not a fan personally

[@mr.random8447]

The glow effects are cool

[@synky9200]

There’s a reason why frameworks like Hyperledger Fabric (Permissioned blockchain framework) utilize writing business logic with Go. It is freaking fast

[@duartelucas5746]

Really like your videos!

[@gabefgonc]

Can you do a video about caching in a golang application? would be nice

[@everythinggoes850]

The magic behind aws lambda is micro vms. To be specific, Firecracker.

[@diogo405]

new background!

[@seanknowles9985]

I think Zig will take the top spot in the future!

[@shinebayar]

Previous gen serverless implementations are not efficient. They are designed to shift left traditional applications. They literally work in tiny VMs and that's why we have cold starts (tiny VM boot time). Current gen serverless are efficient. They are pure function as services. No little VMs, not even processes are forked for them, pure JS/TS runtime, instant invoke, 0ms cold start. Unfortunately that means NodeJS specific APIs like filesystem, sockets, net/http are not supported. Hopefully new specs like WinterCG solve this in next few years. If this sounds workable to you, check out Deno Deploy or Cloudflare Workers.

[@ashimov1970]

What about t3 stack vs Go comparison?

[@bmdavis419]

T3 stack would win in MOST cases sadly lol, there just is not a huge reason to have a separate Go backend without a really specific reason

[@ashimov1970]

@@bmdavis419 win in terms of performance, right?

[@bmdavis419]

@@ashimov1970 the performance of TS (especially on the edge and with serverless) has gotten really really good, Go is definitely faster, but I would argue that the main reason for Go would be the need to handle either websockets or something that requires concurrency

[@ashimov1970]

@@bmdavis419 Is Go faster even than serverless/edge JS/TS?

[@bmdavis419]

@@ashimov1970 I could not tell you off the top of my head, its PROBABLY a wash (definitely something that would be good to test, might make a good video), but the key difference is that the Go server has access to anything, versus the TS edge endpoint ONLY has access to the basic fetch runtime stuff (fetch, no db connections, etc)

[@orangeoranj8007]

I think I'm going to learn rust.

[@spicynoodle7419]

Serverless is like homeless