Mike Bifulco: Hello and welcome back to APIs you won't hate.
My name is Mike Biko.
I'm one of your APIs you won't hate co-hosts.
I'm lucky to be hanging out today with my API's co-founder Phil, Phil Sturgeon.
How are you doing today?
Phil: Hello.
I am doing all right.
I'm in wet North Wales.
Hiding out, hiding out from the weather.
We got a
big old storm coming.
Mike Bifulco: Yeah.
Gosh, it must be the depths of winter there.
I'm sure it's plenty, plenty chilly for you right now, huh?
Phil: Yeah, absolutely.
Mike Bifulco: I'm glad to have you here.
I'm glad to be able to sit down and talk and you and I actually today are
gonna be speaking with a, a guest.
We have Rich Steinmetz on the call today.
Rich how are you doing?
Rich: Yeah, hey, all good.
From my side as well.
I'm here in sunny Barcelona.
It's been constantly sunny as always.
Phil: it in.
Mike Bifulco: my jealousy is infinite.
Rich, you have been a community member for, with APIs you hate
for, for as long as I can remember.
And.
And it feels like your name and your your voice have appeared
quite a bit in our world.
But I, I feel like I also wouldn't quite do justice to explain just
to everything that you work on
can you give a little background on yourself and kind of the things
that you do in, in and out of APIs?
Rich: Yeah, for sure.
First of all, thanks a lot for having me on.
I.
I'm a listener of the podcast since probably four or five years, so it's
basically one of the places that got me into the whole API thing.
So it's, it always surprises me how it is when you listen to some,
to a podcast or watch a show and then all of a sudden you are there.
So thanks
Mike Bifulco: think that officially makes you an OG too.
If you've been around for four or five years, , you've been
with us since, pretty early on.
Rich: Yeah, I think, I think it is pretty much from the start.
Phil: Nice.
Just be, just be ready for how weird it gets when you kind of, you know, you,
you, you do this recording, you pop off, you forget about it, and then however
long it takes us to actually get this one out, you'll be minding your own
business one day and you'll hear your voice coming in through your headphones.
You're like, I was just trying to listen to the podcast and it's me.
Ah.
So just skip
Rich: yeah, yeah.
That, that's a, that's a scary one for sure, but I'm looking forward to that.
I, I'm not from a engineering background.
I did get into engineering about like nine to 10 years ago, and I,
obviously, I didn't know what I'm doing.
I tried a bunch of different things, worked and different.
Software teams from the beginning as well and different
technologies from cake to cake.
PHP, like from PHP
Mike Bifulco: Oh yeah.
Rich: Java to Python.
And one day I had a contract in the Ruby Real space.
And there, there I thought, yeah, that's a cool technology.
That's a cool community.
I want to stay here and.
I was always a backend guy.
So although I've built full stack from like infrastructure to front
end, I still in in the years before I touched and created APIs
a lot for one reason or another.
But then.
With this contract, this Rails contract, five years ago I, for
the first time I worked in a team that they had an interesting setup.
Actually.
They had like a, on the front end, they had a Rails app, and on the backend
they had a, it's called Grape, API it's like a framework in Ruby to create APIs.
And it was the first contract where I realized that.
APIs are like a discipline, like it's something you can get into and be like,
get good at and can learn more about.
And there I learned things like designing an API and they
have like a swagger UI too.
For the front end app to communicate with the backhand.
So and this is where I match you guys in the, on the podcast with my ears at least.
And this is where I started to get deeper into APIs and like read books about it.
And yeah, follow the different shows and understanding like the business
aspect of it, the technical aspect of it, the design aspect of it.
And yeah, five years forward, I'm now, I, I had only rails Ruby
Rails and API contracts ever since.
And I'm now helping to build the business operating system, API for ClickFunnels.
It's a company who basically.
Provides the software for entrepreneurs, for solopreneurs, bootstrappers,
but nowadays also for all kinds of companies to run their business
on and basically have everything related to marketing and shops and
customer management running inside.
Mike Bifulco: Thank you.
That's super helpful.
I , am the first to say that I understand marketing technology at
like, let's call it a 100 level.
I'm not super versed in marketing stuff but I'm also a victim of it fairly
often, meaning I get to be an end user of it as a developer for my team at.
Rich: Yeah.
Mike Bifulco: something that I find really fascinating there is for, for the
uninitiated, there is an incredible amount of technology that goes into making sure
that money spent on ads, for example, is being spent well and being used to target
fundamentally better audiences each day or week or cycle, however that works.
But then there's a lot of information that goes into tracking
people's journey through a site.
So how does someone reach your your website and then get from.
Wherever they got to you to spending money presumably, or creating an
account or whatever the goal is.
And I think on some level that's kind of what ClickFunnels
does, is that vaguely right.
Rich: Yes, we do have a good analytics.
Analytics like module where you can follow your customer's
journey through your funnels.
Like the meat of the software is, it's in the name, it's the funnels.
It's like a page builder for you to create your offer.
Or Well, you create your offer in your mind, in the background on
paper on the, on the whiteboard.
And then you make it visible for others in, in software.
And it's basically there is a page pillar for that.
And then you can have a bunch of different automations, for example.
I think for craftwork you have, you have or will have a subscription, right?
Mike is,
or is it one time payments.
Mike Bifulco: yeah, it's one time payment.
So we're a B2C company.
We, we do home painting, so we're not a SaaS at all.
Yeah.
Rich: Yeah.
I, I remember, yeah.
You
do home paintings and then now imagine you have your offer there.
Hey, I have these amazing paintings in here.
And then someone buys your offer.
Let's say you have like a fixed price on it for this particular funnel, and
then they're redirected to another page where you can provide them
with more services that they need.
Maybe, I don't know if they really need it, if you do like everything,
but theoretically you could sell 'em the the tools to do the painting.
Well, you'll be doing it of course, as a
Mike Bifulco: Sure.
Yeah,
Rich: just as an example.
Mike Bifulco: yeah, of course.
And so ClickFunnel helps, helps you to understand that process and, and hopefully
send people in the right direction.
Rich: Exactly.
And then you can have all kinds of automations around that.
And of course going back to analytics, it's an important part to understand
like where in your funnel and your funnel can consist of couple of steps
can be very simple, but it can be also very complex with like split
testing and all kinds of things.
Mike Bifulco: And imagine when it comes down to it.
So I'm viewing, I'm sitting on ClickFunnel's homepage right now, and
there is a massive grid of features here.
Many, many different things that ClickFunnel seems to build and
make available to customers.
All of these things probably have to talk to each other on some level.
Is that where your work comes in?
Rich: yeah, exactly.
Like we have all these features and.
It is actually a funny story.
This software exists for 10 years now more or less, and they began
mostly just being a funnel builder, like page builder, website builder.
And at some point five years or so, for like five years
ago, they decided to do like.
A ClickFunnels 2.0,
like a second version, and one of their like huge factors was the
technical aspect of how their app was built in terms of API ecosystem.
Like everything around when I say API ecosystem, I'm
thinking about like webhooks.
The public, API, of course like the platform ability of your app, like
other apps connecting to your app.
that was a huge factor because the, the infrastructure or the,
the technical architecture there in the, in the first version wasn't.
set up in a way that, that was easy.
They had like the old version of the API.
So basically to provide a much better experience for their users, give them even
more power in terms of automations that they get with the web hooks and public
API, and to also enable partnerships.
They have like this big factor, Hey, let's, let's build an.
Ap ClickFunnels 2.0
and let's make the API ecosystem.
Awesome.
Like the, there was a, a lot of thought going in from the beginning
into how to build, build it and make it in a way that it's like a platform.
And it really shows fruit fruits now because, you were at their main
page probably@likeclickfunnels.com.
If you would look for like developers.my
clickfunnels.com,
you would see the Our Developer hub.
And there you can see the different resources that we kinda,
that relate to the features, of course on clickfunnels.com.
But then also.
That are used by, by our partners or by our, like, power users
and just also developers or entrepreneurs who are very techy.
Mike Bifulco: I feel like I've gone further and further down the rabbit
hole here, and I'm finding more as I go.
It's a big product.
Phil: why I've been quiet for a while.
'cause I've just been clicking around the website going, oh man, this
is gonna solve a lot of problems.
Whenever I look at a product at the moment, I'm kind of thinking how
it would work for Protect Earth.
And I
think one of the
problems we've
got is,
Yeah, we're like a tiny little startup growing rapidly as a
kind of reforestation charity.
And there's so many different bits of software and we've got like a
website on Squarespace and the you can sponsor Trees on via the Shopify
store, which kind of we have to manually make, try and look a bit similar.
And you can schedule appointments and CRM stuff with HubSpot and you
could, you know, there's all we've got MailChimp for doing email marketing,
but we've also got SendGrid for kind of
programmatically,
sending emails and there's a hundred different things in here
and it looks like you guys do
basically.
all of it.
So that's, that's pretty interesting.
Rich: Yeah.
So this is exactly the vision to have.
Like the business operating system, like to have everything in one place working
together and in an automated way so you don't have to switch between the tools.
You don't have to connect them because probably if you have those
different tools fill, you probably also go from time to time and use
something like Zapier maybe to,
Phil: Yeah, and a
bunch of them charge, charge extra for the integration.
I think like donor box, our donation platform.
I've been looking to replace that for a while.
'cause Stripe already taken whatever reduced charity rate fee they take.
But then donor box take another percentage of that and sometimes someone
wants to bang in a thousand pounds and we lose like 50 or 60 or something.
And tracking analytics is, is a massive pain in the backside.
Fathom, who are amazing sponsors of the charity have given us like a
free analytics thing but it's pretty basic because we've not managed
to integrate all of the correct tracking links between Squarespace.
going to donor box and and joining it all up with that.
So yeah, I think the integrations when free require a little bit of work to make.
Work properly and sometimes aren't free.
so it's expensive and more work.
So yeah, it's interesting to see someone trying to tackle all of
this at once, which cannot be easy.
Rich: Yeah, definitely.
a lot of the features are also quite new and there is a lot in the pipeline
as well, but we are now at a point that we zoom into making them awesome.
on the UI side or on the API side.
So, yeah.
In terms of features, I, I don't think it will not grow like horizontally
anymore a lot I think from what
Phil: Right.
Rich: From what I see.
But we will just like double down on what we have now in the, in the coming time.
Phil: Yeah.
How, how is it?
What, what form does it take?
Like is it basically a, a, a
Big old cms
with lots of modules or is it something that is a
kind of a toolkit that you are meant to plug into.
some sort of site yourself?
Rich: It's, it is just a UI with you, you start out basically when you do the
free trial, for example, you start out and with a screen and a couple of apps.
Predefined for you.
Like let's say like funnels are native and then you can choose, pick and
choose what you, what kind of an app.
It's structured in an appy way and then you go to the app's menu
and say, Hey, I want like, know to know more about analytics.
So we pick the app and then it just.
Part of your dashboard and you can just come back to it
Phil: Oh, I gotcha.
And there's like, there's a, a website editor where you are picking a theme,
and then all of those themes will support all of the built in apps, I'm guessing,
so you can just kind of add in whichever apps and it will have an interface.
for that, for that, that
Rich: Exactly, yeah.
There's an editor like the whole.
Funnel thing, it's its own app.
So there is an editor website.
You connect a domain, you can connect a domain to it, and then you are
provided with a domain, like with Click Funnels, domain first, and
then you can just connect yours
Phil: Do you have any integration with like random APIs?
So could I dynamically fetch data into one of these pages from my own
api, or would that be something else?
Rich: You mean whether
Phil: like Right, right now I've
Rich: data from
Phil: yeah, exactly.
I've got I'm just turning this into free consulting now.
Cheers.
So for a common problem that I have with CMSs that, that try to
do quite a lot or any sort of kind of SaaS that does quite a lot?
Is that.
the more stuff they do, the better.
But you always find you know, the end of it somewhere.
And we've got we've got loads of projects, right?
Like every site that we create a new woodland at is a, is another project.
And I've just spent the last week or two hiring a guy to kind of do manual
data entry into our Squarespace website.
'cause there's no way to dynamic people in the information.
And I'm like, man, I really should, I should be doing better than this.
I should not be hiring someone to manually do data entry on a website when all
of this data already lives in an API.
But also we're quite busy planting trees.
And I think my point is yeah.
Is there any way to get kind of custom data into it somehow?
Rich: do you have like an example of what kind of data it would be like?
Phil: If I've got an API with like name of project description, number of trees
planted, and here are some photographs.
Rich: So it is kind of custom data, right?
It's not something that's part of ClickFunnels already.
I, I know that like.
can have , the first thing I I'm thinking about here now is like
Salesforce, they have these and their APIs are very happy to work with,
but they have this like maybe also HubSpot if I remember correctly.
But they have these objects you can create and you can name them whatever
you want and things like that.
Is that what, what you would look
Phil: Yeah.
I've worked with that sort of integration in the past that's quite clever.
And I was quite impressed, even though it was cumbersome, like in Salesforce,
you can define custom objects
in there that are like represented as o data
and therefore you can see that lives over here on my API and then it kind
of does some syncing in the background or whatever because it, because it's
o data, it knows what structure it is and what types are and everything else.
Yeah, I suppose that sort of thing.
Rich: Hmm.
No, we don't have that.
We have the, the resources that we provide on, on the API, like, we
basically hook in to what we offer to, to what we offer in the app.
And that's basically.
Phil: I gotcha.
So I can integrate kind of products and courses and, and all of the
various different app bits I could use.
I could use an API to stick some stuff in there.
Rich: Exactly like context products CRM you can do even fulfillments via the API.
We have a amazing new feature, which is like creating orders via the API.
Phil: Oh, brilliant.
Yeah, that's helpful.
Rich: Yeah, so
Phil: Excellent.
I always like to find the limitations of a thing to help people get context
of like where it sits, but that's, there's plenty on here, which will
cover the vast majority of of needs.
'cause not everyone runs a reforestation charity,
. Mike Bifulco: So Rich, I.
happen to stumble across the change log on the developer side of ClickFunnels.
And I've noticed your name is under most of the change log entries of
late for the past few months at least.
One of the things I'm curious about is, especially like, as Phil's
mentioned, there's so many things.
You're, you're serving so many different use cases here.
How is your team identifying what to work on next and how do you balance,
you know, the change of a feature with all the users who must be
consuming the things that you've built?
Rich: Yeah, that's a great question.
This like our API launched almost two years ago and like end of.
September, somewhere 2023.
I launched the second version of the API and since then it has evolved.
So we went from, Hey, let's give our users what we know they'll be using for sure.
Let, let's give them like a basis.
And we basically decided ourselves, like business decided together with
the engineering team what it will be.
They have always spoken a lot, a lot to customers.
And so we were just shipping the, the thing that, that we knew
that will have broad application.
And at some point this shifted a little bit in terms of we went
more into shipping for our partners.
And as people started using the API more, they were requesting things
more so we had direct feedback.
By the different channels.
We also encourage people to have feedback for us, so they come via support or we
start early on to foster this discussion, as you said, in the change log.
Like that, that would be like the passive consumption of what's, what's going on.
But
we also early on went into having like a discussion forum so people
have have a place where they have, can have questions or doubts.
And then again, our like our API users, they aren't all necessarily
like the hardcore developers who.
Are hired to do the thing with Salesforce, for example.
Our API users are a lot more, I think compared to, for example, Salesforce
are a lot more just like solopreneurs who who are techie and they want
to build that thing real quick.
By fo fostering that discussion in d in different channels.
We also have like a feature feature board, and these are all the places basically
like our partners who integrate with us, and they're, they're quite a lot of them.
Who basically with whom we have synergy, right?
Like this is a big thing I think in the API space like the
business aspect of the APIs.
If you provide like a good platform that can be easily or apt.
Two that can be, that have exposes a lot of like API features.
Then you have the synergy with other partners and you can kind of propel
your, both businesses and through both customers in terms of like value.
Mike Bifulco: I'm curious, can you tell us a little bit about how the
product is built in the backend?
Like , what tools are you using to manage and maintain the API?
Rich: That's a good question as well.
ClickFunnels is built on on Ruby Rails.
Mike Bifulco: Okay.
Rich: Additionally, it's also built on bullet train.
So bullet train is an open source SAS building framework on top of Ruben Rails.
And it's basically like Ruben Rails on steroids for SaaS.
The creator of this framework, Andrew Culver and the the open source team
who's working on it, they have created this this pretty cool starter kit
for, for SaaS and for APIs as well.
It is funny that . It was ahead of its time a little bit in, in the Ruby
rail space because in the enterprise world where different technologies
play a bigger role like Java and c and wherever and even Python, like in
where microservices play a bigger role.
It's more common to build something like API first.
Would you agree?
Like, because Ruby Rails is more like SaaS web applications.
Phil: Yeah.
I definitely feel like there, there's a lot more kind of, let's sit around and
spend a year planning this thing in, in
those enterprises just 'cause of the, the, the nature of the size
of company and they wanna make sure they get it right, you know?
They're, they're often a bit less agile, a bit more waterfall because.
They are gonna spend, yeah, like sometimes, literally
six Months.
to a year, like planning what they need and involving stakeholders
before, before they even kind of get around to writing any code.
Whereas I am consistent, you know?
In previous jobs where Rails has been the thing, you'd be in a meeting talking about
what, what we might need from this API.
And someone's already started typing rails new into their command line.
Like they will not stop coding because of the because of the
kind of agile nature of it all.
And the fact that there are like generators and Scaffolders people will
immediately try and just be like, his hit.
well, you've mentioned these five resources.
I've.
already made the controllers for them.
The API's basically done, what are we talking about?
So
Rich: The funny thing, you, me mentioned scaffolds, like it's a console command
for anyone who's not into like rails and, and this stuff where you have you
just type it in and it creates like controllers, models, like a bunch of
code that you would write manually.
In other language system frameworks and like Bullet train has super scaffold, so
it provides you with extra functionality, a lot of UI things already built in.
So it is pretty cool and yeah, it is cool that you agree that there is
like more ity on with like in Ruby and Rails teams, maybe also in PPHP
teams or like some other, tech bubbles.
Yeah.
Mike Bifulco: That seems to be a pattern that's found some favor
with people, especially with getting off to the races quickly.
You can like Phil was saying, rails new, is a funny shortcut for just
like, oh, I'm gonna build a thing.
I've got the solution.
It's coming.
And scaffolding is kind of halfway in between where you may be growing
your understanding of the thing and, you can use a scaffold to create
all of the crud stuff very quickly.
My understanding of super scaffolding is that it's make the crud stuff
so that your web app has all of the views for a list and a show and an
edit, but also that you now have an API that does those same things too.
Rich: Oh yeah.
Well, how do you know this?
Have you worked with train?
Mike Bifulco: I haven't worked with Bullet train but at Kraftwerk we're
building our product on top of Rails.
So I've done a bunch of research about Rails API, providers and patterns.
And I think one of the interesting things about Ruby on Rails is
that for a, a framework that is so, so hell bent on having like
the rails way to do everything.
When it comes to APIs, there isn't really a fully formed opinion.
And there's many types of ways of kind of getting to what feels like a similar
end result enough to the point where it feels like maybe that should just be
somewhat standardized at this point too.
And super scaffolding seems, seems to come up every time I look up, you know, how do
I make a nice rest API using my rails app?
. Rich: This is exactly where, where I was saying that bullet train
was a little bit ahead of its time in the ruby rails space because,
because of its ity, because of how.
The rails main driver company, which is like Rails and so Source, right?
And behind Rails, like the main core contributors are, , from a co
from the rails creator basically.
Who, who, who's like DHH David Heiner Hansen.
He's the founder or creator of Frails and he, like his company is basically
the, the main driver of this technology.
And if you look at their API, you might have, like Basecamp is one of their apps.
If you look at the base cam play this a PIV four, you might get an idea why Rails.
API standardization is in the state that it's currently in.
Because it's funny, it's actually funny.
Their APIs basically hosted on GitHub.
It doesn't, it just examples with, with some text and I'm not sure
they are auto generating anything.
Maybe they are.
But in the end it's just like example response, payload and text.
So they haven't ever, I think I'm looking this up like a couple
of times a year, probably every year for the last five years.
And I don't think they ever with any of their products, they went into like
generating an open API schema providing like a developer hub or anything.
So they never.
Got into this stuff so it never became part of the Rails core framework and
Phil: yeah.
I think he's a bit busy writing fascist manifestos to get down writing any open
API, but it would be, it would be nice to see a little bit more effort put
into actually describing, describing any of the APIs involved properly.
Because yeah, it has just been the, the classic, like worst
possible example of here is a url.
Here is some stuff you might throw.
at it.
We're not gonna, describe any of the, of the data types or validations or anything
that you'll actually need and just go figure it out and see what happens.
Because I forget the name of the term.
I think it's, Hirums Law.
Or I'm just getting it wrong and I'm googling frantically, but the, the
law that any part of an interface.
Can and will be used as an API.
Yeah, yeah, yeah.
There I actually got it right.
Go me.
I've said it to like three other people recently, so retroactively.
That's good.
With a sufficient number of users of an api.
It does not matter what you promise in the contract All observable behaviors of your
system will be depended on by somebody.
And so with Rails, because
there are often a lot of different ways of doing something, and sometimes
those things change if you are not documenting the way that things should be.
done and there are multiple ways of doing it, then you have no
idea if you're breaking an API.
Like the fact that Rails has from day one somewhat ruined the entire internet's
Understanding of the difference between,
a put and a patch.
'cause there isn't one,
it's just the same thing in Rails, right?
And they've just never changed that.
And the fact, and the fact that sometimes they, they support like putting a dot
Jason on the end or, or a content type.
Like there's a lot of these weird ways where they've just gone screw it both
and.
If that's not written down in a contract somewhere, you don't have
a contract, you just have vibes that might shift and break everything.
So
I, I would like to see open API considered as important, not only
to David Heil Hanson, but the companies that he works for and the,
the core product itself, you know.
Rich: Yeah, I'm on a mission, a actually to to get there and bullet train.
Is, and I, I don't know how many years it'll take, but maybe, maybe someday.
And bullet train.
One more time back to the head of its time thing, it with the super scaffolding
it provides you with with an API namespace, this is like the regular way.
It's not classic API first development because.
It's not like a separate service in the end Rails is still like a
monolith but it has like, it gets like a touch of API first into the
monolith and you get the the specific API version namespace in there.
You you have even the parameters.
Are initially when you do the su super scaffold, like the parameters of the
domain code in the controllers makes use of the parameters in the API control.
Control so that you kind of think from the beginning about,
Hey, what's, what would be here?
Like like something I can or should expose or shouldn't.
And yeah, not to forget, there is the, the open API quote unquote
problem, which, in the rails world, because it's an unsolved problem.
I would consider it unsolved to.
Generate your open API schema from code itself.
I, I don't know you guys, do you agree that like in Python or like
some type languages there are extremely solid open API generators.
And I'm always saying like, fast API is the most prominent example, but do
you agree that there are like kind of bulletproof, more or less at least?
Phil: No.
I mean, every, every I.
Every
Language has one framework that takes the
view that
open.
API is something that you should just vomit out after you've
finished writing all of your code.
And, and
whether that's coming directly from the code because of types or whether
it's coming from
annotations that are
confusing, proximity with accuracy,
they kind of just, you know, throw something out 'cause they were told to and
they couldn't be bothered to think about
doing it first.
And
that is.
you know, helpful in some regards.
But I think most, most frameworks have.
A way of ingesting open API,
Right?
The
API design first workflow being,
I'm actually gonna do this open API first, and then whatever code I end up using
will simply
be
an
implementation of this.
Without going the full, like I'm gonna generate the entire code
off of the open API, which is usually a bit of a faf.
A lot of,
them have like.
Server side request validation
so that you don't have to write that yourself
And
then make sure
that it matches.
because you can just say, Hey, this middleware, can you validate
the incoming request based off of open API and reject anything that's
rubbish.
And then they have like some other sort of like aspect, you know, test
unit testing extension that just
Says
oh, and hey, can you make
Sure.
that this response coming back matches the open API that said it should
and annoyingly most frameworks.
Have those sort of options, but there are always some random little plugin
main maintained by, you know, some guy.
And I think that more and more API frameworks or any
Web application
framework that wants to
pretend that it's
you know, focusing on APIs
needs to bring those into the core,
and
make it incredibly easy and recommended
to,
instead of defining everything in some random DSL, you
could simply
point it
at your open API and save, wrangle that code.
I,
I'd love to see
Ruby do more of that and Rails do more of
that.
'cause there are really good extensions out there for
that sort of thing.
Rich: Yeah.
it, that's exactly the thing.
Like an R swag.
It's one of the best options right now in the real space where you kind of write
the tests first and then it also generates an O-P-A-P-I schema from the test.
But it's still a little bit of A-D-D-S-L there, right?
It's not really generating from code,
Phil: oh yeah, sure.
That's, that's something different.
That's aspect is just the generic testing framework like PHP unit or
J unit or just whatever test runner,
um, the.
Ah, swag.
Yeah.
I think that doesn't even support the latest versions these days, and
they can't be, they can't, can't be interested in up update updating it.
So mostly what I try and recommend to people is instead of.
Some people don't like writing open API and instead of writing open API,
they write some other sort of awkward DSL, which then gets out of date
because they've tried to simplify it by taking shortcuts, which then don't
represent the full reality of open API.
So honestly, just like learn to write it or use, use copilot
to help you or whatever.
But
my, My.
preferred thing is still like, just actually write
the open API, it's portable.
If you rewrite your version two of your API.
And whatever go instead of Rails, then app days, it, it's still exactly the same.
And you have something there for breaking change detection because you, you know,
that you haven't accidentally broken the API 'cause it's, you know, being tested
and validated against the whole way.
But that is probably a whole other episode and one that we
did recently.
So I'll get off my soapbox.
Rich: No, it, it is good stuff because we also thought about testing
this as an alternative approach.
Like what would be the cost of doing like this manually or design
first versus having our own auto generation, which we have now.
But it also comes with some things that need to be improved.
Like , the final vision of this is that bullet, the bullet train open.
API generation would have like the perfect generation generated
from code and just like clean, cool generation from code, but.
Yeah, , that's the other thought experiment there.
Like what would it cost actually in comparison to us getting it there, the
technology there, what would it cost to actually doing the design first thing?
Mike Bifulco: So Rich I, I know you've mentioned earlier in the chat that
you have been doing some consulting work my understanding is maybe at
least that you may be working on ClickFunnel as a consultant there too.
Are you working with folks currently outside of ClickFunnel?
Are there projects you're working on?
Rich: on?
Yeah, sure.
So yeah, my main consulting right now goes into the ClickFunnels business
operating system, a BI, I'm super passionate about that project, but.
I'm also working together with people to help them create their apps.
Marketing First in the Ruby Rail space because we as developers tend to
develop a lot and keep our heads in the code a lot, but then we don't really
think about the Mark marketing aspect.
Unfortunately a lot of times so.
Yeah.
I'm working with developers and developers to help them build their app marketing
first and maybe with maybe also some projects will come out with backed by
the ClickFunnels, API, to just see how you can delegate your user management
to, to the api, to an API or to this API.
So I'm working, that's one of my main.
Projects right now,
Mike Bifulco: I think that's something that I probably have shouted
about on the internet infinitely for people building new products.
Is that marketing your thing is every bit as important as making it work.
Because if you build a product and nobody knows about it, ain't nobody gonna use it.
And that's hugely problematic for a lot of founders who are super
technically talented, but then never tell anyone what they're building.
And there is no longer, and if you build it, they will come.
It's uh, you gotta do both now.
Rich: them.
Yes.
How many apps died because someone shipped an app, it's online, they
dropped the link somewhere and then no
one registered.
. Mike Bifulco: So Rich what's the best way for people to find you online if
they're interested in working with you?
Rich: Yeah, I'm also asking myself this sometimes because things change a lot.
But I think one solid place is always the rich stone.io/meat
dash rich,
That's the place where I kind of share where I'm at right now and
what channels are best to find me on.
I'm also an ex, I'm everywhere.
I'm Rich Stone io basically.
Mike Bifulco: Oh, that makes it easy.
And I'll make sure to drop a link to your site in the show notes
so people can find that as well.
I've also jotted down a handful of things related to ClickFunnels and
bullet train and, and the like.
We'd love to have you come back some time in wax philosophical little
bit about Rails and open API I think that'd be a fun chat too.
Rich: That'd be awesome.
Yeah.
. And, and by the way,
I just wanted to mention that the Ruby Rails community being like the web app.
Framework and, and language.
They will really appreciate the things that you are sharing and doing
about like APIs and integrations.
So it's good to have you more in our world as well.
Mike Bifulco: Well, thanks so much.
Yeah, I appreciate it.
It is a hugely, hugely responsive community, and they're definitely.
Very opinionated , and nice to chat with too.
People are pretty reasonable to talk through what they're
working on and you know, why they prefer this over that, and so on.
I'll find myself deeper and deeper in that as the the days where on certainly too.
Alright, fellas, well, let's call it a day from there.
Thank you so much for hanging out.
It's been really nice chatting with you, rich.
Have a great day.
Thank you for coming.
Rich: Thank you very much.
Bye.
Mike Bifulco: Bye, Phil.
Until next time
mate.
Phil: yes.
See it.