Today we talk with the director of engineering, Jeremy Tomlinson, and communication specialist, Rich Kurtzman, from Fathym.  Described as an “innovation acceleration engine,”  we discuss how Fathym provides the building tools which allow jr. and sr. engineers alike contribute to development.  The platform allows use of your own code, low code, or leveraging Fathym’s no code build tools.

Hello everybody and welcome to yet another exciting episode of Views on View, your source for view news and great dad jokes. I am Steve Edwards, the host with the Faceful Radio and the voice for being a mime, but I'm still your host. Today with me we have two guests, owners, founders from the platform Fathom, F-A-T-H-Y-M, fancy spelling there by the way. So first off, why don't you guys take turns and tell us about yourselves, who you are, why you're famous, and what we're going to be talking about.

 

Cool, you wanna go ahead Jeremy?

 

Sure. So I'm Jeremy Tomlinson. I'm the Director of Engineering at Fathom. I've been with Fathom for about 12 years now. And I started off as a main contributor on the dev team, and I've transitioned to our Director of Engineering. And these days I spend most of my time discussing, planning, and reviewing work for the team. And I grew up as an army brat, so I've lived all over the states. I spent four years in Germany as a kid, and I'm really into soccer and Haribo gummy bears. Rich?

 

And yeah, thanks Jeremy. My name's Rich Kurtzman. You know, I've been with Fathom for about seven months. I'm the brand communications person. I'm originally from Denver, Colorado, and I now live in Fort Collins, where I went to Colorado State University. You know, in Colorado we love the outdoors and I definitely do. Fishing, camping, hiking, all kinds of stuff like that. And I've also been a professional writer for about 12 years. Mostly writing on the Denver Broncos and other Denver sports. But, you know, I've recently branched out to tech and, you know, at Fathom. I'm working on content creation and spreading the word about our fantastic offerings. And... always looking to collaborate with other companies. We're really stoked to be on the podcast, so thank you, Steve.

 

Yeah, thanks Steve.

 

Ha.

 

if he's still talking to us.

 

I don't know, I feel like he would be in here. The recording

 

Right.

 

is still going. Steve, if you can hear us, we cannot hear you and we do not see you anymore. I mean considering when he was introducing it started skipping and

 

Yeah, he might have had a...

 

lagging.

 

internet issues.

 

Hm, hm, hm, hm. the irony of being on a technological podcast and tech tech breaking

 

Well, and this is why you edit afterwards, right?

 

Totally.

 

You can take all the best stuff and then edit it down to what you want to present.

 

Okay, so he just messaged me. You know what? That was a nice dry run. And we'll just redo it. and you're muted. Just saying it.

 

Oh yeah, that's right.

 

He said, yeah, it's not letting me reconnect for some reason. Everything else is fine. I'm asking if we should start a new room. I mean this is the premiere podcast program or whatever. Niner's Cowboyz.

 

Ha ha ha

 

Ha ha ha  I mean, he probably remembers that too, because he's of the age to remember it. Yeah. well when did

 

I

 

you

 

guess.

 

start college cuz you get a pretty

 

92.

 

okay so you're about five years younger than it sounds like so you get a pretty similar in age

 

Yeah.

 

ish

 

Totally. Hahaha

 

He said he's trying to get connected and we can start again.

 

Okay, sounds good.

 

Yeah.

 

Maybe

 

Good thing

 

I should...

 

I found him on Twitter, you know.

 

I know, I know.

 

We're able to communicate that way at least.

 

I could send a link to the video we were watching while we were waiting.

 

Hehehehehehe Jeremy.

 

You guys

 

He's...

 

there?

 

Yeah, he's Steve.

 

I'm back, had to restart my browser. Not sure what's going on.

 

I thought maybe you just didn't like our intros.

 

I never got to hear him.

 

Hahaha

 

All right, so it looks like it started a new recording, so I'll just go from here. All right, I'll just start over. That's

 

Okay.

 

such a great intro

 

Sounds

 

too.

 

good.

 

All

 

Ha ha

 

right.

 

ha ha.

 

Hello everybody and welcome to yet another exciting episode of Views on View, your source for news on ViewJS and Great Dad Jokes. My name is Steve Edwards. I am the host with the face for radio and the voice for being a mime. but I'm still your host. Today, I have with me as guests, Jeremy Tomlinson and Rich Kurtzman, excuse me, from Fathom, a new hosting platform. How you doing, fellas?

 

Doing good, thanks Steve.

 

Doing great. Thank you for having us.

 

My pleasure. All right, and we cannot forget, we also have our studio audience. So say hi everybody. How you doing?

 

Hey guys.

 

Hey, hey.

 

Alright, thank you very much. Thank you very much. It's always nice to have a studio audience. It gets lonely otherwise.

 

Yep.

 

Hehehe

 

So, we are here today to talk about Fathom, but before we get started there, fellas, why don't you give us some introductions. Who you are, what you do, why you're famous, and so on.

 

Yeah, sounds good. I'm Jeremy Tomlinson. I'm the Director of Engineering at Fathom. I've been with Fathom for about 12 years now. I started out on the engineering team as one of our main contributors, and I've transitioned to our Director of Engineering. And these days I spend more of my time discussing, planning, and reviewing work for the team. And I grew up as an Army brat, so I've lived all over the States. I'm in Colorado now. and I spent some time when I was a kid in Germany. And so I'm really into soccer and I love Haribo gummy bears.

 

