Brian Cardarella (00:01.115)
Welcome everybody to another episode of the Dockyard Roundtable. Today we are lucky to have Chase Granberry here. He's the founder of Logflare. So Chase volunteered after I believe the last round, well, actually the first round table that we're doing these series of I'd say stakeholder interviews within companies and hearing about their experience of using Elixir.

And I kind of put it out there. Are there other companies that are interested in telling their story? And Chase, I think you were one of the first to volunteer. So thank you very much for that. But let's start with you. I want to hear about your background, your history in software development. What brought you to Elixir? And then we can move into the Logflare story.

Chase Granberry (00:41.258)
Yep.

Yeah.

Chase Granberry (00:57.054)
Yeah. Um, and, uh, I'm at Supabase right now. Supabase base acquired Logflare Yep. Um, yeah, yeah. The, uh, I've been, it's, uh, that happened like two years ago now and Logflare still is running and its own thing, but it's got Supabase owns it officially, but it's, it powers all of the. Um,

Brian Cardarella (01:03.124)
Oh, I'm sorry. Oh, well that's good then.

Chase Granberry (01:24.814)
And we ingest the logs and serve them to our customers, but we also use it like internally, um, to debug stuff.

Brian Cardarella (01:27.887)
Right. Are you primarily working on that product still or are you spread across a few things within Supabase?

Chase Granberry (01:34.926)
No, I manage, so I manage Logflare and we have, and the logs and that's a couple of devs that are working on that. The real-time service, which is Elixir, and that streams the wall to JavaScript clients, but we also have broadcast and presence that we provide via the real-time service.

And we are rolling out our, like basically PG bouncer replacement, which is called Supavisor And it's a multi-tenant Postgres pooler. And that's also written in Elixir. So I'm kind of managing all those things currently.

Brian Cardarella (02:24.003)
I see. Okay. Well, let's back up and start with your personal story. You know, where, where are you, you know, what your history is in the software development and how you came to Elixir.

Chase Granberry (02:34.026)
Yeah. Uh, so I, I bootstrapped, uh, a software company long time ago, um, 2009. And, um, that was, uh, like marketing software and we would help, uh, agencies report on basically SEO campaigns for clients. So a lot of our clients, a lot of our clients were, uh, interactive ad agencies. Um, a lot of e-commerce.

companies, we had some Fortune 500 stuff, but basically it was a software as a service. And, um, yeah, we, we did a lot of, we scraped Google basically a lot. Um, and that was initially written in and I, I started and grew that for. I don't know, 12 years, I think, or something like that. And at the end of it.

Um, everything was originally written in Ruby. And then, um, at the end of it, uh, we started migrating everything over to Elixir, uh, because it was, I don't know, probably primarily new and interesting at the time, um, but also showed promise for, um, just really the concurrency model that we were dealing with. You know, we have hundreds of instances.

running browsers basically, and then downloading those results to our database and just kind of managing all that is not the easiest in Ruby. So we looked at Elixir. My lead dev at the time was really the guy that kind of championed it. But a lot of the

A lot of what I really liked about it was that it was, uh, had Erlang underneath, right. And we had spent lots of years of, uh, I think we were on our third front end rewrite. This was like the rear, the, this was like the Angular to Ember to React sort of path. And it was very painful. And so I was very much, I was very much, um, uh, like the idea that, uh, you know,

Chase Granberry (04:53.13)
of Erlang and just that it's been around for so long and continues to be improved. Um, so, and, and Elixir seemed like, um, it seemed like, uh, like a great entry point into that. Um, and, and it also provided some, uh, basic building blocks, uh, like we were huge early adopters and users of Redis. Um, but Erlang has all this stuff built in. So like.

Brian Cardarella (05:21.295)
Yeah. So were you the one driving that decision at that company?

Chase Granberry (05:21.439)
We didn't ultimately need that.

Chase Granberry (05:26.994)
No, I was the, uh, I was actually the, like, I didn't even write any code at that point. I was basically everything except, um, support and like engineering. Um, so it was a small company and I think, uh, I ended up selling that. I think there was like six of us full time at the time. Um, and, um, so it was my lead, it was my lead engineer that, that

kind of brought it up and started the migration. But I mean, ultimately, like I had to understand everything really that was uh, going on and really like, like what we were going to see because of it. Right. Um,

Brian Cardarella (06:09.051)
Hmm. So this is interesting. So you were in a, you were in kind of like an observational position then of watching a company transition, uh, do that transition. So. You know, at that particular time, then were there concerns that you had on making a major technology stack change? Were there discussions internally that you were privy to and what were, what was the sentiment around that? Cause that was still pretty early Elixir days still to make that jump.

Chase Granberry (06:15.778)
Mm-hmm.

