The Engineering Magic Behind Low Code Platforms with Alex Howard of Brandcast

Transcript

David: Would you state your full name, please.

Alex: MY full name is Alex Howard.

Ledge: Alex, it’s great to have you on, man. Thanks for joining us.

Alex: It’s great to have you on, too.

Ledge: Can you give a little quick two- to three-minute background about yourself and your work?

Alex: I grew up in a tiny little town in Ohio as a home-schooled little kid. I wasn’t super smart. And then, I found the computer for the first time and became obsessed with everything about it probably from the age of ten. I built a computer with my dad. He was an IT manager at a company so he would always bring home computer parts. And I remember constantly clicking around on everything. I just wanted to know what everything did and how it worked.

Eventually, I just got into little scripting languages like AutoIt. I remember writing automation for online games so that while I did my school, it could play the boring parts for me; and then, after school, I could play the fun parts.

From there, I discovered the web. I was like fifteen or something. I just remember it being so cool that you could open the code for any site that you found and just see how it worked. And I think that was during the day when jQuery was starting to get really big. So I got really involved in that.

I worked on random little freelance projects where I could and got really big in the jQuery IRC channel just helping everybody learn stuff, learning things there, and being super obsessed with that.

I ended up meeting this guy who was working at a startup in Austin, Texas and thinking that was the coolest thing ever. I helped him out with a few things.

They wanted me to move there and work with them but I was young and not ready to make a big move like that yet. But we reconnected years later and he suggested I come to San Francisco where he was.

I wasn’t really sure what I was doing with my life. I’d graduated from high school and just wasn’t sure I wanted to go to college or anything. I felt like I kind of knew what I wanted and that I should just go and work on it.

He suggested I come out here for basically a vacation which turned into me trying to find a job and, ironically, landing at Brandcast through his friend and that just kind of spiraled off into a weird never-ending path of jumping between startups and, ultimately, coming back to Brandcast for almost two years now.

I have sort of an interesting perspective on Brandcast. As a whole, web development has been my gem for a while. I did a lot of C# development and sort of other avenues but I always come back to the web.

Ledge: That’s awesome! Give a quick intro of Brandcast because I think the tools you, guys, are building are really the root of a great set of stories.

Alex: Definitely! Brandcast has been around for six years now and our goal has always really been the same thing. It’s all about having designers and marketers kind of freed up from the hassle of working with the developer. I mean, developers don’t really want to do this either but Brandcast is all about having that design freedom, being able to work like you normally would work.

You know what you want to make. You know what you want to design. You have ideas for animations. You have ideas for content.

In our app, you can just do anything that you come up with and kind of go crazy. By the end of it, you’ve published a real working website.

Generally, websites are really complicated, expensive, and slow. Everybody has got to rely on a developer who usually has much bigger problems to work on.

We’re software engineers and it’s not necessarily where we think our time could be best spent. So it’s really about building a tool that designers and marketers can work together, and developers get to focus on the piece that really matters to them.

Ledge: Before we jumped on the recording, you were talking about some of the interesting challenges you, guys, face from a scaling perspective and your contributions to really advancing React itself on the open source side to solve some of those problems.

Go ahead and tell a couple of those stories because I think the audience would love that.

Alex: Definitely! As a whole, this path we’re taking is a very difficult one. There’s a reason it has not necessarily been done before. So we’re taking on kind of a bit of a crazy task. We want to build websites in the web without a developer.

The CMS is great but you still need a developer anytime you change your template or whatever that thing is; or there are simpler static site generators that just use an existing template and you’re kind of limited there.

So we wanted to take the approach of “You can do anything you imagine and you never need to download anything just like you don’t want your customer to have to download anything.”

Obviously, that comes with some crazy challenges one of which was ─ we wanted this idea of “You have this super complex UI around your website that are just tools you can use to edit your website.” So the big focus is that you see your site as it will be. What you see is what you get and you can just directly interact with it.

That was actually a really big challenge because the browser doesn’t really have this concept of multi-context selection or anything of the sort. And React doesn’t lend itself to that either simply because that was not a need that they really had there.

So we sort of hit this wall of “Well, how do we have multiple context in which you can have different selections?”

And Iframe seemed like a good solution because it is, literally, another browser context. So we had to find a way to get React to let us do that.

I think right around that time, they had come out with what’s called a “portal.”

So you can have just any download anywhere, then you can kind of connect to it and render it sort of separate React tree to it. We thought that that would be a great solution but it didn’t work within Iframes and there were a few challenges around that.

So we started a fork off of React and kind of worked on that until it felt right and realized then that we needed to be able to drag and drop between those contexts as well because we ended up contributing back to both React and React DnD to make that a possibility.