and my name's Rich Kurtzman. I'm originally from Denver, Colorado and you know here in Colorado we love the outdoors and I definitely do. Fishing, hiking, camping, all that good stuff. Speaking of Colorado, I've been a professional writer for about 12 years, mostly writing on sports including the Denver Broncos who you know they're going to be good this year but... Been with Fathom for about seven months now as a brand communications person and in that role you know I work on content creation spreading the word about our fantastic offerings and always looking to collaborate with other companies and uh... yeah thanks again for having us on Steve.

 

So as a Colorado College alumni, all I have to say about Denver is DU sucks.

 

Hahaha

 

Well, as a Colorado State University alum, I'll go with it.

 

Okay, good.

 

Hahaha

 

Yeah, CC was a small school, but we had Division I hockey and DU was always our biggest rival.

 

Oh, that's

 

and then

 

great.

 

the national champions last year. So. Ha ha

 

I know, I know.

 

ha.

 

Yeah.

 

Anyway, okay, so let's talk about Fathom. Now to be honest, and don't take this personally, but when you guys contacted us, that's the first I'd ever heard of it. And so I was surprised when you said it had been around for 12 years. I'd be honest. So why don't you give us a little background either beyond what Fathom is, and I guess what I'm more curious about is what differentiates it from some of your other more well-known platforms like... say a Heroku or Netlify or any of the other well-known ones.

 

Cool. Well, and like you said, in the past 12 years, we started out more as an IoT company. And so we have a background in IoT. And as we started kind of struggling and learning the ins and outs of cloud technology, whether it was AWS or Microsoft Azure. we started building other tools to help us automate, you know, some of the stuff happening in the cloud and trying to build tools so that some of our, you know, junior engineers could get in and help contribute. So it wasn't just all of our senior engineers doing this stuff. And so, you know, kind of as a whole, we'd like to think of Fathom as an innovation acceleration engine. On the hosting side, we help companies get their web projects up in the cloud. Right now, we're specifically focused on Microsoft Azure. And we have a platform for controlling cloud costs, so you don't get hit with a crazy bill at the end of the month. We help with scale, security, DevOps processes, like CI, CD, pipelines that continuously build and deploy your applications. And yeah, in terms of comparing us to Netlify and Versel and some of those, I think we're very similar. It's you know, we we're not tied to one cloud and we're very much, you know Thinking of the developer and you know companies first

 

Yeah, and along that same route, I would say, you know, we're always aiming to lower the bar in terms of what it takes to host or build a website, you know, through our Fathom platform. And Jeremy kind of touched on that, but. We allow people to use no code tools, low code tools, or you can use JavaScript frameworks. So you can use Vue, certainly. Nuxt, definitely. But if you need to use a no code tool, you're fine to do that. And they all fit in our modular frontends, which many people have heard of micro frontends, and that is what we were referring to our platform for a long time. But we have recently kind of rebranded as modular frontends. because we do not go down to the component level. But we can talk more about that as we continue on.

 

Okay, so bigger picture, you talked about Azure and AWS. Do you have your own hosting, your own infrastructure, or are you just sort of a layer on top of hosting on top of an AWS or Azure or Google Cloud or something like that?

 

Yeah, we sit on top of those clouds and we worked with AWS in the past. You know, now we're focused on Microsoft Azure. And so we have a shared cloud, I guess part of our environment up in Azure is our shared cloud. And so people that sign up for our free accounts and stuff like that, they're initially just in our shared environment up in Azure. And then we have technology and drag and drop interfaces so that if people wanna set up custom infrastructure in their own clouds, we can make that happen also.

 

But from the user, is it transparent? In other words, to them, all they know is that they're hosting their project with Fathom and the rest they don't see.

 

Yeah, that's correct. Yup.

 

Okay, gotcha. So, but can they choose? Now you mentioned you had worked with AWS and now you're working with Azure, so does that mean you've completely switched over or you can use both? Or how does that fit in?

 

Right now we are only up in Microsoft Azure. We're a Microsoft partner.

 

Okay.

 

And so we started with AWS when we were doing like with our IoT background. And then just over time, as we became a Microsoft partner, we transitioned over to Microsoft Azure.

 

Oh, okay, understood, understood. So let's talk about, you said talk about modular front ends. Can you explain what you mean versus say micro front ends? I mean obviously they both start with M, so they have some similarities.

 

Hehehe

 

Right.

 

But the micro is more size and modular is more how it's divided I guess. So what do you mean by that?

 

Rich, do you want to take this one and I'll kind of provide some color commentary?

 

Yeah, sure. Yeah, I mean, basically one of the misconceptions about micro front ends is the way that the architecture is actually working, you know, at least with us. So in the original definition of micro front ends and we were working on Martin Fowler's definition, which was written back in 2019, it's kind of more common to break a single page, say the home page, down into multiple components. So, you know, maybe one person or one team. is working on. This button over here and another person is working on maybe this picture over here and it all comes together in a container in one page. But that's not how we do it. And so in our modular approach, each page or route as we like to call it, and Jeremy can really explain this a little bit further, you know, they're all working on their own Each page or route can be developed and worked on by a different developer or a different team. And so very much like micro front ends, you have individual independent and smaller front ends. Like I said, multiple teams can work on their projects concurrently. So, you know, if you have a small team like we do at Fathom or at other small startups, you can get a lot of work with each person kind of working on their own task and then coming together, you know, for the whole. You know, these modular frontends also mean smaller and incremental deployments. So since you have multiple teams, it means that one team isn't necessarily waiting on another to push their deployment. You also have smaller code bases and, you know, that just means it's easier to maintain and change them. It's also easier to find and fix bugs. and the modular front-end approach also allows you to scale as you need to and yeah we're huge on them and Jeremy what else would you like to say about them?

 