Chase Granberry (06:36.434)
Yeah, I mean, it was, yeah, it was, but it was, I mean, the guy that was leading that effort was, had been with me for many years and there was a lot of trust in that decision. But there was a lot of also, also a lot of communication just in the whole thing. It was like, why, you know, why even bother?

But the, that whole kind of infrastructure was pretty, um, modular also, so we could kind of like, just really do like pieces of it at a time. And so we could pull some stuff out, rewrite it and, um, you know, incrementally bring in Elixir versus having to do some like huge rewrite. Um, so.

Brian Cardarella (07:27.331)
Yeah. But it must have stuck with you, the outcome because you've been with Elixir ever since.

Chase Granberry (07:38.11)
Yeah. So after, um, so that was, we were pretty much done with that main rewrite when, um, when I sold, that was a company called Authority Labs When I sold that. And then, um, I had some downtime and I was just trying to figure out what to do. And, and, um, I mean, ultimately it was just, there was a few things that came together, like we had.

at Authority Labs, we spent a ton of money on logging and observability, um, the data dog at the time. And, uh, just through some conversations and, and some other things that basically ended up realizing that like CloudFlare had no sort of logging story. Um, you could get logs if you're on an enterprise plan. Uh, but other than that, you really didn't have any, and then they re then they just launched Workers and they had this like app store.

So I was like, oh, maybe, you know, if I can build a thing that gets these Cloudflare users like logs easily, um, that might be interesting and their app store might provide for some easy distribution. So we wouldn't really have to worry about marketing so much. Uh, and then really at the time it was like, um, I don't know, that's just the whole like demo Phoenix app with the chat stream at all.

I don't know, everything just kind of came together and I could kind of see a path towards a proof of concept. Um, and so really I just figured out how to get logs from Cloudflare Workers and figured out how to start ingesting them with a simple, uh, Phoenix app. And we weren't even storing them at the time. Um, but I basically like released that and it, people liked it and they

You know, it got some usage and, uh, so just, we weren't even storing the log at the time and so it just kind of kept going. Um, I just really, yeah, I just kept going with it. Uh, and there's also like a lot of new database. So I had to start storing stuff, but there's a lot of new databases. Burt, you know, with analytics, uh, style, like BigQuery and Clickhouse and stuff. And so I was like, okay, well, if I can store stuff cheaper, the now versus typical

Chase Granberry (10:00.418)
Um, elastic plunk stack, Splunk stacks, like that might be interesting for people. And, you know, it might be enough of a reason for people to move, you know, from a typical logging infrastructure to something like, uh, to something new really. Um, and. Yeah, I don't know. It was just, uh, I actually personally had never written Elixir at the time. Um, but I spent a couple of months just. Uh,

Brian Cardarella (10:15.076)
Mm.

Chase Granberry (10:30.97)
Like I had a lot of like high level knowledge about it because of what we were doing at Authority Labs. And so I knew what processes were in Erlang I knew what ETS was. I knew, you know, the benefits that were there. And so it felt like my kind of adoption of it was maybe a bit easier.

But yeah, I mean, it was fairly straightforward. In a couple of months, you know, I had a proof of concept and a little UI and it was, yeah, I mean, it was really easy to pick up, frankly.

Brian Cardarella (11:13.187)
Were there, if you had done this, well actually let's back up this way. What was your previous tech stack of choice prior to Elixir?

Chase Granberry (11:25.004)
Uh, I actually didn't have one because I actually didn't really write any code prior to Elixir. So.

Brian Cardarella (11:29.599)
Okay, so you're coming at this from a completely novel developer experience. You went from not having... To a developer. Is it down? Yeah. So you took a career backslide. Well, I mean, no, I mean, in terms of title, but you definitely, I mean, you went to a fairly quick acquisition then? Like, cause when was Logflare acquired? Cause it was founded 2019.

Chase Granberry (11:35.358)
I went from manager to developer basically, like engineering manager to like developer. Yeah.

Chase Granberry (11:54.804)
Yeah.

Uh, it was two years ago, so maybe two and a half at this point. Um, I'd worked on it for maybe I think a year and a half, um, before I joined Supabase, um, and it was, it was growing, but it was slow and I knew it was going to be a grind, um, at the current growth rate and the Cloudflare stuff while

driving signups wasn't driving paid users as quickly as I would have hoped. We also had like this Vercel marketplace integration. because they didn't have logs at the time. And that was driving some signups and then Supabase started becoming like a thing. And they'd actually used, they'd actually signed up for Logflare. One of the co-founders did.

And they were using it when they launched on Hacker News And it was a funny story because basically everything that they were using fell over or were rate limited to some degree, um, when they launched on Hacker News, except for their, except for their logs, which was, which was kind of cool. Um, and, but, but I, they had, I saw that they had, that they had signed up. And so I was.

