Ep. #45, Embedded APIs with Startup Mentor Jeremy Glassenberg

Brian Douglas: Welcome to another installment of JAMstack Radio. In the house we've got Jeremy Glassenberg .

Jeremy Glassenberg: Thank you. It's good to be here.

Brian: Cool. So Jeremy, we chatted-- Actually, we had an introduction here at Heavybit.

You have specific background and knowledge around products and APIs, do you want to talk about your background and why you're here today?

Jeremy: Yeah. Basically, I've been working in the world of product management for a little over 11 years, and for a little over 13 years I've had just a crazy, irrational obsession with APIs.

That combination brought me over to Heavybit over time, but basically if we start in the beginning I had just gotten really interested in the idea of the web as an OS while back in college.

Some of us remember iGoogle, it was basically this customized dashboard that Google had where you iframed in a bunch of third party things on to one web page.

I was interested in actually making what is now called a web top. It's basically iGoogle on caffeine. A web page that looks like a desktop operating system.

Brian: Gotcha.

Jeremy: If we're into the whole idea of just the web as an OS, you can do everything on the web.

You could install third party apps in this web page and you would just iframe things in, run some JavaScript, but basically run everything from one web page.

The idea was interesting, more interesting that it was valuable, so I had enough sense not to actually build this.

Others attempted it and I think they saw the same results. People liked the idea, but the user experience really didn't make sense.

While I was still really into the idea of just bringing everything onto the web and letting everything work off the web, the web as an OS wasn't going to be like a desktop operating system, it was going to be in services talking to each other.

I just started hacking away at random APIs while at the same time being on this academic trajectory to become a product manager, which back then was to get your engineering degree and then go and get an MBA. We don't need that anymore in product managers, but that's another topic.

But that was the path I took to basically find my way into product management while still being really tacking trying out whatever web API I could find back in 2006-2007.

I found my way over to Craigslist, a job listing for this startup that I hadn't heard of before. That was Box, where I basically got--

Brian: I've heard of them.

Jeremy: It was the first time I got to actually see a product management job that was specifically for APIs, and so that was it for the next eleven years.

I've just been doing the product management thing, building web APIs and other developer-facing tools.

Naturally that progressed to make my way over to Heavybit, I have been mentoring other accelerators and advising companies on product strategy and platform strategy, and eventually that just--

I kept running into Heavybit. One of the companies I advise found their way over here, it was Moesif, and as Heavybit expanded to be interested in addition to marketing for platforms they were interested in product as well. So, here we are.

Brian: Yeah. Literally, here we are. The industry has really woken up to APIs and APIs as a product.

I know you have a few blog posts and a few conversations out there publicly that listeners could totally find out and check it out, definitely mention those within the conversation.

But I'm curious of how do we get to this point where now we can actually have pieces of products embedded to other products, and how did we get here?

What is the world that we're living in today?

Jeremy: This has been a recent topic of interest for me, and actually it's been a longtime topic of interest, it's just now there's more general interest in the market and I get to talk about it a lot more.

I've advocated in the past just treating APIs as a product problem.

A lot of people have been advocating that, and that's allowed for better trends and not only the rise in APIs, but the rise in successful APIs that are actually usable.

Now when I talked earlier about my interest in iGoogle, that was an example of bringing third parties into your interface. In iGoogle's case it faded out over time.

When I started getting into APIs and working at Box back in 2008, we saw other attempts at these UI-embedded integrations where besides external APIs these were platforms that fundamentally allowed third parties to just fit right into their interface.

Facebook had Facebook Canvas, LinkedIn and there's a company called Ning, only a few people remember that one.

But there were a handful of these companies in the social networking space that adopted open social, and they were allowing third parties to create these apps that could be embedded on their users profiles.

There was a time when this all happened when I was still obsessed with the whole idea of the web as an OS.

That all faded out, really nothing worked back then, but there's a rise in it now.

So now besides just writing about the usual "Treat APIs as a product problem," I get to start advising more on the strategy of those embedded frameworks.

Brian: Yeah. I think in our conversations you mentioned you had some experience with AMP and working with that.

Would this fall within the world of embedded frameworks? I know that's very SEO heavy and maybe quite different from what we're talking about.

Jeremy: AMP-- It's coming up. What we've historically seen when it came to these embedded frameworks is iframing.

Brian: OK.