One thing how I think about modular front ends is in the backend world, you know, we had microservices. And microservices, you could kind of create them in whatever language you wanted, and you would provide an API endpoint. And that's how the front end, or really anyone, could interact with your microservice. We're doing the same thing for modular front ends. Modular front ends are also, like Rich said, we have these routes. So you might have your site, like fathom.com, and then off of that, you might have a slash dashboard. Well, that slash dashboard, that's your route. And then under your route, you can have one or an unlimited number of pages app stacked under that route. And those routes and those pages, those are the equivalent to the microservices. And so they can be written in any language that you want. They can all be written in the same language, if that's what you prefer. But it just very much provides the flexibility on the front end that we've always had on the back end.

 

Mm-hmm.

 

So, okay, I'm still trying to get my head around this. So, you could have like a blog. Can you combine multiple frameworks across one application

 

Yeah,

 

with each on its own route?

 

and that's some of the power, you know. So let's say, again, I'll use fathom.com as an example. Your slash blog could be written in Vue. And then you can have slash docs and that's in DocuSource. You know, you can have your slash dashboard and maybe that's a Nuxt.js. And so you can kind of pick and choose based on the strengths of your team members, you know, what frameworks you wanna use. And if it's just one person, you can still divide up, you know, these different routes and you could create them all in view if you want to. But now you can have different repositories that you're storing each of these routes in. And now it avoids things like dependency, conflicts, different versions of libraries and stuff like that that you might be including in one repo. Where if you're in a monolith and everyone's merging their code back into the monolith, I've been in teams like that and there's just lots of headaches and lots of pain and suffering around trying to figure out what version of a certain dependency that we're going to use. And now being able to break things out into different repos or even MPM packages, it just provides a lot more flexibility stepping on someone else's, someone else, another team's stuff.

 

Okay, so that's what you can do, but do you have to do it that way? I mean, if I have just a simple, you know, you, you raise the case of Nuxt. Um, if I have a Nuxt app, that's just, you know, you want to know, you want to use it, uh, what's the term universally where you have a, a node back end running. And so it's dynamic as compared to a statically generated site. For instance, you can still have all your routes and you know, URLs within one app instead of having a separate one. Uh, divided

 

Yeah,

 

by a separate project, right?

 

yep, for sure. And the great thing with that is we do some of that stuff like that too, Steve, is we have a number of routes, you know, maybe in one application. But then just if you wanna break something else off, you know, like. a different feature in the dashboard or something like that. You can put that on its own route. And now if you need to use, again, different dependencies or a different framework that's maybe more suited to that task, you're able to do that. And from the end user point of view, they have no idea that it's not part of your monolith in that sense, because everything's just running on routes. They're not running on subdomains. And so from the end user point of view, if you build things with the same look and feel, you know, your users have no idea that you're, you know, things.

 

Right, so it's transparent to the user.

 

Yeah.

 

Okay, so one of the articles you've written here recently, and since this is a view podcast, we should probably talk about this, you've got a blog post on how to deploy view sites on Fathom. Now I haven't had the chance to read through this in detail, but are we talking basically of USPA in this particular blog post that you're talking about?

 

And so it definitely could be, you know, it's, we don't discriminate in terms of what we host. You know, it's, we do everything from a monolith down to micro front ends or to these modular front ends. You know, it's very much, and like even Rich was talking about, like no code tools. You know, it's, we can host any and all of those, those situations.

 

Okay, so it sounds more like you're geared towards an enterprise, right? Who's somebody who has a large enough application and a large enough either team of engineers or teams of engineers as the case may be, right? Where you need to split up the work and be able to handle different parts of your application with different teams or different tools. As you mentioned, docusource versus a JavaScript framework versus whatever.

 

Yeah, that's exactly right. And you know, there are advantages and disadvantages to using all these different tools. And so by giving people the freedom, which is one of our company values, to choose whatever tool they want to use, well, if you have a small team, then you can allow them, you know, like me for instance, I don't know how to code. But if we're using a no code tool, then I can run the blog and I can produce it myself. So basically you're going to be able to leverage your team members and get the most out of them by using, you know, different tools and different applications. Now, if you are a large enterprise like that, to talk on this a little bit further after I'm done, then yeah, you could use React, Vue, whatever framework that they are comfortable using and for whatever reason. I mean, obviously React is incredibly popular. Vue has become a lot more popular in recent years. And so if you have a React developer, they can build that page out of React or the whole structure, basically, of the site. So yeah, it basically just gives teams more flexibility to kind of use whatever they need. You know, like if you're looking to use or to create something lightweight, like for instance, we asked one of our developers who specifies and react to use Svelte because Svelte, you know, can make a lighter weight page. it was able to do that and it was a way for us to illustrate how our modular front ends work. And then, you know, we wanted it to be lightweight so it ran quickly and easily, you know, without, you know, big downloads or anything like that. Now, obviously, we've had pushback by people saying, well if you use React in multiple of these routes, isn't that gonna slow down the site? It's possible, but that's why you can also kinda play around and use these lighter weight ones or spas or static site generators, et cetera.

 