kind of constantly pinging them every once in a while, like, hey, do you want to like, you know, like pay for Logflare and be a paying customer and like send all your logs to me and stuff. And just in that conversation came about like, well, do you just want to come do this at Supabase and help us grow Supabase and provide the logs to our customers? And so that's, that basically ended up making,

Brian Cardarella (13:41.327)
Mm.

Chase Granberry (13:50.858)
A bit more sense that it was a different journey that I never taken. I was bootstrapped everything. I was trying to bootstrap Logflare. Um, and they were going to the VC route and they are going to VC route and really want to build a large company. And so, uh, I really saw some opportunity in that experience and, um, yeah, it's been a lot of fun so far.

Brian Cardarella (14:15.234)
Um...

Brian Cardarella (14:18.375)
So was the acquisition desire from Supabase's part, was this simply because they had a need that you were meeting? Was it a trust based upon the tech stack or is it because they were already familiar with Elixir? I know they have a certain amount of open source work in Elixir, I presume a good amount of their infrastructure is in Elixir as well.

Chase Granberry (14:38.654)
It was actually, yeah, I mean, that's a good point because it was, I think, a little bit of all of that, the, they had already built, um, their initial version of the real time service, um, on Elixir. So they had like the real time server was, uh, written in Elixir and, uh, pulled in the Postgres right ahead log and just broadcast it to everybody. Um, so they had experience with Elixir.

Uh, they were interested in Logflare, I think because of that is one reason, but also, um, I mean, they, they wanted, they, they didn't have any sort of, uh, way for their users to see or view, uh, or search their logs at that time. Um, so they needed the feature basically. And, uh, it was done in Logflare. Um, and then.

I mean, ultimately, if you look at the log story on like a build versus buy scenario, it ends up being very compelling to build it because it's so expensive to buy it. And so in doing the log stuff in-house via a Logflare acquisition, they've saved millions of dollars basically, without having to use...

Brian Cardarella (16:02.277)
Mm.

Chase Granberry (16:05.986)
you know, Datadog logs or some other log, logging infra

Brian Cardarella (16:10.343)
Hmm. Have you thought about whether Logflare as a product would have been possible using a different tech stack? Was it just chance that Elixir worked out in this case, or do you think that this was just a matter of product market fit and Elixir wasn't so much part of that story?

Chase Granberry (16:35.338)
Um, I mean, anything's buildable and any other stack to the, for the most part, right? Um,

Brian Cardarella (16:43.148)
But I assume this was a one-man operation that you were able to get it to a particular point within a period of time.

Chase Granberry (16:45.714)
It was one minute. So it was one. Yeah. It was a one man operation. Um, we had logs streaming to the browser, you know, cause Pub/Sub was just a built in thing, um, and we had log streaming to the browser, you know, that was like, I had that work again, like two weeks. Um, and going from nothing to like.

like an advanced like modern feeling proof of concept. I think it would have taken a lot longer in another stack, for me at least.

Brian Cardarella (17:31.707)
And this was being built by someone without prior application building experience too.

Chase Granberry (17:38.082)
Yeah, yeah, literally first language was Elixir

Brian Cardarella (17:41.251)
Right. So what was your path for learning? Like what resources? Did you do any of the code schools or anything like that?

Chase Granberry (17:48.322)
Yeah, I did. Uh, I can't remember the guy. I can't remember the specific one at the time. I can find it again, but it was, um, it was basically like, uh, a $20 course. Um, on, on one of the, one of the things it was, it was a great, great course. And yeah. And I just did that. And it was after that, I pretty much had a proof of concept. Um, so

Yeah. I mean, the thing is, it's like, this could have been, I mean, you could write a, again, it's like with the proof of concepts, like.

I mean, it could have been built in any other stack really. I couldn't have scaled it nearly as easily or as quickly in any other stack, I don't think. And...

Chase Granberry (18:49.886)
Yeah, it's just, it just, I mean, and with like the feature set, it's just, it makes it so easy to do things that are otherwise so much more complex. Um, simply a lot of reasons is because of like the other technology that you would have to like reel in to do those things. Um, it's a whole other

Brian Cardarella (18:56.132)
Mm.

Chase Granberry (19:18.802)
It's a whole other you know, they talk about like the full stack developer these days, and it's just, it's so difficult for anybody to be full stack anymore because the depth of each technology, um, that you end up having to use, yeah, I mean, it really, it really does like to be an expert in any, in any part of the stack take what takes a lifetime, frankly. And so, um,

Brian Cardarella (19:35.087)
takes a lifetime at this point. It's, yeah.

Brian Cardarella (19:46.253)
Yeah.