Jeremy: The easiest way to just let another web page get plugged in. There are a lot of different ways to make it work, Salesforce has Apex, Salesforce Lightning.

There are other platforms that allow server-side code to be hosted in their frameworks, or they create a new markup language and shell out some very custom integrations baked very deeply into their system, but the client's side code can be hosted in their system.

There's been a lot of attempts at making this work, and AMP is coming up. We can talk about that a little bit later in this, but basically it may solve a lot of problems.

I'm not seeing it adopted heavily just yet, but it is something that the successful platform providers are all thinking about.

Brian: Gotcha. So, what's the entry point into embedding in these embed frameworks?

Because I know with things-- You mentioned iGoogle, there might be some learning curve.

I know with Lightning you have to learn the Salesforce way and their interaction with the framework.

Now we have Electron where now you can embed that into your Mac OS, or now Windows at this point now.

You can embed that as a little dropdown in your taskbar. Is there the Electron for embedding on the web today?

Are we-- What are we talking about here?

Jeremy: We're starting to get there. It actually starts from a tech standpoint, often just with iframing the old system.

It's still pretty common among the newer platforms, the biggest difference I'm seeing today from what we saw 10-12 years ago in these temps, it's one of my opinions for the reason why we started to see more success in the use of APIs a little bit after the 2009 API craze.

That's because just as we're treating API as a product problem today, we're starting to treat the embed frameworks the same way.

At the time that embed frameworks were starting to get popular, APIs were also generally getting popular and there was a bit of this "Built by engineers, for engineers" mentality.

Which there's nothing necessarily wrong with that, but if they weren't treating this the same way they were treating other product problems, which is namely "Understand your customer, understand your personas, understand their pain points and the problems that they have, and how are we going to solve them?"

As opposed to "We're going to build a bunch of features that we think are really cool."

If you apply the proper product process in general you have product market fit. So APIs struggled in their early days, a lot of companies just built APIs because they saw other API companies being successful .

After they actually said, "Let's only build API s when we see a customer need, and let's design them according to the needs of our partners," APIs started to get successful.

During that time, the iframe embedded experience just went dark. But they're coming back now, and where I'm seeing success, it's the companies that understand to treat this like a product problem.

In API world, it's "Your customer is the developer. What are the apps they're going to build, and how do we make it as easy as possible for them to integrate?"

When it comes these embedded integrations with third parties, no matter what, you're going to have more than one persona.

You're going to have the developers who are building these integrations, and you're also going to have the customer, the consumer-- Someone who's experiencing this in your UI.

If you look at companies like Stripe and Twilio that have great APIs, they were fundamentally developer-facing.

Where we see these embed experiences, they're usually in companies that have a core consumer user-facing product with a complementary developer platform.

So, you now have to think through "What are the problems that my primary customer has that are going to be solved by third parties?"

And then, "How do we make it as easy as possible for that to happen?"

When you think about it that way, it's not just about throwing iframes in places that you think are cool, it's placing them where you can tell that there could be a good story to solve real customer problems.

Brian: Do you have an example of someone who's done this correctly that people can maybe take a look at and admire?

Jeremy: Everyone who I'm going to highlight here are emphatic that they're still experimenting, but I think Trello and Shopify are great examples of applying this tactic.

They're using iframes, they're trying out other things, and you can tell that they've positioned in their interface very intelligently places where it just makes sense for third parties to fit with their customer experience.

Brian: Interesting. My entry into the web and actually web development-- I've used the web for a long time, not since inception, but for a very long time.

My intro to web development was shortly after this API craze. But I've always gotten my hand slapped when it's like, "Maybe we can do an iframe. "

And embed this thing in part of our product to try something out, and usually because I didn't come through that experience and maybe when it was not as great as today, I've always had "Let's not go that route."

So are we at this point as developers that we can actually push back and say "No, but we can try this. Performance is not going to take a huge hit. There are frameworks that we can leverage to get us most of the way there."

Jeremy: There are alternatives to iframes, but I find that iframes are still popular.

Things have improved in addition to the user experience on the technology front to make iframes more feasible.

I find it's the easiest place to start, but the top platforms are also thinking of other options.

If we look at iframes in particular, when we treat this as a product problem rather than do the iGoogle model which was a simple page, things are just iframed there.

I've seen very commonly the iframing just happening in a dashboard, or the app is in a sidebar.

What if you're in the world of invoicing and you want to provide payment options in the invoicing interface? You're going to now enable a hook in the invoicing interface.