And the thing I would add to that, Rich, is that, you know, we work with... all different size companies. So we work with small startups, you know, we work with medium sized businesses as well as enterprise customers and they all get the same benefits from this stuff. You know, it's very much our platform is designed so that based on the strengths of your team, you know, we help bring those to the forefront and you're not, you know, limited by a language, you know, again, like when view and the NuxJS came out, you can start building new areas of your site, you know, with NuxJS, and you don't have to go rebuild everything else. You know, of start with your new stuff and then over time if you want to rebuild stuff you can, but you know you don't have to rebuild your entire monolith with Nuxt.js just because you want to try it out maybe on your dashboard or something like that.

 

So, are we limited? I'm reading through your documentation at phallum.com slash doc. And so, you've got under deploying, for instance, you have frameworks, Angular, React, VELT, Vue, and site builders like Plasmic and Docosaurus. What about other, say, static site builders, like for instance, one I've been working with is Astro or Eleventy or some of the more... you know, specific static site builders that aren't necessarily the big old frameworks. Are those hostable as well, or are you limited to some of the framework stuff?

 

So the only thing that we've seen just differentiation or things that are different on is just how we build those projects. And so when you're setting up your project, you provide the build command and any other commands that we need to run. Like essentially, if I was downloading your repo and I was trying to pull it up in Visual Studio, what do I need to run your project? And so you have to inform our platform on what we need on that stuff. But outside of that, works.

 

Okay, and then we've talked about viewing Nuxt, so just to be more specific. So Nuxt, obviously you can run in a couple different ways. Nuxt 3 doesn't quite have the static capability, but I know they're working on it. But the idea is that you can either do a static or dynamic site. So a static site where you build it all, generates all your HTML and you upload that. And that's it. And then you got to rebuild it if anything changes versus dynamic where you've got a back end running that dynamically generates your data. And like a node back end, for instance, I think that's the default. And next is you can run either of those settings or

 

Yep,

 

structures. Excuse me.

 

yep, yep, that's correct. And right now we don't have a user interface for uploading all of your backend code, or setting up your APIs and stuff like that. We can do that stuff manually for you, but if you have that stuff up in the cloud somewhere else where your front end is using those APIs, then you can bring your front ends to us just today.

 

Okay, well, I mean, the back end, the node stuff is, you know, it's part of Nuxt, it's just how you run it. Right, so that's, I mean, I haven't done any much dynamic stuff with Nuxt, just static mostly. Excuse me. But that's all, it's all self-contained.

 

It is, yep. And we have Nux sites up on Fathom right now.

 

Mm-hmm.

 

And yeah, you know, in that sense, the

 

Thanks

 

most

 

for

 

of

 

watching!

 

the stuff that at least the next sites that I've built, it's more front end stuff. You know, I don't have, you know, stuff stored in a database and things like that on the more dynamic side of stuff.

 

Uh huh.

 

And I think that's the stuff that I'm referring to. You know, we don't have a spot right now where you can, you know, connect to a database up in Microsoft Azure and set up your tables, you know, or set up, you know, some of your APIs and stuff like that. We're working on those types of features. Right now it's more of anything that you can set up in your Nuxt project in Visual Studio and then you push to your GitHub repo. That's all the stuff that we can host today.

 

Okay, so let me throw you another scenario then and this is a framework that I like to push because I've had the guy on a couple times and I use it myself as inertia.js. Are either of you familiar with that?

 

I'm familiar with it, but I've never built anything with it.

 

Okay so for those that maybe haven't heard me talk about it before, inertia is basically glue that allows you to create a monolith with your own pieces. So it sits in between your front end and your back end. So your front end it has adapters for Vue, Svelte, React, Angular I believe. And then back ends you can use Node, you can use Laravel, you can use Ruby. And maybe... there in the community might have adapters for something more. So the way it works is from the view front end or from whatever your JavaScript front end, there's library sits in between and it hijacks your post requests, sends them directly to your backend and then your backend sends the data back as props. So that way you're not doing the browser refresh. It's just instantaneous, it's just really quick. So my stack that I like to work in with is view on the front end and Laravel with MySQL on the backend. So I just write Laravel as I normally would with a slight modification to send stuff back as inertia as compared to Blade or something like that. So that requires Laravel in the back end, Vue in the front end, and then MySQL. So that's the kind of stuff you're saying would require a little more custom setup on your end to be able to work with something like that.

 

Yeah, that's correct. And it's all stuff that Microsoft Azure supports. We just don't have a UI in our platform at the moment

 

Mm-hmm.

 

to support that stuff. And so it's more of we have to log into the Azure portal and set that stuff up manually,

 

Mm-hmm.

 

which we have done for clients.

 

Mm-hmm.

 

But yeah, the more point and click stuff that we have available today is more for your front end based stuff.

 

Gotcha, okay. So for someone like me coming in using your free tier, you're probably not gonna want to do that versus an enterprise customer that's actually paying for your time, right?

 

You know, we're still trying to get our platform off the ground in that sense.

 

Uh huh.

 

And so, you know, we definitely have a support team that, you know, can go above and beyond to help people on our free tier too, for sure.

 

