By Marcos Iglesias, Senior Software Engineer at Eventbrite, and Ryan Wholey, Software Engineer at Eventbrite.
Background & Stats:
- Eventbrite has processed more than $8B in Gross Ticket Sales (since inception), and over $3B in 2016 alone
- They process between 2-3 million tickets each week on Eventbrite
- They processed about 150 million tickets in 180 countries in 2016
- Millions of events use Eventbrite as their ticketing solution each year; in 2017 alone, they supported nearly 3 million events in 180 countries
- Britecharts was released back in April and is now one of the most popular D3.js-based libraries on GitHub
Check out their tech stack and open jobs on their profile
Yonas: All right, cool. Maybe we could just start off with quick background on both you guys. Where you're from? How'd you get here? And what you do at Eventbrite?
Ryan: Yeah. My name is Ryan, I grew up very local here. I started working at Eventbrite maybe a year and a half ago. Before that I was at a small tech company in northern San Francisco, that has gone under since I started there. I was doing mostly charting-related data visualizations for them, using D3. I think that's why I got hired here actually. To help my man on the left here, work on their charting library and the reporting parts of Eventbrite.
Marcos: Yeah. In my case, I'm Marcos Iglesias. I work here at Eventbrite, where I have been working almost three years already. I'm Spanish, I've been in the Bay Area on the barrier for five years. No, more than five years already.
I work with Ryan creating user interfaces and data visualizations for our event organizers. So when you create an event a Eventbrite and you sell some tickets, then you can come back to the organizer side of the website and check how are you doing? Where your attendees are coming from? How's your sales going? What kind of tickets did you sell? All that kind of stuff.
Y: Awesome. How is engineering organized? Is it front end, back end or is it product specific?
M: That's a great question.
It kind of evolves a little bit depending on the business objectives. But mainly we have a couple of back end and front end platform teams, or foundry teams, as we call them. [inaudible 00:02:40] in charge of creating the tools that we need in order to keep on working, like our development environments or our front and back end stacks.
We also have different feature teams, like us for example, that cover and hone a specific, sometimes really specific, sometimes really broad, part of our product. We will be small teams, one of those ‘Pizza teams’, it's called? Yeah. So we're maybe at the most eight people. We have a QA, a UX, a designer, a product manager, and then maybe four, five or six engineers. Maybe have half front end, back end. Usually a little bit more back end.
Y: Yeah. Okay.
M: More is like this.
Y: Okay.
M: I'm sure I'm missing something.
Y: Okay. Awesome. I'm sure you guys use a lot of different things, but what's the primary back end stack?
R: Back-end stack is Django. We've had some core contributors of Django lucky enough to work here at Eventbrite. We acquired a company called Lanyrd back in 2013.
Y: I know, I remember that.
R: Yeah. A few of those guys have made some huge contributions to Django when it was first starting out. So it was an easy choice for us here at Eventbrite to move in that direction because there's a vast knowledge of expertise on that side of the stack. Not only that, it's a pretty easy language to pick up for people just to come in and start working. So yeah, we have a little bit of legacy code hidden away, in some of those dark corners of our code base. But those are wrapped in Django interfaces and most of our stuff now is in Django.
Y: Gotcha. And database is MySQL?
R: MySQL. Mostly. We have a few other things floating around. We use a few Redis clusters, Elasticsearch for some of the aggregational queries that we're running. We're running Cassandra I think too. But mostly it's MySQL.
M: And Redis for some stuff as well.
R: Right, yeah.
Y: Okay, awesome. So you guys handle specifically the organizer side of the platform?
M: Yeah.
Y: Okay.
M: All of the reporting related stuff.
Y: So maybe you could just describe what that entails. You can create an event, you can offer tickets. Do you all do payments as well? Or is that a separate team-
M: No, that is a separate part of the system. Almost all of our work is based on something called the report service. That is grabbing all the order information and getting insights from it. It's the same service that our organizer app will use for example, our mobile app will use the same API's that we do on the web.
Y: Okay. So as an organizer I come in, I've already created an event but I want to see stats on how many people have registered, how many people have probably checked in-
M: Yeah. Also how many people visit your event page as well.
Y: Okay cool. How did Britecharts even come about?
M: The idea of Britecharts came from ... it was May, 2015 and we had a piece of D3 code in production. Someone created a line chart and started adding features and adding features and adding features to it.
And eventually it just became a huge file. It was a render function in a Backbone view that was more or less 500 lines of D3 code, all just in a row. So we get to a moment that we were actually unable to work with that. So we had to change our point of view and our approach to working with D3 code.
Our solution was to create a different repository, extract all that code out of our core repository and create a product that would be something that we at first, and later everybody at the company could work with. We always had a hope of open sourcing it in the future.
We created that piece of code and we committed to do it in a test driven development way. And keep it really, really clean, with a lot of options. Yeah, more of less, that's the beginning.
Y: Yeah. You mentioned Backbone. Are you guys using Backbone?
M: Yeah. Well, right now we are in the middle of a change of the stack in the front end. So we used Backbone with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux-style architecture, but with Marionette.
But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.
With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.
Y: Got you. So the evolution was Backbone, Marionette, and D3. Pure D3 with a bunch of, well 500 lines of extra magic. Then you're now moving to React, Redux, and Britecharts.
M: Well-
Y: Well, D3 as well, but Britecharts.
M: Yeah. More or less. The thing is that Britecharts was created from the point of view of just using it as a JavaScript-agnostic library. That worked really well with our Backbone builds. We just use a render and initialize all the stuff there.
Now moving into React, we have the necessity of actually moving Britecharts into React land. That's something we're gonna start working on in the next two weeks. That is a wrapper of our Britecharts in order to be used with React. And we are really excited about that.
Y: Oh, awesome. So Britecharts' React component. Very cool. What was the driver? I'm guessing you all were involved with that decision, but what was the driver for moving from Marionette and Backbone to React?
R: We found that there was some limitations with the speed of rendering and the ability of our components to branch out across component with Marionette, just the way that it was.
If you've worked with Marionette and Backbone you're familiar with the idea that everything is sending events to some other place across the code base and it immediately as soon as it gets past a certain point, gets unwieldy to work with in large scale applications.
So the hope was to move to something like React, which has a much smaller API than something like Marionette. Which is exciting for developers to work with. Like I said small API with the idea that when these complicated applications that need to be built, when that happens where you can use something like Redux. Which will hopefully simplify the front end, back end portion of it. The data driven portion of the view layer. That was the goal there really. Is to be able to move quicker down the road.
Y: Got you. What was the first section of the app? Or portion, feature/product that started to use React? Was it the charts?
R: No. I think-
M: Was it the login?
R: Maybe it was the login.
Yeah, I think the first production-wide page that went live very recently, a couple months ago, was our login page. So nothing too crazy on the front end. I think that was the first 100% live production page.
We do have another create event flow that's been in development for maybe the last year or so that is still ... I think it's rolled out to maybe 10% of our organizers that have opted into it. We're testing it out, making sure all the kinks are out of our new system.
We really want to make sure that our SEO doesn't drop at all with React. So we're rending on the server side, which introduces another layer of complexity that we didn't have before with Marionette. We're just making sure all of our ducks are in a row before we pull that ripcord for React.
Y: Yeah. What are you guys using for server-side rendering? I'm sure there's a bunch of prebuilt stuff.
M: I'm not super, super familiar with it, but we know. Our back end is Python so we couldn't run Node just by itself. So what some of our peers figured out was that let's create a service that runs Node and that can do the renders for ourselves.
So our Python back end, we say, "Okay, I gonna send you this context object with data and I will send you this application. And you will give me back a string of render markup that we will use to render on the server."
R: Actually I think it's just HTML.
M: It's HTML right.
Y: Oh, okay. Gotcha.
M: So we use it as a service that actually renders out someplace.
R: I think I've seen it diagrammed as a sidecar like architecture. Where we have just a, like you said, a service that we just request HTML from and we set it directly on the client's page.
Y: Got you. Okay. Makes sense. Cool. So coming back to Britecharts, what was the problem that it solved for you guys? What did you guys end up building on top of D3 specifically?
M: The good thing that Britecharts offers is that we move into this world of components as well. Like on React. Before we had really one-off things, so we will have this chart that works here and that's it. There's no API for that element, it's just a one off thing.
Right now we can take the same chart and we use the same chart in different places in our website. Also we have different small auxiliary charts. We can say like legend. We have different type of tool tips. We can stack those in and out depending of our necessities in each different case. So that was a big win.
Also having all that tested and in a continuous integration and platform. That gives you a lot of confidence over the code as you're using that.
Y: Okay. So it sounds like the main benefit is that it helps you sort of componentize your different visualizations?
M: Yeah.
R: And test it.
M: Testing on this is really not a trivial thing. It's kind of tweaky and it changes the way that you approach the whole thing.
Y: Got you. Okay. Are you now using Britecharts across all of your charting? Or are you still migrating some of that over?
M: Yeah. Well, we have some sections of charts that are really, really old and that we are trying to deprecate. So we can say that if we build something new, we only use Britecharts.
But still you will find some chart, some really old charts, some here and there. I don't know. You would actually need to dive deep into the code for those. We're really trying to hard to get rid of those.
R: Yeah.
Y: Okay. But for the most part, what a user can see now is pretty much powered by Britecharts?
M: I would say so, yup.
R: Absolutely, yeah.
Y: Okay. Ryan, I guess from your perspective, was Britecharts kind of like an obvious thing to you? As like, "Oh, this makes a lot of sense." Or was it just something brand new that you were like, "Oh, never thought of this before."
R: I think that the benefits for it, there was many. I guess totally was an easy choice 'cause if we open source that we have people contributing and giving their input into this code base. So we have a wider developer base for it. We have the testing.
Since we are the owners of it basically we can release it whenever we want. Someone when we first released Britecharts asked us, "Why didn't we contribute to something like Highcharts?"
Y: Oh.
R: Some other charting library instead. For us, it's easy. We need control over not only the release process, but the look and the feel of the charts. Our designers are very specific and they're very talented. Something like Highcharts where we're trying to delve into the API of some other charting library to add our styles in, it's just not gonna work out well for us.
So compatibility with our work style here. The testing was a huge thing for us. The modularity of the charts. It seemed like an easy solution for us.
Y: Yeah. I'm sure someone probably brought up the idea of forking too, right? Why not fork D3 itself or Highcharts?
R: Yeah. At the time when this was conceived, there wasn't a great library that was tested.
Y: Gotcha.
R: I think that there was some good research done and we couldn't really find one that was a satisfactory, fully test-driven environment. So that was big for us. It was either add testing to another library or just create our own.
M: Also we were limited in the sense that we had something that was working in production at that time.
Y: Oh, you mean the code, essentially everything you had added on top of D3 was already in production?
M: Yeah. Just one chart. The line chart was something that was already in production. So we had to move into something different, but we need to keep that thing there. So we actually we factored that thing until it just met our standards. And that was the first chart of Britecharts.
Shout out to all our contributors on Britecharts, it has been an amazing trip in that sense because yeah, they have helped us so much. I guess we didn't expect that much help from outside people. People find bugs and fix them themselves.
There have been people creating new charts from scratch and doing a great job on that. So yeah, we want to make the most of this to say thanks to all those contributors.
Y: Yeah. No, it's awesome. Looks like you have over 20 contributors. Can't see how many times it's been forked, but it looks like it's been really popular. Sounds like something the D3 community really needed.
As far as v2, anything you want to mention that's new with v2? 'Cause I know you guys just released that.
M: Yeah. With v2, what happened was that we noticed that we had ... even if we had a good amount of charts, we still are far from having all the charts that are needed at this point. So we knew that we had to grow.
From feedback from our contributors, they're saying that sometimes we didn't choose the right names for the API. And sometimes something that was doing the same thing in one chart was called that one way and in another was called in a different way.
So the idea was to make all these more consistent. For that we created these API guidelines document where we talk a little bit about how the API will look like and will be named.
Because actually one of the main pain points is naming. Naming is really hard. So even in ourself, we struggle, what do we call this? Do we say itthis way? Or that way? Or this word first? This word last? Y: One of the big computer science problems, yeah.
M: Yeah. So, we got a screenshot of all the API's from our documentation and we say, "Okay, what is matching here? What is not matching? What makes sense? What doesn't?" And we created a document saying for example, if it's a boolean, then it needs to start with is, has, should. Or if it talks about the ticks of the charts then it needs to have ticks at the end. This kind of stuff.
We created that document. We circled it around. We agreed on that. Then we refactor it so that every chart will have this consistent API. That's mainly the version two. It also added a couple of new charts by the contributors and some bug fixes.
But yeah, we're sorry for some of our users because we are actually breaking their charts because the old accessors don't work. But I think we are now a lot more confident that we can grow more and that people can contribute to it by just reading those API guidelines, they will be good. They will do it a lot better.
Y: Awesome. All right. I guess before we wrap up, how many front end engineers are now at the company?
M: That's a great question.
Y: Ballpark?
R: 35, 40, maybe.
M: No, a little less maybe?
R: Maybe less.
M: So we can say that maybe 15 pure front ends. Then we will have another 15 that can really work with the front end. But they also work with the back end.
Y: And that's out of what? Maybe 100 engineers?
R: We have more than 180 product, engineering, and design people globally. We have offices in San Francisco, Mendoza, and Nashville, which are heavily engineered. We have other offices around the world, but those are where our engineers mostly work out of.
M: Also, we just completed our aquisition of Ticketfly from Pandora.
Y: Ah, cool!
M: So we're in the process of integrating the Ticketfly team that is also here in San Francisco.
Y: I guess I was just mentioning that to say I'm assuming you guys are hiring front end engineers-
M: Yeah, sure, we are always hiring really good people. Specifically we're hiring a senior, front end engineer who's good with data visualization so if you're interested in Britecharts, please hit us up on our site or check out our listings here on StackShare.
4
1377