So companies are thinking through "Where do things fit?" In Trello's case, there are apps that work on a project board but there are also apps that just fit into a single project card.

So they decide "Where do these things happen?" And that can still happen with iframes combined with user experience and letting the developers know where their iframes can fit, but there are alternative technologies.

Sorry I'm bouncing around a bit here, but if we stay on the iframe what has improved in addition to thinking through the user experience, there have been performance improvements.

Namely, computers are faster now. In the past, platforms were in fact shut down because the owners of the pages were just taking too long to load or crashing if there were more than three apps installed by a user.

So certain platforms were designed so that only one app could load at a time, but it was still limiting. There were also security concerns, and there still are.

There are new restrictions you can't apply on your cross-site scripting has been restricted, requirement for SSL. If your site is SSL, the iframe has to be SSL.

That actually didn't exist back in 2006-2008.

Brian: Yeah, I believe it.

Jeremy: So there are other security holes and new rules you can apply to iframes now that give a little bit more power.

But there still is that concern that you're allowing a third party to run scripts that could either cause a performance issue, or there are other security implications, intentional or either malicious or unintentional and accidental.

You also have to consider, besides the issue of performance and security, people aren't just using your service on the web anymore.

Mobile apps are very popular and iframing as an experience just doesn't work that well on mobile, so that's forced platform providers to think of alternatives as examples.

At Gmail they don't have iframing for their add-ons program.

They have "Cards", which is basically you're allowed to use a certain set of buttons and input options, a very limited set of UI items that were defined by Google, you're not allowed to just write JavaScript that runs right in the client side.

Now I've spoken with some members of the team and along with others who've actually gone the card route, the reasons for these cards are both usability and security.

Sometimes a security team just says "Absolutely not" for iframes, but quite consistently they also say "This is the only way we're going to make the platform work on mobile."

It's limiting, we're really restricting what developers can do with the UI, but on the plus we're allowing the partners to actually run these apps within a mobile application.

That's very new. If you have a Gmail add-on today, when you open up the Gmail app on mobile you can actually run these third party apps on mobile.

Brian: OK. I've been pretty far removed from the Gmail app for sure. I've been on a tear trying out since-- Basically since Dropbox is a mail app.

I forgot what it's called, they shut that down. I've been trying every single email app known to man since then and haven't touched Gmail in a while.

But I remember back in the day I had add-ons for almost everything. You have the add-on for LinkedIn where you can actually--

When someone emails you, you can see their LinkedIn profile directly in Gmail.

It's interesting that they have an embeddable framework on Gmail, which are these things called "Cards."

It brings me to my next question, today is the day on Twitter I saw Figma announce their integrations platform so you could integrate within Figma.

Figma being the design tool, I don't use it very often.

Mainly designers show me what it looks like and I mirror what's in there, but what I'm getting at is there's a bit of a focus on tools becoming platforms to have integrators on there.

Zite was one that came out a few weeks ago, I know Netlify has their platform as well, and obviously Heroku add-ons and Gmail add-ons.

Everybody's having some integration platform, and then they have these large developer conferences eventually. So, where do we stand between?

Do we do embeddable frameworks and have people embed onto their platform, or do you do API integrations or is the world all the same?

Like, is there really no difference? What's your opinion on that?

Jeremy: From a technology standpoint, you're not going to have these embedded integrations work unless you have a good set of API.

Now to make your Platform work really well, you're going to have a set of custom APIs that work only really with these integrations.

For instance, when I was back at Box, we had a system where you would right click on a file and edit it in Google Docs.

You could right click on an image and edit an image header, send a file to DocuSign.

Those third parties had to be able to send the files back into Box, so we had these special overwrite APIs to overwrite a specific file, and Scopes for our tokens so that when these apps were run they only had access to that file and not anything else in the user's account.

So from a tech standpoint, they're going to overlap. Now we do have to think through use cases here, and also "What's the business model? What's the value point of your platform?"

If we look at Facebook, they had Facebook Canvas and Facebook Connect.

I've worked with other platforms that want to have that Facebook campus model, the embed framework, because they want to be the center of everything.

I've even seen cases where they don't want an external API because they don't want to be brought into other services, they have to be the center.

I've gotten those companies usually to change their mindset by saying it benefits to have both, because when you have that API--

In these cases it was usually a single sign on thing like Facebook Connect.