Hmm, okay.

 

Our thought on this stuff is that if we get people kind of hooked on the free tier, then they'll want to move up and do more. And that's why we also, we don't want people to be stuck in our shared environment.

 

Mm-hmm.

 

If at some point you want to provision all the stuff from our shared environment over to your own Azure cloud, and now you're getting the bill from Microsoft at the end of the month,

 

Mm-hmm.

 

we can do that too. And that's definitely more, we have more enterprise customers that want to do that.

 

Sure.

 

But we have that path forward.

 

All right,

 

and

 

so you're still working through the Fathom UI and it's just hosted behind the scenes on Azure?

 

Yeah, that's

 

Okay.

 

correct.

 

And I think Jeremy did mention it, that we will be working with AWS in the future as well. So there will be an option for Azure or AWS eventually.

 

And Google also, right

 

Mm-hmm.

 

now we're kind of just listening to our users. And we have a number of users in our shared environment that really don't care. They're just trying to get stuff up in the cloud. They want a URL. They want to map their custom domain over to us.

 

Uh huh.

 

And really they, we have a number of people that came to us because they were. worried about some of the cost management features up in Azure. You know, sometimes you put your credit card down with a group and you're just using it and they're not really showing you how much it's costing. Like they're

 

Right.

 

showing you in, you know, storage or whatever it might be. And then at the end of the month, you know, you get a bill for 10 grand.

 

Right.

 

And we had that with one of our teams, we got a bill for 40 grand at the end of the month. And we were like, yo, what happened? And they were like, well, we didn't know how to scale this stuff. It wasn't running fast enough. So they kept scaling stuff, things up, not knowing, you know, the repercussions were on the cost side. And so now we have, you know, kind of levers and some things in place that... help us protect users from that, you know, that want to be in the cloud, you know, that want to like harness some of that power in the cloud.

 

Uh huh.

 

But now we can provide, you know, some gates and some things around that so that, you know, you're just a little protected and you know, if you're paying, like if you move up to one of our pay plans and maybe it's $8 a month, you know, you're not getting charged more than $8 a month at the end of the, you know, at the end of the pay cycle.

 

Okay. So is there anything, since we're again on a Vue podcast, is there anything else Vue specific to talk about that, I don't know if it's unique, I mean it's a framework like the other ones, a JavaScript framework. Because I know you've, in notes here we talk about Vue sites on Fathom and how we support them or blogs you've written.

 

The other couple of blogs that we've written, one was kind of just an overview of some JavaScript frameworks that developers do know or should know. Because we've had a focus on getting the individual developer to sign up over the last six months and we've done really well. We have over 29,000 signups currently.

 

Uh-huh.

 

customers as well, but one of the blogs that we wrote was for JavaScript frameworks, you should know, they were Angular, React, Svelte, and Vue,

 

Mm-hmm.

 

kind of an overview on those. And then we also wrote one on how you could build a headless WordPress with Vue, because we've done a lot of research on CMS and... The one that's being used the most obviously is WordPress, but according to Jamstack's survey, which we also wrote about, you know, popular CMSs, headless WordPress is the third most popular solution currently, and so if you wanted to, you could create a headless WordPress using Vue and all the great features that Vue has.

 

So, but that's something you would support. Again, going back to what you were talking before, is that something you sort of set up behind the scene because you don't have the UI for someone to host that? Or would they like host it somewhere else and just connect over the API with authentication and so on?

 

Yeah, that's more of what it is. Yep, so all your stuff, like WordPress is acting as your CMS behind the scenes.

 

Right.

 

And then we're hosting the view, the front end stuff. And then yeah, you're connecting to WordPress APIs behind the scenes.

 

wherever you have it hosted separately.

 

Yep.

 

Mm-hmm.

 

Okay, okay.

 

Yeah, and then obviously you have more flexibility with Vue than you do with WordPress. And, you know, you have to have a lot of plugins when you're using WordPress a lot of times. And sometimes those can fail. They're third-party plugins and stuff like that. So, you know, if you're really familiar with Vue, then you could probably build something more functional, more beautiful than, you know, the templates that you get at WordPress. So that's kind of the benefit there.

 

Yeah, I, you know, a little bit of background. I came from the Drupal world into view.

 

Mm-hmm.

 

Uh, and while I was there before I had quit working in it a few years ago, uh, doing the same thing with Drupal was a very, very, very big focus. Uh, Drupal sort of got dragged kicking and screaming into the head of space, but now they've with their latest, uh, versions they've, you know, wholeheartedly embraced it. And you know, have this Drupal. There's a buddy of mine has a company that focuses on e-commerce. for Drupal and they have headless stuff with React in view and they've done it themselves. So yeah, it's not just WordPress. You know, obviously I think WordPress has a third of the internet or something like

 

Mm-hmm.

 

Great.

 

that. So, you know, with those people out there, they're going to want to take advantage of that. But yeah, the CMS world is large in terms of headless CMSs that have exploded, you know, since Angular came on. So there are many, many tools out there other than WordPress for sure.

 

Mm-hmm.

 

who

 

I like,

 

enumerate

 

I use Prismic, you know, I've looked at other ones too. Prismic is one I'm just a little familiar with. But yeah, that gives you quite a lot of flexibility in terms of, you know, where you can go to host your data.

 