Chase Granberry (19:49.53)
For me, it was like, it was like, I'd rather pick Erlang to become, you know, an expert in because that's, it gives you everything. Um, and rather than trying to have to be an expert in, um, 10 different Erlangs essentially, like, you know, um,

Brian Cardarella (20:10.695)
Yeah, yeah, that's like the kind of fragmentation that exists now on the jack of all trade position. I think is unfeasible to achieve. Like you have people that still go out and try to be generalists, but it's significantly more difficult than it used to be. You know, when I was first coming up, I first got started in web application development back in the mid to late 90s when I was a teenager. And

Back then it was like, okay, I just need to know a little bit HTML and CSS and I can just literally like FTP these files up the server and now they're accessible and nowadays it is a significant depth of knowledge and so like one of the value propositions I think that Elixir brings the table that a lot of companies have not really caught on to yet is that it consolidates

Chase Granberry (20:47.843)
Mm-hmm.

Brian Cardarella (21:02.747)
much of your tech, much of your stack under single technology, under a single language, under a single technology ecosystem. And so there's less of that kind of like context switching that you need to go out and now like find these other things. And we've been kind of focused on this as our general like value proposition to sell to companies, but it's, it is.

Chase Granberry (21:14.51)
Mm-hmm.

Brian Cardarella (21:29.335)
a fairly, a significantly different market than it was 20 years ago, even 10 years ago, because there are just so many choices out there nowadays too. That just amount in number of choices can be debilitating. I mean, it can give companies angst because their concern is that they are constantly having to reinvent their internal technology, like choice du jour

Chase Granberry (21:57.73)
Mm-hmm.

Brian Cardarella (22:00.652)
I mean, I don't want to just like dog on JS, but it's had the reputation, unfortunately, where every year or so you kind of have to reinvent in order to stay current. And something that I actually think is an undervalued value in Elixir, you've cited Erlang several times, is its stability, is its age. Erlang as an underlying infrastructure, 30 plus years old, great.

Chase Granberry (22:21.153)
Mm-hmm.

Brian Cardarella (22:29.019)
Good, I can learn this and I don't have to constantly relearn things every few years.

Chase Granberry (22:29.492)
Well.

Chase Granberry (22:33.062)
Yeah, we got to give Jose and the core team like a huge amount of credit for building on top of that in a way that keeps that story going on the Elixir side, right?

Brian Cardarella (22:37.68)
Oh yeah.

Brian Cardarella (22:48.499)
It makes it relevant too to modern developers. You know, like Erlang as a technology, I think has all of the checklist items on what's nice. It's just that the ergonomics of using that language have always been difficult for modern application developments to really get into. And along comes Elixir, and it solves that last mile issue, like brilliantly. The tool set being very mature. It's, you know, this is what's been kind of the...

Chase Granberry (22:51.297)
Mm-hmm.

Chase Granberry (23:10.562)
Mm-hmm.

Brian Cardarella (23:17.171)
question in the Elixir community is, you know, when. And I think for most people, it's not so much a matter of if, but a matter of when Elixir starts to reach a significantly higher level of adoption, because it solves a lot of the problems that I think a lot of companies are running into. But we also have a lot of copycat companies, right? They, they, they don't want to take the chance on something new. There are bigger companies that are using Elixir that aren't actively advertising it.

And so companies want to see like, Oh, Facebook's using this. So I should use that or Microsoft's using this. So I should use that. So that's why I like speaking to, uh, people like yourself that have had success using Elixir to share that story and hopefully influence others to actually, you know, have some, uh, data and some outcomes that they can take within their own organizations and say, Hey, this company did this with this, we should, you know, take a chance on it.

Chase Granberry (23:45.284)
Mm-hmm.

Brian Cardarella (24:14.495)
or to help them bite the bullet themselves. So given like...

Chase Granberry (24:21.182)
Yeah, it's like, it's like, how do we de risk it for people essentially? Right. I mean.

Brian Cardarella (24:24.047)
Yeah, yeah. Yeah. Given that, like what, that's exactly the right, I wanted to go down. You know, what, what for you were, might've been some difficult points of using Elixir, if any, or what do you foresee being some hurdles people may have that would need to be called out and maybe addressed on Elixir to increase adoption.

Chase Granberry (24:49.938)
Yeah, I think, I mean, I mean, there's a lot to organizationally. How do you break things up so that you can adopt things incrementally? Right. So, you know, how do we, how do we carve out a project or feature if we can even carve out a feature that Elixir can power. That's a lot of the issue too is just, you know, often things aren't

built in such a way that you can just carve a piece of it out and try out Elixir, right? I mean, it's getting better with microservices being more of a thing now, but I also just I don't like microservices very much. There's obviously a lot of a lot of everything's context dependent, right? But like