Facebook Connect is external to Facebook, but it's basically making Facebook more the center of everything on the internet.

Now people are logging in, and when they register an account they register with Facebook.

Which is controversial because now Facebook knows even more about you. But both the external API and the embed frameworks can serve that purpose.

What I do find though is there are certain limited set of use cases for the embed framework.

For the external API, it could be having integrations with partners that are going to bring you customers.

It could be also that those external integrations are solving problems for your customers, so in that case you are the distribution channel.

You're bringing those partners to your customers, they're helping you close your deals, but in the world of embed frameworks these things are in your interface. Consistently, you're the distribution channel.

This is not about getting new users through partners.

Sometimes indirectly it is, but usually this is about enhancing the experience of your product to maybe improve the MPS and customer retention.

But your partners are building apps in your system on the assumption that you are bringing them users.

This is surprisingly important to reiterate to companies, because during the last API craze companies were launching these embedded experiences and there were a lot of things that they hadn't thought through, including the value proposition.

So they might have a few hundred thousand users, a small percentage of whom are active, thinking that having this framework is going to somehow make them as popular as Facebook.

When they understand it was the other way around, you have to have a certain saturation point and a certain number of users, this is a marketplace model.

You have to either see the supply or the demand and for app marketplaces quite consistently you have to have demand first, users using your product for other reasons, and then say "We're going to open up the third party system for partners to enhance our experience for our existing user base."

Brian: You mentioned a couple of times, this "API craze."

I remember back in the day we had, for example, the Netflix API. It existed.

Right now it doesn't exist publicly anymore, but then you could have all these other tools that you could build on top of Netflix and you could find out what shows were trending.

I think another one that's popular is Twitter, who's reversed a lot of their open-API stuff.

My question is like, how do you prevent API lockout and embedding into other people's platforms and being locked out eventually?

Because I imagine that's going to be a fear for people, if this is their number one driver for getting user engagement or new users and attention and marketing, I imagine a lot of these companies are small when they take that leap.

How do you prevent this in the future?

Jeremy:

For platforms run by teams that are high in developer empathy, they don't like shutting things down on their developer community.

They like backwards compatibility and want to make sure that what we build is likely to last for a long time.

We don't want to break things too easily that will harm our developer community.

Things I generally advocate for APIs are just as applicable for embed frameworks, although in many ways embed frameworks can be more sensitive to these issues.

When launching any new set of APIs I like to start conservative and then go liberal.

Part of the problem we had with Facebook in the past and Twitter in the past, and they acknowledge these mistakes, they felt they opened up their platform too much and they didn't like what partners were doing.

They had to scale back afterwards, and that's more dangerous than starting light, seeing how it goes, and then as developers ask for things and as you test the water you expand.

That's a much safer route. So if the team is especially concerned, and frankly we all should be concerned about how third parties are using our APIs, start conservative and expand from there.

I'm also emphatic of backwards compatibility, that when you're designing your APIs design them such that you can extend them without breaking existing applications.

Now for these embed frameworks, if we look at the issue of backwards compatibility, it's not just about changing your APIs can break things.

It's changing your UI can break things for these third parties.

So you're now talking backwards compatibility for your interface, and often the interface is not designed by a platform team through other product managers who are focused on your UI who now have to deal with this challenge.

As an example, I saw with Gmail before the recent add-on program they did attempt something where you could actually embed these little iframed things on the left sidebar, like underneath your labels of Gmail.

One day Gmail decided to adjust their interface, changing the width of that sidebar and shrinking it a little bit, which was going to break everything.

If you're allowing now these third parties in your interface, backwards compatibility is harder to maintain. You have to be ready for that.

Also if you did open things up too much, and scale back, for APIs-- OK, you may bother your partners and the users other partner integrations. Twitter did that.

I'm OK making fun of them because their CEO apologized for it later. But if we look at say Facebook Canvas, all customers really saw what was happening.

They watched as we're all getting these annoying zombie bite apps, and they saw the apps they were using and that they like were getting pulled.

So it becomes more noticeable not only to the developer community, to your partner community, but to your users.

When it comes to applying product process, it's the same thing, it's just riskier and it's a more sensitive topic once you decide that you're going to open up your UI.

Brian: It sounds like if you apply the product mindset to it that you want to open communication to your developers as well as your end users, so that way if things are changing--

I imagine Facebook Canvas had their top 10 partners that they were going to make sure they knew they were going to leave because they were making changes to the width bar. In the case of Google's width bar.