What that really lets us do is we have a single React instance that can render to multiple contexts and there’s no cross-origin issue because the iframe isn’t actually loading something; we’re just using it as basically a render canvas but it all gets lifted up to the top.

It almost kind of fades away once you solve the problem. You just render a component that’s a frame and you can put any normal component you want inside of its children and it just renders it and you’re kind of good to go.

So once it was solved, it really faded away as an issue and we could just keep working the way we did normally which definitely helped us move a lot faster there.

I think we actually spent two years getting that back into React itself which happened just last year and that was a huge moment for us. Getting that in there was cool.

It was funny. I think this was also last year. We realized that let us do some more things like popping out different Windows because if we rendered it as an Iframe, why not also pop it out as a Windows.

We kind of keep moving closer and closer to feeling like a native app but inside of the browser which is definitely awesome.

Ledge: There are, obviously, endless solutions I can think off the top of my head for WYSIWYG and the precursors to what we now call “low code” and all these things. I’m always interested and I think our audience is.

That’s an interesting challenge because you really are creating a product to abstract out that creative experience and really kind of democratize the web building for everybody else. And I think there’s this misnomer now where you get the PopTech articles about how “no code” is going to eliminate engineering.

As you’re demonstrating ─ and I’m sure you can laugh about this with me ─ the engineering challenges of making that happen is more than a full-time effort for dozens of mind; and it sounds like the experience you, guys, had.

Alex: Absolutely! The funny thing is the only way you get to “no code” for somebody is by having a lot of code. Engineers are needed to reach that point. We just get to focus on what, in our minds, are the bigger, cooler challenges.

Honestly, it’s awesome. It’s the reason that I ultimately came back here. And it’s actually funny that you say “democratizing these areas.” That’s a term that’s been used since the inception of Brandcast internally.

Just to go back a little bit to the vision, we think teams are ─ marketing teams especially ─ are going to webify everything because if you could not have to have somebody download a PDF, wouldn’t you do that? If you could have insights on what parts they saw, if they could be responsive so it’s something you can share and know that if somebody opens it on mobile, it looks great and you can tell where they got tripped up or what links they follow, it’s like why not make this something that everybody does without a second thought?

Ledge: The first thing that pops into my mind is I’ve used a lot of these tools in passing and so many of them are clunky and slow and just the antithesis of a good experience. Walk me through some of the engineering challenges of making that work that right way.

I’ve been hurt, man, and people have been making that promise to me for years. How are you, guys, doing this?

Alex: There are a few things we can talk about that. I totally get being hurt by especially web apps. It’s a hard area to be performant. And I think React, Redux, Draft, and all these things have made that so much easier for us but, still, the scale at which we’re building this application is insane.

So we’ve built a bunch of internal tools for data memorization for when we need to select what parts of state ─ I mean, we, at any point, can have thousands of React components just for the sake of having the actual page itself and the whole UI around that depending on which panels you have opened at any moment. There are so many things where we have feature interplay and just massive numbers of components that all care about similar state in potentially different ways.

I guess, the first thing I’ll dive into is actually what we call “virtualization” which is super funny because, as everybody here will know, in React, you have the Virtual DOM. It’s already virtual. That’s the whole point. That’s where you get a big performance benefit.

But when you render a page that potentially has thousands of components ─ actually, I should give a little background on what our components are.

You build up your page as a set of components. So we sort of abstract the way from the designer or the marketer depending on who is in this; usually, it’s the designer, in this case.

They have containers. They have grids. They have text components. They have images, image galleries, that sort of thing. So it’s not quite the level of like a widget per se. Some of them definitely have a little bit more interaction going on there but you’re supposed to build up from sort of concrete building blocks, and then you can do any form of abstracting as well the CSS so you can do automation, whatnot.

So when you’re building up things that way, you end up with a lot of components on your page. We have this trend these days where we have much longer scrolling pages that are almost just made of slides.

That led to actually a really huge performance issue because when you have that many React components, you’re telling them, “Hey, the state changed. You should check if it matters to you” whereas the majority of them are like “We can’t care but we’re going to spend the time figuring that out” which Redux helps with a lot and memorization helps with a lot. But, still, you’re asking a thousand components to figure that out at a given moment.

So we actually built another virtualization layer just for this specific area on top of React where we let the first paths only render HTML and then we have a sort of an event layer on top of that depending on what you click on to activate or you start dragging something. We create and destroy React components as is fully necessary.

We have this, ironically, super simple logic that lets us have the whole page be HTML until you try to interact the part of it, and then it becomes a React component on the fly and starts reacting to state.

That was a huge performance benefit for a lot of customers that just had these massive pages. You never want to tell your customer, “Oh, just make more pages and you’ll be fine.”

Ledge: Just like “Install 64 gigs of RAM ─”