Chase Granberry (25:48.182)
But anyways, that's kind of a off topic, but I guess it's like, how do people de-risk it? How do people evaluate another technology and then ultimately de-risk it enough for their use case?

Brian Cardarella (26:07.868)
Mm-hmm.

Chase Granberry (26:11.018)
And I think a lot of, so a lot of the issues that maybe I'll just, I guess, kind of talk about some of the, some of the issues that we've faced. I think there's a lot of, and there's a lot of lack of skill, frankly, on my part as well on, um, you know, what do we do when we really start hitting, um, I guess, like scaling issues, how do we.

Uh, the, the observability story inside Erlang is, is very good, better than most, um, languages in that we get a lot, uh, with just processes and observer and, and everything like that, but there are still a lot of things, um, things that, that actually we're dealing with, like with the real time service and with kind of Logflare at the moment in terms of, uh, cluster communications and

Um, like, like we're hitting issues, just sending too much data over the, uh, distribution, um, TCP connection. Uh, or we're, we're running a global cluster, uh, for real time. And we have nodes on a single cluster that are all talking to each other and trying to broadcast stuff. And, um, it becomes more difficult when there's latency between nodes.

Brian Cardarella (27:16.711)
Mm.

Chase Granberry (27:34.878)
And, uh, communication ends up backing up and you get, you know, the disk busy port log messages, which I didn't even realize were a thing until, um, reading Erlang in Anger basically. And, um, and figuring out on like the last paragraph of the last couple of pages that was a thing and we should monitor for that. And it's easy to, it's easy to do and it's easy to see, but like, you know, until you really dig into that.

piece of it. And there's a ton about garbage collection that I don't know that we should probably be doing differently. So I think that's the stuff. And that's probably not any different than any other, like Java. You probably run into a bunch of garbage collection issues when you're really trying to optimize something that's written in Java and hitting

Brian Cardarella (28:31.913)
Mm.

Chase Granberry (28:33.998)
like real scale, but like real scale with services like that. Um, but yeah, I think, I think probably some of the things that have bit me are just like overusing communication inside of a cluster. Um, like, like with Logflare, we have like this rate limiter that's global. And we pass a bunch of data around and, um, it's, it's basically an eventually consistent like rate limiter.

Um, that knows how much traffic each customer and each quote unquote source is sending, um, and that works great, but it just, it's, it took a while to optimize because it's very chatty and there's also like a lot of, so then when you start doing that stuff, then you really start getting into like, um,

Brian Cardarella (29:21.823)
Yeah, yeah.

Chase Granberry (29:31.222)
You know, distributed systems, it's all just, it's all complex. I mean, the great thing about it, when you get into that, it's all complex, but like great that it, and the also, I think the problem is, um, you know, it seems to be, it's a lot of times it's talked about like a silver bullet, like, Oh, you know, use Erlang, it's, um, fault tolerant, scalable, blah, blah. Right. But I mean,

You can still write shitty code in early in Elixir. You know what I mean? Like it does.

Brian Cardarella (30:03.995)
Well, that's, that's what I was going to say is more often than not, more often than not, when we run into clients or if somebody comes to us with an Elixir scalability issue, it's typically an implementation that is trying to implement code the way that they do in another language and not, and not using Elixir's tool set to its advantage. Like there's, there's a way to write Elixir that in Erlang that

is the correct way where you're going to be really pushing as much work to the distributed processes as much as possible. So you get that performance benefit. I think sometimes the advertising, the language doesn't really convey that nuance. There are some people that I've spoken to just think that you get the scalability for free. It's not free, it's just significantly cheaper than it is in other languages in terms of time and implementation.

Chase Granberry (30:49.346)
Mm-hmm.

Chase Granberry (31:00.67)
Yes. And it gives you, it gives you the, I would say like low level tools to implement those things, right? But like, you still have to implement them and you still have to implement them like correctly, right? Otherwise.

Brian Cardarella (31:07.311)
Right, yeah. Yeah.

It's bad to write, it's easy to write bad Elixir at times. More often than not that we see this, those coming from Ruby, they're not used to having to manage multiple processes. They're used to working in that single thread. And it's not a difficult skill to teach out of. It's just something that I think Elixir could probably be doing a better job of.

Chase Granberry (31:15.166)
Yeah.

Brian Cardarella (31:36.859)
making people aware of. Because I run into companies and people that said we tried Elixir, it didn't work. It didn't meet the skill, like it was way worse than Ruby. I was like, well, how'd you write it? I mean, you can't just go out there and just throw everything into a single function and expect it to be fast. If you don't take advantage of what the language has to offer, then yeah, it's not going to be performant. But I do think that there are