It sounds like if you apply those processes, the same process that we're doing with creating love for developers, then we also need to create this love for the end user as well.

Going on a little bit of a tangent, when we first met downstairs I saw you were on a Pixel too as well, so you are really ingrained in the idea of the web as an OS.

I'm curious, you're on a Pixel using the Chrome OS. What is the future for platforms like that?

We see Web OS that's not here anymore, the Chrome team's huge so I know that thing is going to be around for a long time.

So me as a developer, where do I look first as far as tinkering with these embed frameworks?

Jeremy: I'm a fan of the Pixel Book and Chrome Books in general. I've been on Chrome Books for about four and a half years now, and you just eat your own dog food.

If you want to see the web as an OS happen, then let's see what happens if you're not limited to anything local.

One of my favorite things about Chrome OS is when you want to download something, you can set your download folder to an online content management system.

You can drop it into Google Drive, you can connect it to Box , you can connect it to Dropbox.

Then when you're downloading something, everything that is just stored online, so if you just do that and you learn to work entirely off web services it's entirely possible to--

Even when working in tech and on developer-facing products to actually be able to live entirely on the web.

In the context of embed frameworks, we're starting to see success finally, and that is going to allow for deeper integrations. Not just connectors between applications, but platforms that are just designed for everything to plug in and really polish and customize your UI. A big challenge is that everyone's still experimenting, and if you're trying to build an integration you can't build it cross platform if we're treating every one of these web services as a platform.

So connector tools, if we're looking at tools like Zapier and IFTTT, they made it a lot easier for consumers to just connect services.

In order for that to happen, we really needed some standardization to solidify more in the world of API.

I'd seen a lot of initiatives like Zapier 10 years ago, and the problem was it was too hard to keep up with APIs because there was so much inconsistency.

We had a concept of restful API architecture, but we needed other things to enforce it.

Things like Swagger and now the open API initiative that made it easier for developers to design their APIs according to a standard, and once everything's designed to a standard it's easier to integrate.

Other was open social in the past, which was this attempt at iframing these embed frameworks and having a standard that worked across a few platforms.

It was a little ahead of its time. So what I'm hoping to see now with the success of these embed frameworks is to see a standard form.

I've been asking around many of the companies that have seen good results so far, and they're all emphasizing the same thing.

They're still experimenting, they're still figuring things out, so they're not ready to adopt a standard or to encourage a standard but they want to see it happen in time.

When that happens it starts to become more feasible to create an integration that with zero to minimal effort can actually work across a few of these services.

Brian: That sounds great. This was a really good conversation.

I am going to transition us into picks. I don't know if you had some links and things you want to share, if you wanted to share them now.

A blog post that you've written in the past on this topic?

Jeremy: A couple that I would recommend, one if you go to ThisIsProductManagement.com, there was an interview with me on treating APIs as a product problem.

When it comes to embedded integrations, if you go to NordicAPI s.com, we're publishing a few articles now as part of a series specifically on the topic of embed frameworks.

Brian: Excellent. So now on to jam picks. These there are things that we're jamming on, I'm a pretty jammy individual and I like trying out a lot of different things.

So if you don't mind, I'll go first and I'll let you go after me. I have always poo-pooed this thing, which is kombucha.

I've never tried it, I've always smelled it and I've always had a gag reflex when it comes to vinegar for whatever reason.

My wife who loves salt and vinegar chips will eat those around me and I can't stand the smell of vinegar, it just smells like cleaning solution.

But for whatever reason, I was like "I'm going to try to be healthy."

There's this kombucha that was at our office that's been there awhile, so I figured I'd try it because it's either that or LaCroix.

It's called Dr. Brew Kombucha, and it was my first kombucha. I have no standard or experience of any other kombucha, but it was actually pretty good.

It was like some green tea and raspberry or something like that. It was approachable and it wasn't super gag-reflexy for me.

So, I am now on the hipster San Francisco train for drinking kombucha all day. But I would recommend give it a try, try new things all the time.

Then my other pick is actually the original series for Star Trek.

I've tried to binge this a few times back in the day, I think even tech TV or G4, they were playing the original series in between late night reruns and I would catch an episode and be like "OK, that's cool. Whatever."

I grew up with my mom, and she was a big Star Trek person. I used to watch her watch it, so that was my aversion to it.