Alex: Exactly! And even then, that’s not even going to solve the problem because it’s a processing issue. With this virtualization thing, we actually led more to “Let’s use memory so that that’s not a problem.” It should work on any computer and you should be able to do this kind of stuff.

On top of that, we did this internal set of data and memorization tools that help us kind of on the fly select parts of our state that we need, and it kind of has this internal garbage collection that creates selectors on the fly. We actually use Redux selector; and then we built another layer on top of that where it will create and destroy selectors as they’re needed and let them be reused across different containers and components which is the coolest thing to conceptualize; and you do it and it sort of just, again, fades away.

So we keep building those layers of abstraction over these things for ourselves just so that they fall away and we get to focus on our UI and UX process which actually ─

I realize that I’m sort of just going crazy and talking a lot here. But we have a really unique UI/UX process in just the way we go about prototyping which, again ─ not to harp on about this but given how complex and just feature rich this application is and is going to continue growing into, we can’t really follow a super normal or a typical prototyping process where we just do design exploration and maybe use something like InVision where we can just connect all these different images together in a single linear flow because every feature we build has interplay with potentially ten other features we’ve built and might have interplay with the features we’re currently planning. And there’s that whole crazy complex web of features that work with each other in unique ways we can’t even imagine until we’ve built it.

We actually have a designer who works in CSS and HTML to prototype with us. For any given chunk of feature that we think we’re going to build, we actually do a design exploration followed by an in-code and app prototype phase where we just explore and try different things and see how they’re going to interact with other features which comes with its own crazy set of challenges, of course, but it’s “Let us build a set of features that works so well together that I don’t imagine we could ever have done otherwise.”

Ledge: With an application of this level of complexity, my mind goes to “What is your process for technical debt remediation?” because you need to sort of have imagined the data architecture and application architecture so far ahead that I imagine this comes up over and over again where you’ve painted yourself into a corner and you need to refactor but, always, there’s this demand on the backlog for new features.

How do you balance that workflow?

Alex: I can tell that you’ve been through everything we’re currently going through many times. That is definitely the biggest challenge that we have.

We sort of maintain this set of internal ongoing refactors because, a lot of times, you come up with ─ for example, our memorization approach there is built on top of a layer of things that we’ve been doing for two years already. So it’s not just this “Yes, let’s take a month and get to refactor this whole thing to be performant.”

We don’t only get to build these amazing abstraction layers that help us move faster or help us be more performant at the same time. We also have to think about “What is our plan making any old code, use that?”

And, just as you say, there is so much technical debt that you don’t just have a feature backlog; you’ve got this tech-debt backlog. And balancing those concerns is really tricky. I don’t think anybody has an easy answer for that problem but we find the balance.

As a whole ─ the company ─ we get to communicate that we’re building something crazy and just super complex. Everybody gets that. So we get to find this balance of spending the right amount of time working on our technical debt issues and finding a path where we don’t just spend the month doing it but we get to work towards it and actually make constant releases that are always improving.

So, a lot of times, we try to take the approach of “Let’s build a set of tools that we can use now and going forward and, as is possible, be able to go back and just bring forward old code to refactor and use these new approaches.”

It’s crazy.

Ledge: I know that you’re a frontend guy. What does the full stack look like for the solution? I’m sure you have to deal with sort of the abstraction of business logic and scale and horizontal, vertical ─ all these things. What does the front or back look like?

Alex: Definitely! Recently, we made the switch using GraphQL now which is awesome. That wasn’t around when we started; a lot of these things weren’t. So we’ve had this piece of technical debt, too. There are a lot of new open source things we would have leveraged should they have existed so we’re kind of transitioning as well.

But in terms of our full stack we have, obviously, React on the frontend; and then, our backend architecture is moving a lot more towards microservices because there are definitely smaller pieces of the backend that need to scale up as necessary. But the majority of the backend is written in Django.

We have our main microservice that actually is used for publishing which actually runs just on Node server for React. That was one of the big benefits where our pages are built up of just React components; and we really get to just reuse that whenever we want to publish a site.

So we actually just run a smaller set of our code in what we call the “processing server” which is actually just a huge set of Docker containers and everything. I think we’re switching over to Kubernetes right now and just being able to scale that up.

But when we publish a page, literally, it’s just “Hey, can you publish this for me?” and then it renders effectively what we render for a preview on the backend and spiff that out to an s3 bucket that ends up being.

We’re completely built on top of AWS infrastructure using SQS a lot and just kind of trying to spend that load. In the early days, it’s always that thing where you are moving really fast and you sort of forget to break out things into microservices and whatnot. I think Django has helped us do that a little bit moving forward as well.

But our infrastructure is almost fully using Docker, I believe, which is also great for development side. We basically had to run the same set of backend code and database and everything.