Yep, and you mentioned Netlify earlier. Netlify has a CMS. And so we have another blog on how to use a front end of your choice to connect to the Netlify CMS. And

 

Yeah, I

 

now

 

was just looking

 

you can host

 

at that.

 

it.

 

I saw that, yeah, for sure. Awesome, so any other features of Fathom you want to talk about? Any other tools or something you guys provide?

 

So on the platform, a lot of the stuff that we already mentioned, we help develop, automate, manage just all of your apps in the cloud. You know, all of the, we have the DevOps processes, you know, and CI CD pipelines for hosting, securing, scaling, continuously building and deploying your apps. You know, whether it's a GitHub build or an NPM package, you can use any version of those, you know, and so you're not always tied to the latest. You know, if I put out, you know, I push a new build and it, you know, everything, my GitHub actions run and you know, everything builds, I can deploy that latest version, you know, and fathom if I want to, but at any time, if I'm testing this stuff and it doesn't work out, I can roll back to a previous version. Another great thing that we love about our platform since everything is route-based, is you can set up a QA route in your production environment. And now you can do QA testing in your live production environment. And as long as you're not linking to any of those QA routes or paths on your main site, your end users have no idea that you're doing some of that front-end testing But now, you know, it avoids an entire integration environment that you might need to set up. And, you know, our QA team, it's just been hugely, you know, popular with them. Because again, they can choose any version that they want to deploy. They can deploy feature branches, you know, and it's just very much provides an environment so that you can, you know, test things in production with your production database and see how they're going to react with your front end. And then when you want to take it to production, you decide what version together.

 

Okay, so when you say testing, that means it sounds like what you're saying is that's what the user's actually seeing. It's almost like A-B testing, if that's an accurate term, but you're saying make your QA stuff available to your users and using them for the testing?

 

Well,

 

Or?

 

you definitely could do that and you know, we do a B test stuff, you know to see and we use more You know Google behind the scenes to do some of that a B testing like that's more I think on our marketing type stuff But I think more of like I can put let's say one of my engineers is working on an update to our dashboard and They're working off a feature branch when they push that feature branch up to github You know once all the builds complete we can come into our again if we're using fathom.com as an example then I could do slash QA and I could host their latest feature branch build on that QA path. You know, maybe it's dashboard test after that slash QA, now it's dashboard test. And I can point to their feature branch, any version, any build version of that feature branch, and now we can test it live. And our end users have no idea that it's there because those QA only the QA team manually has to type in those paths, you know, in their browser to get to them. And then once they verify and they give a thumbs up that everything tests out correctly, now we can, you know, the QA team can work with our, like our release team, and they can kind of show which ones they've given a thumbs up on, and our release team can now take those builds and put them into production, which our end users would then see and interact with.

 

Right, so you talk about CI, CD, so is that basically replacing something like a Travis CI or Circle CI? That's where they're actually running that through?

 

Yeah, you know, so it's continuous integration, continuous delivery. You know, some of that is with the GitHub actions, you know, so that every time someone does a, you know, a commit from their local, you know, we're, we're continuously building your, your code just to make sure that it's running correctly and that, you know, there's no build errors and things like that. And then, you know, we can have Fathom set up to. automatically grab that latest build for you if you want to have that continuous delivery. But that's where some of the beauty comes in is you can tell Fathom, no, I don't want you to automatically grab my latest stuff. I will manually go in and if I want to, I can update to the latest. And if I want to, I can roll back to a previous version.

 

Right. Okay. So now you mentioned GitHub. Do you all support other Git repositories like GitLab or Bitbucket?

 

We don't at the moment, it's on our roadmap. Today we support GitHub and MPM packages. And then as well as zip files, things like that, if you just want to bypass source control.

 

Right. Oh, okay.

 

And Jeremy, do we want to talk a little bit further about Fathom in the cloud and virtual developers?

 

Yeah, you know, we definitely can. You know, some of our virtual developers, we're just handling things that developers and more senior developers would have to handle, you know, behind the scenes, you know, especially up in Azure, you know? So I think it's, you know, setting up Azure resources, you know, configuring those resources, you know, all of the above. That's some of the stuff we're handling.

 

So you're saying that's what you're handling for these teams that normally their people would handle?

 

Yeah, yeah, and it's all stuff that, you know, our senior engineers were... You know, having to keep track of, and then as Microsoft would release updates to these tools, you know, our guys would have to get in there and level up, learn all the new features. And now we just have a couple members of our team that have to learn those things. And then they, you know, they write code that manages that stuff. And so now, the Fathom end users, you know, just have no idea about that stuff. You know, Microsoft could be releasing updates to Cosmos DB or to, you know, different, blob storage or whatever it might be. Now you as the end user, all that Cloud stuff is out of sight, out of mind, and we have code that automates all that stuff. Like Rich said, we refer to those as virtual developers, so that now you can extend your team with our virtual developers instead of having live developers on staff that are Azure experts.

 

So that so then your team can just focus on what they need to focus on

 

Yep, and

 

Exactly.

 

now we have a few guys that kind of have to get in and we always talk about those guys, the cloud experts, like they're dealing with that pain and suffering.

 

I

 

And

 

think

 

we

 

that's

 

used,

 

a good term.

 