Chase Granberry (31:48.282)
Hmm. Mm-hmm.

Brian Cardarella (32:06.375)
beyond just the performance, being able to reason about multiple processes becomes a less, I'd say, brain intensive exercise in Elixir than it has for me in other languages. Like when you start to get into the nuances of having to reason about any type of...

like leaking of data between processes and ensuring that the consistency of data, especially outside of the functional world. I mean, the functional world, it's less of a concern, but if you're getting into green threads, if you're getting into Java, where you have more kind of ability to manipulate the memory directly, or you're kind of in the driver's seat on deciding how this multi-process thing is gonna work, it almost feels like at times that when you are given more ability to have

decisions over that, you're going to get it wrong. Like it seems foolish to me to even consider writing any of the process distribution or the memory management or anything that you get for free in the actor model stuff basically, that you're getting for free out of Erlang Elixir.

Chase Granberry (33:06.391)
Mm-hmm.

Brian Cardarella (33:28.283)
going to another language and rewriting that from scratch. Like Ruby, I think is implementing an actor model or maybe it has already. It's like trying to back in some things that Elixir has brought in. Whether or not Elixir is influencing it, I don't know. But just having access to those tools is only part of the story. You need the like years of battle testing to ensure it's actually there. And there's few other languages that can really claim they have that.

Chase Granberry (33:50.006)
Mm-hmm.

Brian Cardarella (33:57.287)
have that level of kind of production level testing that Erlang does at this point.

Chase Granberry (34:01.438)
Yeah, our, you know, just talking about, I mean, the whole, just a general concept of processes is different in Erlang, right? And so, you know, our crawling infrastructure went from using Cron to fire up a bunch of Ruby processes, right? Which sometimes works, sometimes didn't. It was really hard to tell. Like, you know what I mean? Like I just had a chart that was like, oh guys, like something's wrong. Um, cause throughput was down.

And, um, you know, that versus actually being able to manage, you know, processes inside your code base is just a totally different experience, much better experience. Um, but yeah, unless you, I mean, unless you really understand it and put in the work to understand it and have had experience.

doing that because that's also a problem is that a lot of people on the web on the website is on the well oh yeah sorry can you hear them yeah we have chickens yeah I forgot that you can you can hear those I have calls sometimes like sometimes people bring them up and they don't bring them up that often I forget that you can hear them

Brian Cardarella (35:05.795)
Do I hear a chicken behind you?

Brian Cardarella (35:10.424)
I hear a chicken. That's cool.

Brian Cardarella (35:20.689)
Hahaha

Brian Cardarella (35:26.428)
Hehehehe

Chase Granberry (35:30.026)
The, uh, but yeah, so it's just like, it's just a totally different paradigm. And until you have experience with it, and even, even Elixir developers who kind of spend most of their time on like the Phoenix side, don't really have. The experience with like actually creating processes and handling exit signals and like supervision trees and stuff like that, right. Yeah.

Brian Cardarella (35:34.227)
Mm.

Brian Cardarella (35:50.039)
Yeah, I mean, Phoenix does a lot of that for us automatically, which is really nice. I mean, going even like to the web request, the huge benefit there right away is like in the Rails world or in other web frameworks, you kind of have to push that, like handling multiple requests concurrently into something on top of the web framework sometimes. Like in Rails, I actually have no idea if it still works this way, but early on in Rails world, you have to...

essentially launch a whole new instance of each application for every concurrent worker, effectively to handle the request response cycles. And that's just baked in for free with Phoenix. It can spoil you to a degree where if you're staying in just the web application framework world, then while you're getting the advantage of it, you're not directly exposed to it at times.

Doing more of what you are doing though is, it's pretty impressive that you did that without any prior programming experience, first of all. And then second of all, I do, because you don't have experience in other language, it would have been interesting to have heard a comparison between trying to say if you had done this in Java or done this like in Node.js. But my assumption is that it was gonna always be the easiest path for you with Elixir in terms of knowledge acquisition, time to market.

And then, I mean, finding Supabase as a potential acquisition partner, because they were already familiar with the technology. It seemed like it worked out really well for you.

Chase Granberry (37:29.93)
Yeah, it has. Um, and I mean, I have a lot of experience managing, like I'm, I was like, basically a foot short of writing code. I mean, essentially like we had an API product, so I sold our API product to customers and like supported their developers and they had issues. And you know what I mean? Like I knew I had a lot of. Just. Um.

I guess like just internet knowledge, you know, going into, into Logflare. So there's, you know, but one of the things, one of the things I think it did provide too was like, I didn't have to, I didn't have to make any decisions on the JavaScript side either. Like I didn't have to decide like what front end framework to use. Like, well, like, okay, I'm going to.

Brian Cardarella (38:24.838)
Yeah.

