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.