it is, and we used to have to deal with that collectively as a team. And now it's just a couple of guys that, they love that stuff. They're reading all the Azure blogs and they're in all those forums and stuff. As things get released, they're eager to get in there and learn that stuff backwards and forwards. But where the rest of our team just wanted to use it, now the rest of our team can just use it and our virtual developers, our code behind the scenes can just manage all that stuff for us. Those people that do want to learn that stuff, they can. is open source so that you know people if they do want to get in and contribute or if they do want to get in and make changes to this stuff for their enterprise you know or for their company they can do that but you know for people that don't want to have to deal with some of that stuff they don't have to anymore

 

I know as a front-end developer I certainly would not complain about that, to put it mildly.

 

Oh man. And it's the same on the IoT side. We do the same on the IoT front. And it used to be a full-time job for me, you know, is just maintaining that infrastructure. You know, maybe IoT devices are connecting and they're sending too much data and maybe things go down or there's like a buildup in one of the resources because it's not scaled up enough to let enough data flow through. It's, you know, it's a 24-7 job to monitor that stuff. And now, not only on the hosting side, but on the IoT side, we have virtual developers that are running in code that can monitor that stuff, that can auto scale stuff up as needed. And it's just been a godsend. It's been great.

 

And since

 

Sick.

 

Jeremy said it, you know, just really quickly, Steve, I'm sorry to cut you

 

No,

 

off.

 

go ahead, go ahead.

 

on the iot side of things uh... our platforms called iot ensemble and you know it can be used by d i wires all the way up to enterprise level people or companies uh... and really you know if you're a d i wire you could be connecting your uh... spark fun little gadgets you know we wrote about how you could garden better with a soil moisture sensor from spark fun another boulder company or any you know there are multiple different to build that hardware and then you could connect up into IoT Ensemble to be able to retrieve all that data and similarly IoT Ensemble works with you know the enterprise level people on the industrial IoT side of things so manufacturing automation you know we've worked with breweries in Denver we used a temperature sensor that actually you know saved Crazy Mountain Brewery from their temperature wasn't correct in the middle of their brew process on the weekend when no one was there. Well, luckily our sensors, you know, sent them an alert through IOT Ensemble and you know, the brewers were able to come in on a Sunday, you know, and save that whole batch of beer that would have been wasted. And I mean, the, the examples are kind of endless in terms of how you could use IOT Ensemble for an enterprise level customer.

 

Actually, you just answered my question where I was going, because you

 

Hahaha.

 

had mentioned that you started out in the IoT world. So let me ask you this then. I think you mentioned this before, just to make sure. So Fathom basically came from wanting to provide the tools for your own people to handle their own front end deployments and

 

Yeah,

 

use cases. Is that correct?

 

it was very,

 

So in other words, you're scratching your own itch.

 

yep, yep, it was very like selfish in that sense. You know, we wanted these for our team to use. And then as we built them, we were like, well, we should offer these to other people because we know they have the same headaches. Again, the same pain and suffering that we were dealing with. We wanted to share the wealth in that sense.

 

That's really weird. I've never heard of that happening in the open source community

 

Ha ha ha 

 

before, so that's very unique.

 

Ha ha ha ha.

 

Anyway, excellent. Alright, so before we move to PIX, anything else you want to cover that you wanted to talk about?

 

Well, one quote that we like to use internally in our team, and again, it comes from that, the... the pain and suffering of doing some of the stuff in the cloud is that getting technology right is challenging, but getting it wrong is costly. And again, like we mentioned that $40,000 bill we got at one point, you know? Being a Microsoft partner, we were able to call up Microsoft and kind of like, you know, find a happy medium on that bill that they

 

Alright.

 

helped us work through. But you know, when you set up this cloud technology wrong, it can be costly, you know? And it can be something that scares people off and makes people want to, you know, the cloud and again being a Microsoft partner we want to help bring people to the cloud you know we want to make this stuff easy we want to help you control costs you know we want to help you get up in a shared environment so that you can test the waters a little bit and then you can start scaling out you know and having more confidence that you can do this for your company you know whether big or small but just in a more controlled way

 

Yeah, I can think of horror stories. I've heard of going back to AWS's early days and people were discovering scalable infrastructure and you only pay for what you use. And then you get some guy who's got some small app or website and he gets hit with a slash dot effect, if anybody remembers what that was.

 

Oh yeah, yep.

 

And all of a sudden he's got a bill for tens of thousands of dollars

 

Hahaha

 

because he didn't have any throttling in place and everything

 

Right?

 

just scaled up automatically. So. So I'd be willing to bet that most people handle that as well.

 

You know, it's

 

There's

 

scary.

 

safeguards for that.

 

Yeah, and it turns a lot of people off, you know, and it kind of, you know, was starting to turn our team off until we were, you know, getting better just wrangling it, you know, and learning where all those control checkpoints are. And, you know, as once we learn that stuff, we realize, well, now it's some of our senior guys that know how to do that. And if these guys leave our team, we're going to be in a bad place, you know, and so what we started finding it is, hey, the more that we can automate this via code. Now we're not tied to different team members, you know, team members can come and go. our company can keep going forward in the cloud. We're not losing that IP just because some of our senior engineers that knew this stuff forwards and backwards, now they're gone. Now we've abstracted it into code, which we call virtual developers that handle all this stuff for us.

 

That's also, I mean, that's basically infrastructure as code, right? Is

 

Yep,

 

that the

 

exactly.

 

same thing?

 

Yep.

 