Chase Granberry (38:26.326)
you know, write a backend in something, you know, it probably would have been fairly straightforward to, um, to write something and go and pull in data and like, do what I'm doing with Elixir. But now I got to make a bunch of decisions about what to do on the front end. Um, and that's a difficult, it's just so huge and there's so many things going on there. Um,

that and not to say like, okay, well, I mean, if Elixir was as big as like JavaScript, would there be, you know, more things to navigate there? And, you know, maybe it's just a fact of the size of JavaScript, you know, that's just is what it is. But I just really liked, yeah, I mean, I don't know. It's just everything just kind of made sense.

for what I was trying to do with Logflare

Brian Cardarella (39:29.255)
So were you using LiveView as your UI framework?

Chase Granberry (39:33.886)
Uh, we initially, uh, LiveView either wasn't, there's some things where I'm just using channels, uh, even still just because I haven't rewritten it, but, um, uh, but the main log like search page, um, is written in LiveView. Um, and so you do a search and it pulls the, pulls in the background on the server and streams it to you.

Brian Cardarella (39:46.227)
Hmm.

Chase Granberry (39:59.27)
as they come in and so that's all written in LiveView and that was written on an early, we got into LiveView fairly early but it's been, I've you know, I've enjoyed it.

Brian Cardarella (40:08.211)
Mm.

Brian Cardarella (40:16.679)
Have you poked around at other clients? I'm always interested in people's kind of knowledge acquisition on LiveView because the priority model, and you're coming from like the unique position of maybe not being exposed to the nuances of single page application framework implementations in that whole landscape out there. So was LiveView pretty intuitive to learn?

as you're going, I know you're not, you can have a use of it, but was it like, Oh, this is some, a completely new animal or is this, Oh yeah, this makes sense. This aligns with how I've done everything else in the Elixir.

Chase Granberry (40:54.086)
I mean, it really, it aligned just because I knew it was a process. And I mean, at that point I was supervising processes for lots of different reasons. So it made sense. Um, you know, going back to

Chase Granberry (41:15.862)
You know, in terms of like a user of web applications, like I think that even though, um, you know, there's a downside, I guess, to LiveView because you got to go back to the server. Right. But like, in terms of JavaScript, like single page apps, um, I think they're very hard to write. Well, I actually personally haven't written one.

but as a user of them and as a manager of people who have written them, it's really difficult to get right. And you have to do all the same things you're doing on the backend on the front end in terms of state management and like syncing and like, you know, okay, well what happens in distributed systems? Like, okay, I've got state on my local client machine and I need to...

Brian Cardarella (41:52.388)
It is. Yeah.

Brian Cardarella (42:03.411)
Mm-hmm.

Chase Granberry (42:12.982)
get that state to the server. Um, and I have to make sure that gets there, but I don't want to wait until I re you know, the server responds to maybe some latency or something. So, I mean, you have to have a, you have to ultimately learn about all this stuff. Um, and have a, like a mental framework for it. If you're going to build a, an SPA that ends up being a great user experience and is fast.

Brian Cardarella (42:22.897)
Yeah.

Chase Granberry (42:42.722)
Um, well, and then if you want to build a great SPA that's fast. You also have to end up building a great backend that's fast because the backend has to be fast, you know, unless you're doing like optimistic updates, but, but very few people actually do that and do it like, well, right. Um, and so it's just like,

Brian Cardarella (42:51.089)
Hmm.

Brian Cardarella (42:59.907)
Yeah. So, so I'm in the, I'm in the fortunate position to have witnessed like the birth of LiveView. Um, it started at DockYard when Chris was still here and we, at the time, I actually, I should probably confirm, confirm this with him, but my assumption was that the, at the time DockYard was primarily an Ember JS shop. We were doing a significant amount of single page application development and we had

decided that Phoenix was going to be our backend. And we were using it primarily for API, like just a restful JSON API. And I think Chris was maybe attached to one or two client applications and saw this. And he got exposed to the complexity of the JS framework. I think in some way this motivated him to pursue LiveView,

Chase Granberry (43:34.135)
Mm-hmm.

Chase Granberry (43:38.113)
Mm-hmm.

Chase Granberry (43:56.317)
Mm-hmm.

Brian Cardarella (43:58.631)
Because he would constantly talk about wanting to burn like JS frameworks to the ground, things like that. Now that's kind of the same talking point he has with Flame on serverless. I can say this with a certain amount of certainty that in the JS world.

There is a, they seem to be attracted to complexity. And I'm someone that actually doesn't like complexity. I think the more complex the system becomes, the more opportunities there are for breaking and things that can go wrong. And then it takes more time and cost to ramp up new people. Like the amount of domain knowledge that gets into someone's head becomes invaluable. And this has always been one of the sticking points I've had with.

