There is an option for typesafety between Go and TS - gRPC :) It generates types for both Go and TS, and it is the data that is beeing send, so nothing is beeing ommited here@@bmdavis419
The only downside is when you want to go beyond web (like mobile, tv or whatever) Then you will have to maintain two separate “backends”. But if it’s only web I agree
Why, you can add api routes in your routes folder like /routes/api/v1/whatever/+server.ts to make external api routes. They'll perhaps have some different (authentication) logic but it still all in your one environment.
@@captainnoyaux we are talking about using something like htmx for a web app. Unless you want to render your mobile app in a web view, you will need a json adapter for your API to build out the mobile screens with native UI components for iOS/android
SvelteKit is great, and the idea of building fullstack apps with good SSR experience is definitely something worth giving a try. The thing is, the more bussiness logic you have, the less applicable the fullstack technologies are. Using such fullstack frameworks for something more complex than e-commerce sounds like a complete madness to me.
When I look at software architects and how cleanly they implement smth like monoliths in .NET, I just feel like a total mess working with a framework -- or at least if I imagine scaling up. It makes me want to learn more and more and more... but I'm at the point where I just got to pick a technology and stick with it.
it definitely has a limit, but I would argue that the ceiling is a lot higher than you think, at work we have some MASSIVE projects in fullstack JS t3 stack projects that work great (one was basically a linkedin clone)
@@n8o_ yes it is. The "but" is just in contrast to Ben having recently moved from Go to Sveltekit and saying he just isn't into HTMX, which is all good. Different strokes and whatnot
What's nice about HTMX is that you can make your back end into microservices and still use HTMX, so HTMX doesn't necessitate a monolith on the back end. Also, you can have the SPA on the front end with HTMX and have the front end be a micro front end - it is much easier to have a micro front end with HTMX than it is with React, et. al., where with React you are creating monoliths on the front end. Yes, you can break up React, but it is much more difficult.
5:00 I agree. I'd say having fullstack devs where each has a distinct strength within the spectrum is the way to go. So for example, more of a back-end-like full-stacker vs more of a front-end/designer-like full-stacker.
I use grpc separate backend API and connect it to my sveltekit directly. Works quite well when API client gets generated and there is no duplication of code. And I can create more API endpoints on sveltekit that are needed only for web, making SvelteKit similar to BFF (backend-for-frontend) & frontend combo.
i dont quite know grpc and kinds of web tech, "when api client get generated" is it equivalent to api docs ? the duplication of code in the video I think it's when you typed the structure of the response api call in frontend.
@@yazidridwan6917 It basically generates client class, methods and data types you pass to those methods. You can implement server in one language and generate client for any other programming language.
This is a problem I often see with inexperienced or front-end fullstack-wannabe developers who don't know much beyond dom manipulation and API integration. Most tend to think backend development is all about building apis. Now that they have API routers they call themselves full stack developers. An API is just an interface that allows other applications to communicate with the backend. It's not thee "backend". What we have are tools so pick the best one for the job. If you understand the history of software engineering, then you'll appreciate why all these technologies exist.
Did you even watch the video? The dude prefer the FullStack framework, a FS framework is still a backend(Laravel is also a FS framework what you write there? FE code?). What he means is that in the server you fetch the data from the DB and send it as a response and in the client you again fetch the same data and parse it and he is saying that it is better to skip second step, which is leading us to SSR which is the traditional way to create apps. You fetch the data and send the HTML directly and you don't need to fetch again on the FE. He likes Meta Frameworks for JSX because he doesn't like HTMX(which can be used in PHP, GO, Python and so on), that way he can return JSX instead of HTML. What is so hard to understand lol.
@@georgiyanev7822 I did. The problem with all the statements is that the frameworks you quoted (just for example, is not for saying that are bad choices or to go against you) run on interpreter sacrificing speed and control over the machine for dx. The reason why he is going for full-stack frameworks is that he needs and want to create a website. He doesn't really care of the rest nor the speed nor the scalability. Basically he is approaching the problem as a frontender and creating first the client and then the infrastructure. Personally I would made a go server and serve the page statically /using templates, as the application scales you can detouch an API part and the fe into separate threads and use the apis for mobile apps ecc... 😅
I agree with you completely. I did NestJs + Angular in my project, now I regret it..... I should have done MPA in PHP or NodeJs and not complicate everything
I definitely understand the sentiment for coupling full stack. Especially for small teams and startups, next js + backend as as service (supabase etc) allows you to hit market very fast. I've written next JS app before which had a landing page, stripe checkout etc. It's a great DX experience I personally just don't enjoy writing JS/TS everywhere (but if I have had to pay the bills this way I would) I definitely prefer something like C# or Go on the back end. I need to give Go + HTMX a try sometime but haven't because I really enjoy component libraries like ShadCN because I suck at design. Also, to remedy your frustrations couldn't use an interface on the front end for type safety or consider using something like GRPC? Anyways great video keep building cool stuff
Basically you like monoliths is what I hear you saying fullstack. I definitely agree it is the productive way that people have always done fast and amazing things with for so long, its just hilarious we have gone full circle now. I personally prefer the more backend monoliths like Elixir/Phoenix or RoR.
Reason why I'm still writing separate backends for some apps is because I do more than just REST APIs that return data. When you need a stateful and persistent backend for usecases like websockets, server sent events, and CRON jobs, I feel like you'd still have to use it. Is this wrong? I know Vercel has those options but I still prefer to host on a VPS tbh. Also because sometimes of a requirement to write a different app that will consume that API.
This is actually a good point and something I should have probably mentioned. In serverless land (which is where I'm living more and more) most of that stuff does end up needing to be done with either a server (for stateful stuff) or with a server (websocket service). Vercel has stuff for CRON jobs which I recommend, but yea u do loose state on the server which CAN be an L, although I'd argue it is less of an L then people think
This is the exact same thing I once thought. And it is just wrong, there are a huge number of real apps built with fullstack JS, I have built/published many myself
Funnily enough I have been using Sveltekit and been stuck with the same pain of creating API endpoints everywhere and with very little Type Safety - having to still go through the fetch(endpoint, body) dance and custom validations everywhere. I think Astro Actions that just dropped may be a good solution, but I am starting to feel that Sveltekit is failing to address this issue. I would love to get your opinion on this - subscribing just in case.
Yeah that is true. But if your hosting company doesn't support edge functions does it still work. Also should you use api folder in all cases when you use fullstack frameworks like nextjs?❤
Nah u don't need edge, just serverless (which any major hosting provider has). For nextjs I would just run my logic in my components (server components)
I'm on your side about using full stack frameworks but I prefer using backend languages in frontend instead of js/ts for backend. And it's possible through web assembly. My personal choice is leptos.
Yea, these terms are not well defined anymore, and even saying "backend framework" in the title is kinda wrong, b/c like u can use SvelteKit or Next as a normal rest api
Sveltekit is a game changer and the way to go forward. That or Go + HTMX (throw in templ). You don't need anything else. Let's retire the mess that React became and force all those "react devs" to learn proper CS/engineering practices.
I prefer a separate backend because js can't solve problem perfectly Even just proxying the request, rust helps reduce the js server's response time from 100-200ms to around 1-20ms Htmx with pure rust is even faster, around micro seconds
You can just use a modular monolith design and use NATS for routing requests to the api running in the same app. It produces apps you can actually run a debugger on. It also makes it possible to hand roll request tracing. The event bus also functions as a storage layer so you can dump logs into it. Unless you have literally 100s of thousands of CONCURRENT users, this works fine. You still have too many levels of indirection for my taste(e.g. html renderer -> NATS -> logical endpoint -> ORM -> SQL - jesus), but it's way better than convoluted python javascript stacks with thousands of packages that run slower than your grandmother.
Yea but like I would rather just use SvelteKit or NextJS or Nuxt, like JS has its problems obviously but the idea it can't handle anything above a toy app is silly
@@bmdavis419 well in this case you don't have to use the backend parts of your program. You don't have to touch the routing at all, for me the 'frontend' part is just a golang server, so I do my database lookups directly there. EDIT: Presumably the same can be done in js?
What are the pros and cons of adapter static on s3? Does that mean im missing the full stack backend? I think you can do go on the frontend with wasm containers. When i worked on a ship, deff had to have everything cached to the server.
Static adapter just means that like ur serving static stuff, so full SPA, no server attached. You cannot do what I'm talking about in this video that way and would need a seperate backend
To solve the problem you have that is lack of expressiveness in the contract (between BE and FE), you are advocating for just getting rid of the contract and have everything into one giant tangled ball, where the alternative is having a working contract, a working process between teams. This will work only up to the point where the app is small enough to fit the inner workings in everyone's brains. The moment it grows bigger, nobody will have full context of anything, and development will slow to a crawl, everyone stepping on others' feet. In my experience, the complexity accumulates quite fast. If you just do this, I guess it would end up an unmaintainable mess by the 1 year or 2 year mark.
Yea: github.com/bmdavis419/SvelteKit-Ecommerce, I also have multiple in development that are not public yet. Also a ton of big sites work like this (vercel, upload thing, and a lot more)
This is a good solution only for small teams and small projects, ideally for MVP. You need to be a backend dev to understand it. EDIT: I'm fullstack dev btw.
Why would you use JS for the backend? Except as a junior trying to learn backend? JS is a horrible language for a backend language. Go, on the other hand, simple and powerful language
This just isn't true, and let me to over complicating the hell out of multiple projects, and more often then u think JS would get it done JS servers/backends do not explode if you have more then 5 users, I unironically thought this for a long time, its not true. They may never go quite as far as Go, but they can go pretty damn far, certainly far enough to build a business
Thankful more people are saying this. The future is full stack, and these tools make it so much better
Wild Theo appears. Ben's getting attention he deserves.
Fullstack is back to the past :)
Don't tell me about the future...people know nothing
"The future is full stack". It always was, client side rendering is, was and will always be dumb.
Oh shit, here we go again. 1-2 years and we will find that decoupled services are better.
If they make a way for me to get end to end typesafety from Go to TS then yea 100%, but with what is here now? Fullstack all day
There is an option for typesafety between Go and TS - gRPC :) It generates types for both Go and TS, and it is the data that is beeing send, so nothing is beeing ommited here@@bmdavis419
@@bmdavis419 **cough** code generation **cough** gRPC **cough** OpenAPI **cough** 😂
Not an expert, but wouldnt gRPC provide you type safety end to end between Go and Typescript?
@@Mikenight120 author removes comments like this
The only downside is when you want to go beyond web (like mobile, tv or whatever) Then you will have to maintain two separate “backends”. But if it’s only web I agree
yea expect a video about this soon, mobile does need a seperate backend, go might be coming back lol
Why, you can add api routes in your routes folder like /routes/api/v1/whatever/+server.ts to make external api routes. They'll perhaps have some different (authentication) logic but it still all in your one environment.
You just architect your code with repository pattern and you can have a json API adapted from what your html API already uses
why would mobile need a specific backend ? I never encountered that case (10+ years of experience)
@@captainnoyaux we are talking about using something like htmx for a web app. Unless you want to render your mobile app in a web view, you will need a json adapter for your API to build out the mobile screens with native UI components for iOS/android
SvelteKit is great, and the idea of building fullstack apps with good SSR experience is definitely something worth giving a try. The thing is, the more bussiness logic you have, the less applicable the fullstack technologies are. Using such fullstack frameworks for something more complex than e-commerce sounds like a complete madness to me.
When I look at software architects and how cleanly they implement smth like monoliths in .NET, I just feel like a total mess working with a framework -- or at least if I imagine scaling up. It makes me want to learn more and more and more... but I'm at the point where I just got to pick a technology and stick with it.
I do not agree with you
I don't remember him saying "this is the best solution in all circumstances without exception"
What about handling bff data in full stack framework and business logic inside of proper backend language?
it definitely has a limit, but I would argue that the ceiling is a lot higher than you think, at work we have some MASSIVE projects in fullstack JS t3 stack projects that work great (one was basically a linkedin clone)
I’m a fan of go+htmx atm but I totally agree full stack / monolith is the way to go unless and until there’s some pressing reason to change
Is Go+HTMX... not fullstack/a monolith itself?
@@n8o_ yes it is. The "but" is just in contrast to Ben having recently moved from Go to Sveltekit and saying he just isn't into HTMX, which is all good. Different strokes and whatnot
What's nice about HTMX is that you can make your back end into microservices and still use HTMX, so HTMX doesn't necessitate a monolith on the back end. Also, you can have the SPA on the front end with HTMX and have the front end be a micro front end - it is much easier to have a micro front end with HTMX than it is with React, et. al., where with React you are creating monoliths on the front end. Yes, you can break up React, but it is much more difficult.
Full stack is the only way to go with small teams
5:00 I agree. I'd say having fullstack devs where each has a distinct strength within the spectrum is the way to go. So for example, more of a back-end-like full-stacker vs more of a front-end/designer-like full-stacker.
This is what we have, everyone has strengths, but we can each handle everything
I use grpc separate backend API and connect it to my sveltekit directly. Works quite well when API client gets generated and there is no duplication of code. And I can create more API endpoints on sveltekit that are needed only for web, making SvelteKit similar to BFF (backend-for-frontend) & frontend combo.
i dont quite know grpc and kinds of web tech, "when api client get generated" is it equivalent to api docs ? the duplication of code in the video I think it's when you typed the structure of the response api call in frontend.
@@yazidridwan6917 It basically generates client class, methods and data types you pass to those methods. You can implement server in one language and generate client for any other programming language.
This is a problem I often see with inexperienced or front-end fullstack-wannabe developers who don't know much beyond dom manipulation and API integration. Most tend to think backend development is all about building apis. Now that they have API routers they call themselves full stack developers. An API is just an interface that allows other applications to communicate with the backend. It's not thee "backend". What we have are tools so pick the best one for the job. If you understand the history of software engineering, then you'll appreciate why all these technologies exist.
Answer: because you are a frontender
Did you even watch the video? The dude prefer the FullStack framework, a FS framework is still a backend(Laravel is also a FS framework what you write there? FE code?).
What he means is that in the server you fetch the data from the DB and send it as a response and in the client you again fetch the same data and parse it and he is saying that it is better to skip second step, which is leading us to SSR which is the traditional way to create apps. You fetch the data and send the HTML directly and you don't need to fetch again on the FE.
He likes Meta Frameworks for JSX because he doesn't like HTMX(which can be used in PHP, GO, Python and so on), that way he can return JSX instead of HTML.
What is so hard to understand lol.
@@georgiyanev7822 I did.
The problem with all the statements is that the frameworks you quoted (just for example, is not for saying that are bad choices or to go against you) run on interpreter sacrificing speed and control over the machine for dx. The reason why he is going for full-stack frameworks is that he needs and want to create a website. He doesn't really care of the rest nor the speed nor the scalability.
Basically he is approaching the problem as a frontender and creating first the client and then the infrastructure. Personally I would made a go server and serve the page statically /using templates, as the application scales you can detouch an API part and the fe into separate threads and use the apis for mobile apps ecc... 😅
@@georgiyanev7822 Inertia and its (even GO is there) adapters can solve that, it works as a glue for both sides and reduces a lot of complexity.
@@The6DAZ6great comment. interesting to see it from that perspective.
@@Ahduciekwndnbbbsvvvghhhyyyyy Thanks ^^
I dont believe js should be used to on the server
i bet you don't like pineapple on pizza either >:(
I agree with you completely. I did NestJs + Angular in my project, now I regret it..... I should have done MPA in PHP or NodeJs and not complicate everything
I definitely understand the sentiment for coupling full stack. Especially for small teams and startups, next js + backend as as service (supabase etc) allows you to hit market very fast. I've written next JS app before which had a landing page, stripe checkout etc. It's a great DX experience I personally just don't enjoy writing JS/TS everywhere (but if I have had to pay the bills this way I would)
I definitely prefer something like C# or Go on the back end. I need to give Go + HTMX a try sometime but haven't because I really enjoy component libraries like ShadCN because I suck at design.
Also, to remedy your frustrations couldn't use an interface on the front end for type safety or consider using something like GRPC?
Anyways great video keep building cool stuff
Basically you like monoliths is what I hear you saying fullstack. I definitely agree it is the productive way that people have always done fast and amazing things with for so long, its just hilarious we have gone full circle now. I personally prefer the more backend monoliths like Elixir/Phoenix or RoR.
I am more arguing for full stack type safety, but yea monoliths are also better then 20 different codebases
Reason why I'm still writing separate backends for some apps is because I do more than just REST APIs that return data. When you need a stateful and persistent backend for usecases like websockets, server sent events, and CRON jobs, I feel like you'd still have to use it. Is this wrong? I know Vercel has those options but I still prefer to host on a VPS tbh.
Also because sometimes of a requirement to write a different app that will consume that API.
This is actually a good point and something I should have probably mentioned. In serverless land (which is where I'm living more and more) most of that stuff does end up needing to be done with either a server (for stateful stuff) or with a server (websocket service). Vercel has stuff for CRON jobs which I recommend, but yea u do loose state on the server which CAN be an L, although I'd argue it is less of an L then people think
This is valid but only for pure landing pages
This is the exact same thing I once thought. And it is just wrong, there are a huge number of real apps built with fullstack JS, I have built/published many myself
In what world would you ever write REST for a landing page?
tip: for hono you can export the type and instantiate a client which guarantees typesafety when calling your API. You can also add zod validators.
Funnily enough I have been using Sveltekit and been stuck with the same pain of creating API endpoints everywhere and with very little Type Safety - having to still go through the fetch(endpoint, body) dance and custom validations everywhere. I think Astro Actions that just dropped may be a good solution, but I am starting to feel that Sveltekit is failing to address this issue.
I would love to get your opinion on this - subscribing just in case.
Hope there will be a good DX in go ecosystem in near future, maybe it will be htmx idk
Its probably HTMX, unless they make something to TRPC style connect Go + TS, which seems VERY unlikely
Htmx needs a backend framework, the thumbnail is kinda confusing
Yea its the best stand in I could think of for fullstack Go
Yeah that is true. But if your hosting company doesn't support edge functions does it still work. Also should you use api folder in all cases when you use fullstack frameworks like nextjs?❤
Nah u don't need edge, just serverless (which any major hosting provider has). For nextjs I would just run my logic in my components (server components)
I haven't been this excited about the direction DX is starting to go since jQuery went stable and I thought I had super powers. (realized I had...)
The only reason I could have a separated backend is for strict security, e.g. I'm a bit scared of having backend envs around a metaframework
SvelteKit allows you to flag envs as backend only, and if you try to import it from the frontend you will get an error stopping you
I'm using astro + grpc and had no problems with it. Feels productive and I dont have to write yucky JS on the server
Grpc is more productive then writing db.findMany() at the top of your file? 🤨
@@bmdavis419 bit of a disappointing reply as grpc hasnt got anything to do with querying data from a database.
I'm on your side about using full stack frameworks but I prefer using backend languages in frontend instead of js/ts for backend. And it's possible through web assembly. My personal choice is leptos.
Is rails, php. django etc full stack as well? I think so. I think the whole backend/fronted distinction might be a relatively recent concept
Yea, these terms are not well defined anymore, and even saying "backend framework" in the title is kinda wrong, b/c like u can use SvelteKit or Next as a normal rest api
I prefer my backend and front end being agnostic from each. Even my db. Writing all the rules inside the db instead of the backend.
such an on point opinion.
api client generation is the way to go
Sveltekit is a game changer and the way to go forward. That or Go + HTMX (throw in templ). You don't need anything else. Let's retire the mess that React became and force all those "react devs" to learn proper CS/engineering practices.
templ makes a world of difference
I prefer a separate backend because js can't solve problem perfectly
Even just proxying the request, rust helps reduce the js server's response time from 100-200ms to around 1-20ms
Htmx with pure rust is even faster, around micro seconds
while true, not to be that guy but why? does 80ms really matter if it is 100x harder to build stuff?
You can just use a modular monolith design and use NATS for routing requests to the api running in the same app. It produces apps you can actually run a debugger on. It also makes it possible to hand roll request tracing. The event bus also functions as a storage layer so you can dump logs into it.
Unless you have literally 100s of thousands of CONCURRENT users, this works fine. You still have too many levels of indirection for my taste(e.g. html renderer -> NATS -> logical endpoint -> ORM -> SQL - jesus), but it's way better than convoluted python javascript stacks with thousands of packages that run slower than your grandmother.
Yea but like I would rather just use SvelteKit or NextJS or Nuxt, like JS has its problems obviously but the idea it can't handle anything above a toy app is silly
@@bmdavis419 well in this case you don't have to use the backend parts of your program. You don't have to touch the routing at all, for me the 'frontend' part is just a golang server, so I do my database lookups directly there. EDIT: Presumably the same can be done in js?
What are the pros and cons of adapter static on s3? Does that mean im missing the full stack backend? I think you can do go on the frontend with wasm containers. When i worked on a ship, deff had to have everything cached to the server.
Static adapter just means that like ur serving static stuff, so full SPA, no server attached. You cannot do what I'm talking about in this video that way and would need a seperate backend
To solve the problem you have that is lack of expressiveness in the contract (between BE and FE), you are advocating for just getting rid of the contract and have everything into one giant tangled ball, where the alternative is having a working contract, a working process between teams.
This will work only up to the point where the app is small enough to fit the inner workings in everyone's brains. The moment it grows bigger, nobody will have full context of anything, and development will slow to a crawl, everyone stepping on others' feet.
In my experience, the complexity accumulates quite fast. If you just do this, I guess it would end up an unmaintainable mess by the 1 year or 2 year mark.
I suppose if you have 1 client this is likely the most efficient approach.
Laravel is king
Would you care showing some examples of business logic in your JS full stack app and it working "really freaking well" like you said?
Yea: github.com/bmdavis419/SvelteKit-Ecommerce, I also have multiple in development that are not public yet. Also a ton of big sites work like this (vercel, upload thing, and a lot more)
This is a good solution only for small teams and small projects, ideally for MVP. You need to be a backend dev to understand it. EDIT: I'm fullstack dev btw.
I don't get it. Who needs more than a console as a front end? 😂
what about realtime stuff? and dashboards etc?
what do you think of fastify microservices + trpc in a monorepo with frontend
Would work great, but still would probably be more of a pain than SvelteKit or NextJS app dir, for very little gain b/c ur not leaving TS land
@@bmdavis419 how would sveltekit or nextjs work tho if i wanted a mobile app, do i have to rewrite the backend again?
By "full-stack" you mean "full-stack js" or "isometric."
You lost me at the backend devs writing CSS. 😂
hey man I've gotten better at it
Go is not good for prototype
You should try Laravel 😊
Why would you use JS for the backend? Except as a junior trying to learn backend? JS is a horrible language for a backend language. Go, on the other hand, simple and powerful language
This just isn't true, and let me to over complicating the hell out of multiple projects, and more often then u think JS would get it done
JS servers/backends do not explode if you have more then 5 users, I unironically thought this for a long time, its not true. They may never go quite as far as Go, but they can go pretty damn far, certainly far enough to build a business
Go is not easy
Typescript.. ewww..