Ledge: The way you’re talking about your rendering makes me think there are immediate use cases for serverless. Are you going that direction at all?

Alex: Yes. I mean, we sort of thought of that, too. Given the on-demand nature, I think we’re a little concerned about making that switch but there are definitely going to be use cases where that would be really helpful.

A good example is ─ we have this feature called “Site Map.” Anytime you open a website, you get to see basically a tree structure of how your pages are all laid out which, again, is a nice abstraction. You don’t have to understand how HTML files have to be laid out in folders or anything or the sort.

A marketer can just build up this tree of pages. But we used to use Iframes for that section because “Hey, we can just render a preview for something given React components.”

Obviously, you run the same performance issue when you have massively long pages. So we had to spin up this thing that and we, basically, reused the processing server to render a thumbnail of any given page. And so, that just reused the server side rendering of React and just kind of on the fly generate thumbnail for everything.

But that’s one of those things where it doesn’t have to be instant and it doesn’t to be on demand and it also needs to automatically scale up as necessary. That’s definitely one of the areas, I think, serverless would be more beneficial to.

I think we’re kind of hesitant to just dive into a new technology that clearly has benefits and more trying to weigh the pros and cons of switching any given microservice into something like serverless or not.

Ledge: Last and favorite question of mine ─ obviously, we’re in the business of evaluating and sort of vetting and certifying just A-plus super senior engineers. We think we do that pretty well. We have a really good process for it and it’s been successful.

Yet, humbly, we always are out there sort of asking tech leaders we talk to, “What are your heuristics for the very best engineers that you want to add to your team and how do you measure and make sure that’s successful?”

Alex: Hiring is the most important thing any tech leader will ever do. Really, internally, for us, it’s like the first year, how passionate are they about what we are building and the challenges we have?

If somebody believes in the vision of Brandcast, that’s the first immediate indicator. And so many people do. It’s like why wouldn’t I not want to have to do this myself?

I don’t want to have to spend a crazy amount of time going back and forth with a designer or a marketer making constant changes, and then have to do that again next week just because we pivoted our marketing vision or whatever it is. There are always these small updates.

Our first focus is how passionate they are about what we are doing, and I think that’s something you would always hear from a startup.

On top of that, it’s “How interested are they in web technology and how up to date on these new technologies are they going to be as well? How eager are they to learn?”

As I’ve already mentioned, we have so many in-house things that we’ve had to do and open source contributions that we’re either working on or have done. That’s a huge piece and we actually want to take these internal things and get to open source them one day.

We really focus on “Is that the approach that our potential hires want to take with their careers?”

And then, as tech leadership, after hiring, your number one thing is being able to manage your team and see them through their career growth and make sure that they’re not getting moved into a leadership role that they may not have been interested in doing or don’t think that they’d be good at or whatever that is. It’s working with them to see that they get to do those things that they want while balancing the business needs and the products needs.

Especially as a startup, we use different pieces of different processes. So we do parts of Agile that work for us and we come you with our own things that work for us. I think it’s letting the whole team be as involved in that as possible and being transparent about “hey, we’re going to try these process changes and sort of see how they go and we want everybody to be giving constant feedback.”

So we maintain an internal repo that’s kind of like “This is the approach we’re taking to these things and you can make a port request request or even just a suggestion on any process that we do.”

I think that lets the whole team be more involved in how we get things done and the big picture in terms of the product that we’re building and all these things.

Ledge: We often find, at this point, that tech chops are just the cost of entry. It’s so much more about the soft and the qualitative aspects. And it does seem to be different for every company.

I think candidates would do well to evaluate that. And we do find that most senior developers are not going to say, “Hey, I just want a React gig. What is the project? Who will I be working with? What do they do?”

Alex: We don’t just want to engineer code. We want to engineer everything to be, sometimes, efficient to a fault. Our inherent approach to things is to make them better.

So we want everybody to be involved in problems, not just on the engineering side but also our product process and our business process, all of that. And that sort of leads to engineering everything and trying to make everything better and faster and all that which is, in my mind, super fun.

Ledge: How do people take a look at what you, guys, are doing and get in touch?

Alex: Our site is brandcast.com. I highly suggest you go check it. It’s awesome. You can actually sign up for free and play around with the app which is a great idea. It’s fun.

We love hearing suggestions as well. If you are interested in working with us, you can email us at HYPERLINK “mailto:[email protected]” [email protected]. And if you have any other questions or suggestions or anything, just hit us at HYPERLINK “mailto:[email protected]” [email protected].

Ledge: Awesome! Alex, it’s super cool to have you on, man. Thanks for sharing the stories.

Alex: Ledge, thank you very much. It was good talking to you, man.