complex JavaScript frameworks was number one, the nature of JavaScript as a language itself was such that when it came to debugging, even now with all of the ability to like ship the original lines of code over to the browser and then, you know, be able to display these in the debugger, it's still really, really difficult to like adequately debug JavaScript applications to the point where we would spend majority of

And not like 90%, but I'd say over 50% of our application development time, just chasing bugs and trying to resolve them or in having to go deep into the, uh, the framework code itself. And then it, as you said, it's a, like a, you have to develop the application N times. And so if you are doing all that state management to a degree, if you're doing all of that data validation to a degree on a server, you kind of have to do this.

Chase Granberry (45:39.982)
Mm-hmm.

Brian Cardarella (45:49.623)
also again on the front. Yeah, and not to like pimp our, to push our product, but this is kind of why, big reason I've been pursuing LiveView Native as a product was because now we're hoping that same state management concern, the consolidation of managing state in one place will carry over to native application development so that you don't have to reproduce state management for the web, you don't have to reproduce it for Swift.

Chase Granberry (45:50.39)
You gotta do it, yeah, you gotta do it twice, yeah.

Chase Granberry (46:11.918)
Mm-hmm.

Brian Cardarella (46:17.479)
like each Swift device for each Jetpack device, for each WinUI 3, you just do it once and now you're adding templates. And so I think that whole kind of cycle of application development is one that is very well known within the Elixir community, but hasn't really broken through to a degree to larger development community. And I'm a bit...

Chase Granberry (46:21.838)
Mm-hmm.

Brian Cardarella (46:45.247)
Other than just like going out and trying to speak about it to those crowds directly, I don't know if those crowds are ready to hear this either, because you're talking to companies that have made significant financial investments in some sort of JavaScript framework to the tune of sometimes millions of dollars. And like, yeah, just get rid of that, rim-wrap that directory and start this over again. That's sometimes a conversation people don't want to hear. They'll stick with something because it's like infrastructure already.

Chase Granberry (47:11.395)
So.

Chase Granberry (47:14.682)
It's, it's really been interesting. Um, I want to say watching Supabase grow from the sidelines, even though like I work there, um, I feel very, I'm a bit disconnected from the front end, um, stuff because I work on like the Elixir stuff. Um,

But the adoption of and the growth of Supabase has been—and interest in it—has been incredible. And, um, I've really tried to understand why, and I don't think I fully do yet, but, um, I have some theories other than, you know, the initial kind of like marketing message was, um, uh, was the open source Firebase alternative. So like,

First areas, Firebase blows, great. We now have like a better version that is open source. But at the core of what Supabase offers is a restful API that's reflected from your database with a JavaScript client that basically just lets you do like write a, you know, select from.

country's table, filter by state or whatever you want, whatever you want. Basically that we have chosen to not A) write our own framework or pin ourselves to a certain front end JavaScript framework. A lot of the reason I think is, and I'm not involved in any of these decisions or this has all come from our founders.

Brian Cardarella (49:01.683)
Mm.

Chase Granberry (49:02.322)
Uh, and, um, and, uh, but basically like a, a lot of it's the, the model is simplified such that like, you just write a query, you write a, essentially, uh, Supabase JS, which is a Postgres JS query and it hits your database and you get your data back, data back, and you can list stuff and you can post stuff and you can.

patch stuff and you can, you integrate that with whatever framework that you want to use or not. You could literally use it straight from the browser just the same. And I think that at the core of it, for JavaScript devs, I think the simplicity really just of that mental model just really resonated with them because

the complexity of everything else in the ecosystem is so high. Um, and. You know, it just, it, it's, and I think, I think, I think that going back to your point, I mean, I think that people like Supabase, I think for the front end community like Supabase so much just because of, um, frankly, the simplicity of it more than anything.

Brian Cardarella (50:06.197)
Mm.

Brian Cardarella (50:29.699)
Yeah. Simple wins in the end, I think. Long term. All right, well, we're at time. Thank you very much for joining us. I greatly appreciate it. Do you want to have any last words before we sign off?

Chase Granberry (50:34.27)
Yeah.

Chase Granberry (50:47.378)
No, thanks for having me. I think this has been fun. Um, you know, we haven't, it's been an, I've enjoyed speaking to you. We, I think maybe have met like once, but otherwise I just kind of follow you on Twitter and so thanks for having me. Yeah. Uh, so it's been good to actually kind of like talk to you a little bit for sure.

Brian Cardarella (51:02.372)
Most of my rants on various non-related tech things.

Brian Cardarella (51:12.219)
Yeah, absolutely. All right, Chase, thank you very much.

Chase Granberry (51:14.742)
All right, thanks man, see you.