Yeah, that's the first time I've heard the term virtual developers. I was thinking of a hologram sitting at a desk and typing

 

I know.

 

or something like that when you met virtual developers.

 

And I think that's some of the language that we use internally, you know, and we've started to share it in some of our blogs and stuff, but it's, you know, we've definitely kind of view Fathom, we use this stuff first, you know, we kind of use these terms, like we're using modular front ends instead of micro front ends, because like Rich said, we're not trying to bring everything together in one page. And so as we kind of come up with these things, we're just, you know, kind of putting them out in the wild and seeing what people think.

 

Excellent. Alrighty, well with that, we will move on to PICS. PICS are things that we like. We like to talk about that may or may not be tech related because we do have lives outside of tech. At least most of us do.

 

Right?

 

So I will let you guys go first because you mentioned that you had a couple things.

 

Yeah, Rich, do you want to kick it off?

 

Yeah, sure. So, you know, some of my picks, we talked about Jeremy and I in our preparation for this podcast. you know some of the TV shows we've been watching. My wife and I just finished Sopranos for the first time. Fantastic show. You know I've been binging on Star Trek Discovery. Big Trekkie, nerd myself. But you know I heard you Steve on one of your previous podcasts talk about the Mandalorian. And

 

Mm-hmm.

 

you know my wife and I just had our first baby. She's two weeks old and I recently just posted a picture of her

 

Ha ha ha ha.

 

Hahaha

 

like baby Yoda you know

 

Grogu,

 

so

 

right? I saw where

 

Yep.

 

that was going as soon as you mentioned that.

 

Ha ha ha ha ha ha ha.

 

so I definitely use the hashtags you know the child and Grogu

 

Hahaha

 

and all that so

 

Alright.

 

and as far as my dad joke goes like I said we just had our first baby and you know I gained some sympathy weight you know as one does and my friends are now saying man you have a dad bod but I just keep reminding him it's a father figure

 

Oh nice.

 

Absolutely, absolutely. That's a classic. That's a classic. Excellent.

 

One of my picks is again on the show side. I'm also a Trekkie and I've been getting into Star Trek Strange New Worlds. I don't know if anyone's watched that yet, but it's you know, there's a couple seasons out and it's a

 

Oh

 

great

 

really?

 

show.

 

Yeah,

 

Yeah.

 

my wife's a huge Trekkie, except she never really got into the original. But Next Generation and Discovery and Deep Space Nine and

 

Yep.

 

Mm-hmm.

 

she can tell you what episode is in the first minute just from having watched them so much. Enterprise, the one with Scott Baccala.

 

Yep, yep.

 

I liked that one because he was a former water polo player, which I was too, so I was like woohoo.

 

Hehehe

 

But yeah, she knows all of these. And so what's this new one called again? I'm sorry.

 

Yeah, Strange New Worlds.

 

Strange New Worlds, okay.

 

And it just came out, I believe it was this summer. And yeah, it's been great.

 

uh...

 

I have

 

okay

 

a couple episodes left of season two.

 

is it on paramount or where is it

 

It

 

you're

 

is,

 

watching

 

it's on Paramount. Yep.

 

okay paramount plus one of the multitude of streaming services out there right

 

Yep, yep, we have a number of them.

 

Excellent. All right. So for my picks, I will start with a shameless plug. Very shameless. I just, just this past week, Monday, as of this recording in mid August, the final chapter in my course on called Nux 3 Essentials was released by View Mastery. So kudos to the View Mastery team. Those guys are awesome. They put together a great product. very polished and in particular Shout out to Daniel Rowe who I've had on this podcast a couple times to talk about next three and what's going on since he Is part of the next core team. He was a huge help in Helping me make figure some things out with next three so that has been released and Bonus at the end of each episode not on YouTube. I don't know why but at least on view mastery I tell a dad joke at the end of each episode. We call them cringe-worthy dad jokes. So

 

Hahaha

 

Hehehe

 

Go check that out if you're interested. It's very basic With the idea that won't you get something basic then we can build on that later in later courses if we go down that road and now for the Dad jokes of the week You know, I'm I keep my eye on science science, you know and discoveries in particular astronomy cosmology that kind of stuff But I recently read about a new element that makes people around makes people around the element very serious, but unfortunately it's no joking matter.

 

Hahaha!

 

Hahaha.

 

Barão!

 

Right.

 

And my drum jokes died. Oh,

 

Oh no.

 

so bummed. Okay. Um, you were talking about sports, uh, and ironically, this is sort of, uh, relative or excuse me, relevant, excuse me, to Denver with their, with Russell Wilson, joining the team this year. Good thing.

 

Mhm.

 

Right.

 

Oh great.

 

Right.

 

Huge

 

Yep.

 

So what

 

thing.

 

do you write huge? So what do you call a person missing 75% of their spine?

 

Hmm. D'h-

 

A quarterback. And then.

 

Hahaha

 

And then finally, what is worse than raining cats and dogs? Anybody know?

 

Nope.

 

Hailing taxis.

 

Hahaha

 

Taxis, yes. And all my sound effects. So anyway, that is all we have for this episode of Views on View. Thank you to Jeremy and Rich for joining us and talking about Fathom. And I'm going to go spin it up and try it out myself here a little bit. And until next time, we'll talk to you on Views on View.

 

Awesome,

 

Fantastic.

 

thank you, Steve.

 

Thank you, Steve.