I was like, "It's my mom's thing. I'm not going to watch this."

I literally started watching and it was really cool, and the coolest thing is that I have a five-year-old and he was super engaged the entire time.

It's almost like the acting is exactly like what cartoons-- It's like on the same level of acting, like over too much.

And he was engaged, "What's happening? Why'd they go in there? Why are they fighting this guy?"

So we watched two episodes and we ended up extending bedtime because he was like, "Can we watch another one?"

I was like, "Sure. All right, cool." My wife's like "You know what you're doing to him right? This is going to be a path for him."

I was like, "It's cool." So definitely, if you have kids see if they like the original series of Star Trek. Jeremy, do you want to give us your picks?

Jeremy: Sure. It's going to be hard to top those.

I don't watch too much TV, but I do watch YouTube. Random science documentaries, history documentaries and cat videos.

Something I've actually started to do is there's some very interesting niche nerd channels, on Disney and the history of certain Disney movies and actually Disney Land.

Which I found actually highly applicable as I'm continuing to improve this product management course that I help out, because there's a lot to learn from in terms of how Disney gets detail oriented and how they design certain things, what mistakes they made and what they've learned from it.

As one example, there's-- They actually hit tech news a couple years back, the story of this thing called a Hatbox Ghost.

Which basically, as the internet started to form these online forums and people had too much time on their hands, they started posting all this marketing material from when the Haunted Mansion first opened.

They found that there was, in the old pamphlets from the Haunted Mansion, there's some character they describe that nobody sees in the Haunted Mansion.

It's this ghostly figure that has his head that can disappear and reappear in his hatbox that it's holding, and people are asking like, "Is this somewhere in the haunted mansion? Was there something like this in the haunted mansion?"

Some people found prototypes for it and it finally got popular enough on forums that some old Disney Imagineer finally came out and said, "OK. Here's the deal. We did design this thing, we did build this thing. Unfortunately, we didn't test it until a few days before opening the haunted mansion."

So they tested it in a test environment, but they didn't test it in production until shortly before launch, and with the lighting in the ride it wasn't going to work.

So they had to pull this thing at the last minute, but they couldn't pull the marketing material.

It actually teaches some project management, and it basically tells people "Don't pull a hatbox ghost. Make sure to give yourself time to test so you don't end up in that situation."

If we've been in often in startups where you're launching at the last minute, and next thing you know you have to pull a feature because it wasn't ready and you've already announced that it's coming.

Brian: That is really good. That's deep. I'm intrigued to hear the rest of this course.

Also, I rode that ride with my son. Same five-year-old that watched the original series, and definitely scary.

I'm from Florida, so we actually did the Haunted Mansion which is in Disney World.

It's based off the Eddie Murphy movie called The Haunted House, or something like that.

Jeremy: Actually, I think the movie is based off the ride. The ride goes back to--

Brian: Yeah. The movie is based off the ride, but the ride in Disney World is based off the movie.

Jeremy: So they've adjusted it.

Brian: So the movie itself is not as scary, so the ride's not as scary.

So insider Disney knowledge-- Disney World is actually not as scary as Disney Land.

So, just letting you know for all the five-year-olds in the future. Any other picks?

Jeremy: On the side over the last few years, I guess my second obsession outside of APIs and software is random consumer finance.

I've helped a lot of friends get their credit scores up.

Big fan of retirement accounts, setting up IRAs and 401Ks.

Long story short, I learned in freelancing world that when you are freelancing it's actually possible to save a lot more for retirement than when you're actually working full time.

Most freelancers, it's a scary thing when you're starting off consulting.

You have to pay for your own health care, you don't get that 401K, but if you actually look into it there's a way of setting something up such that you can save a lot more.

Instead of the standard $19,000K in your 401K, if you know what you're doing you can actually save three times as much.

Brian: Really?

Jeremy: Yeah. You can save well over $50,000 dollars just in your 401K when you're freelancing, if you know how to set things up.

So I do a side thing if anyone is interested, feel free to email me and I can share more info as to how to do that.

Brian: All right. That's Jeremy Glassenberg. Find him on LinkedIn, Twitter. He's all over the place.

Also in the shownotes, we'll have a link to your bio in the show notes. Jeremy, thanks so much for coming to talk about APIs and embeddable frameworks.

This was actually enlightening. I didn't think about iGoogle for the longest time until today, so thank you for reminding me of that existence. Listeners, keep spreading the jam.