Golang + HTMX Project Structure | How I’ve Structured My HTMX Go App

so as you all know I've recently building a product in fullstack goang with HDMX uh and some other fun stuff uh and I've done a live stream on that recently and I just wanted to go over kind of how I've structured my project as I know a lot of people have asked that question uh especially with the HDMX stuff um so firstly this is the service repo here um and kind of what I'm going to be covering is kind of how I've structured uh stuff like this so this is all HDMX kind of editing a form uh all your crud application stuff kind of adding stuff uh um kind of how I've structured endpoints so that if I ever need to expose a Json API I can do that if I ever need to just render HTM X Files um template files I can do that um and kind of how my Approach has been for all that stuff right um You have to excuse me as well I've got a bit of a croaky voice a little bit of a sore throat and stuff um but yeah let's jump into it so I currently have all of my kind of business logic uh database implementations in kind of an internal package and then I have uh all of my kind of uh adapter stuff for my HTTP application uh in this API package right um so first of all all of my components and everything are in this web folder um and as you'll see here everything that starts with com is what I class as a component um so for example you got the experience item here this is kind of rendering an item um and you notice here all this stuff is using HDMX so I've got kind of my uh HX delete attributes my get attributes and all that fun stuff on the elements here now I I've kind of been following a little bit of a pattern where I'm I've been following kind of rest URLs to a certain extent uh where I can and I've decided that any so any kind of end points that return partial HTML template files I have behind a API prefix so they these ones here kind of do the operation like a delete or an update or a post uh um and then I just return obviously the partial that I need to return instead of the Json blob right so that's kind of how I think of HTM XX applications kind of for that go apps I think of it as the same as rest kind of Json apis but you're just not returning Json you're returning obviously markup um so yeah as you'll see here I've got kind of my basic HDMX attributes on this stuff and then obviously these are all swapped out based on if you edit you'll get the the edit component rendered where you'll get the form um so that's what I just showed you on the UI a second ago uh and again you have like your cancel button which again we just go and get the experience item again replace it and replace the form with the item um and then obviously uh the form itself makes a patch request to again following kind of your rest URL patterns um to go and update that experience item um so that's all fun stuff but let's get on to kind of the actual HTTP structuring of stuff so uh the basic stuff kind of has I kind of have this API folder here which has like my repos in there Services uh all injected into this API struct and then I kind of have this whole API stru which is a little bit messy needs a little bit tidying up um starting service that kind of fun stuff and then I have all of the kind of endpoints Pages um in this Roots one here right so for example um the engineer Pages we just looked at all obviously in this engineer. Roots thing and all of them are in this handle package here now a Handler uh all of these are what I consider handlers right and they they all get this Handler struct so this is just stuff that they might need to use like the core um Services um the repos obviously go and get data although these repos here do not have the uh right they can't write to the database right because that's kind of Core Business logic um so they're all in the core um so these Reapers like I'm saying are just readers right so these are engineer readers so these these a reader Reaper implementation so I can get data if I need it but again I can't I can't um write any they have to go through uh the core which is in uh internal application engineer and then all these commands here are the actual kind of core Logic on adding experience creating a engineer profile editing experience and that fun stuff right so yeah let's jump into the Candler um engineer one so this is kind of what it looks like there there's some Mitch Match with the naming of end points at the moment um but I'm going to fix that stuff up as well and tidy it up you have to remember guys this is a side project for me so kind of any code I write is in the evenings after working and obviously uh fatigue comes into it and you start doing stupid stuff right uh but anyway so yeah you'll see here all these API ones here uh will return a partial and how I do that is I have a helper function on the Handler that's passed in which goes and renders a component so it just tries to go and exact a template file um and I only actually have the template files in memory of of components right the other ones are just kind of pages that fiber the framework renders itself um so yeah this this will just go and execute the component partial that can be returned um so you'll notice here like the get experience item one uh has access to the engineer reader part of the repo so it can go get the experience item straight away and just pass that through to a component and render that patch obviously um has a lot of business logic in it so that goes through the experience command the actual Core Business logic uh experience command but this this repo method I I do need to remove that was just kind of a hacky thing I added in at first um but anyway you'll notice here that it does like all your usual kind of API stuff right I go and get the um the user logger from the context that fun stuff and then again I'm just rendering out the updated experience item um which um then is obviously replaced in the screen in the markup via HDMX right um so in short I've kind of got all of my handlers separated into kind of different packages here I have a bunch of helper methods um so like making sure that certain error messages aren't rendered to the web page um I don't want them to be rendered like database errors things like that right obviously you want to hide those all behind uh nice error messages and kind of as the application grows these cases here probably grow quite a lot there'll be other types of errors that I want to display um and again like I say all of these ones here are just uh help of methods to like Rend the templates get the logger uh get the user that fun stuff right um so the actual Pages itself if I go to engineer engineer uh the actual Pages themselves just use the fiber framework so if I go to like the the get dashboard page this is just using um this is basically using c. render which is a fiber method on the context but again I've got some helpers in here um like checking flash data see if there's any errors um set and also I have um some default view data that I pass in to every template file so every template file gets access to which features are enabled um naming of endpoints uh the app name and the app title which are all set in app. go here so like the application uh is go for hunt and obviously the title is pairing talented go Engineers with great companies right that's the idea behind the application um yeah so all those helpers work great and again like I was saying kind of uh these Pages return the renders render the whole page and then uh the actual kind of API endpoint logic actually renders the partial components right um so like I say all of the pages all the end points are in the handle I think here I've got some other useful stuff like um making sure like only certain Engineers can edit their own profile uh which is passed into Core Business logic uh certain other packages like certain cookies obviously all that fun stuff other utility functions like functions I actually use throughout the go Application uh on the UI side um because you can actually pass uh functions to your UI so like escaping strings with component data slice substring again this is all stuff that will grow in our use um kind of as the application gets bigger uh obviously you can set up all your middle Welles in here as well but I think the main thing people probably care about really is just kind of how I set up the end points and kind of the thought process so because I've got all of my core logic in this internal package obviously I can go and import that into end points that just need to return Json so I think one of the concerns people have with HDMX applications is that you're coupling your UI with your backend which is something people people obviously removed with like headless applications that call through to a back end from a front end like with your react and your view your spell all that fun stuff right with JavaScript basically um but that isn't necessarily a problem it all depends how you architect your your system your application as long as you have your core away from your business logic like sorry away from your endpoints so they're not in your actual HTTP layer your transport layer then you can quite easily take your core and send it throughout different endpoints and just import it and call the call the functions right like um the this ad experience method here I can just plug into any Json API or any other kind of application and it will work fine right it's not just specific to my UI which is the main thing I was getting to there um so yeah I think that's kind of an overview guys um again like the recruiter stuff all following kind of rest this this kind of get engineer profile we're just go and actually render the profile page with the profile passed into it um and that's kind of it it really um as for the HDMX stuff uh maybe I can make some more in-depth tutorials on them but it's all really simple stuff guys it's like think of your Json API but just think of it as markup and think of the HDMX attributes as just swapping and putting other HDMX in there's one one thing I'll very quickly show off just because I thought it was it was really cool um if I go to web View and then I go down to the sidebar the HX boost attribute is awesome right so I want to change the page on render so like on when you click on all that doesn't exist that's a good good start so like clicking on details here and clicking on experience obviously changes a whole form section here but it doesn't make a whole request uh whole page refresh right this is all this is actually client side um and that's what HX boost does so it means I don't have to do a whole refresh um it's quite cool anyway I thought that was quite cool like it worked really nicely for that um but anyway that is how I've roughly structured the HDMX application here um hopefully you'll get more of an understanding from like live streams and stuff that I do and also just other tutorials uh this is very much a broad overview of kind of how you might architect a HDMX full stack application and go um yeah hopefully you got some value from it drop a like if you did uh please subscribe I really want to try and hit 2,500 subscribers in January that's the goal uh and I'll see you all later on

Channel: samvcodes

Views: 6,642

Keywords:

Id: lVyIQV-op5I

Length: 11min 28sec (688 seconds)

Published: Wed Jan 03 2024