Subscribe
Share
Share
Embed
In our recent podcast episode, we spoke with Kevin Dunglas, CEO at Les-Tilleuls.coop, which is an organization made up of API experts that created the open-source framework, API Platform. Appropriately fitting into our Open-Source October theme, our conversation with Kevin included some implementation tips and a walkthrough of the benefits of API Platform and how it utilizes OpenAPI.
Do you have a question you'd like answered, or a topic you want to see in a future episode? Let us know here:
https://stoplight.io/question/
Building a successful API requires more than just coding.
It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.
In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.
Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.
They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.
They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.
Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.
Welcome back to the API Intersection podcast here again with my co host, Phil.
I'm Jason Harmon, CTO at Stoplight.
Phil helps out on our Deverell side, and we have a very interesting guest today.
I think this is going to be a little more implementation talk than we usually get into, but let's see.
So we have Kevin Duglas front, who is CEO at and here we go.
I'm going to try do co op, which he tells me means lime tree, so maybe that's easier.
Hello.
Almost literal, which means like three Hello.
Okay.
Alright.
And thank you for having me today.
Absolutely.
Thanks for coming on.
So maybe Kevin, give us kind of a quick overview of your background, kind of what you're into that sort of thing.
Yes.
So as you can hear, I'm French and my English accent is almost as the river.
So you can say at year in French.
So sorry about that.
But I CoFund or a worker cooperative called Liter Point later Point co op.
So the company is ten years old and we mostly provide professional services for a lot of other companies around the world, mostly French companies, but also English and US and European companies.
We mostly provide developers to work on any kind of project, but we also do consulting and audits and consulting and consultants here around the APIs around Web performance and many things like that.
So basically we are a professional service company, but we also have a lot of people in the worker cooperative who are API is expert and we work on the topic of API very, very often.
At some point in the life of the company, we started to be tired to have to rewrite almost the same thing and almost the same tooling for every project with a quality that could be nice sometimes and sometimes be less nice.
So seven years ago we started to work on an internal framework to build API.
Bye.
The card name of the tool was a platform, and at some point some point we tried to open source the project.
So seven years ago we created a GitHub repository called API Platform containing the code of internal framework to build Web APIs.
And now it's a project that has a lot of contributors outside of the company and which is quite popular, especially in the the community, because it is integrated with the Symphony framework, which is a very popular a web framework.
And when you build APIs with the official distribution of Symphony, basically, you get API platform with the framework, even if you can also use API platform as a standard tool without Symphony.
So here we are and I'm still the main contributor of that platform, and I must be focused on the architecture part.
There are a lot of other contributors know, and especially cream of 20 maintainers writing.
And this for listeners is Mercer, M-E-R-C-U-R-E.
And I love that it's rock is the website for this API platform that Kevin is referring to.
yeah.
I love talking to tooling providers for API stuff because it all seems so formulaic.
It always seems like, well, this is also reproducible, and you can just generate everything and kind of where does the line of generating from sort of underlying data sources versus manually designing things? Where does that line start and stop for mature here.
Okay.
So just to clarify, I'm working on several open source projects.
Api platform is a PHP framework that you can use to expose with API and make sure that works.
Was that a different thing? I'm sorry.
All right.
It's another tool that I also created.
It's basically a real time protocol that you can use to create a sync API.
And when you are using API platform, you can expose API using Mercure, but you can also implement and use Mercure in other programming languages and in other technology.
But anyway, to reply to you as well.
I see.
When we started working on APA platform, one of domain constraints that we add is that we wanted to be able to not generate code.
So with API platform, there are no one nation at all happen.
Most of the work when using a platform is when you start a new project.
Basically you will start by designing the public shape of the structures of the data structures that you want to expose through your API to do so because it's a tool written in PHP, you will use the explicity of the explicity of the PHP language, and we are a domain the structure that is supported by PHP classes.
So you will write classes with type definitions with the relations between the classes with the documentation using the integrated PHP documentation to represent the public data structure that you will expose with your API.
So basically, if you are used to open API and format like that, you would write Jason or a file describing the structure of your API with APA platform, you will use PHP to do the same thing, and then with this data transfer object basically containing all the metadata that you need to be able to expose an API.
The framework will under the infrastructure part, and we'll use this class here to expose an API supporting persistence with common features as pagination and filtering, sorting, ordering and things like that.
And it will also generate documentation from the PHP place.
Actually, the tool supports several documentation formats, including Open API but also Hydra, which is popular API documentation format available as an RDS vocab that allow you to use all the Semantic web stack.
Actually, in its platform we have a strong focus on RDF and Gold community and a set of tools, and by default the API which is exposed by the tool, is using Gong as format and document the API using the Hydra vocabulary for we also support other APA format and other documentation format, but they are the default, and by default we want to expose the RDS graph.
Where does the RDF come from? Like, yeah.
I haven't really honestly seen RDF used since the Sparkle days, so I'm just curious.
Like what kind of use case or tech brings RDF back from the grave here.
Yep.
Okay.
Oh.
Actually, I'm not sure that it's the case because are you a Gmail user? Yes.
All right.
Bye.
Sure.
Did you already notice that in Gmail when you let's say you book a flight directly in the Gmail UI, you can see the details of the flight, you have a link to the booking and you have the data or regarding the flight updated in real time.
And also if I did to use Google Calendar when you are using this video, you are using RDS because actually there are a lot of systems that are using the Schema or vocabulary inventive promoted a lot by Google and schema.
That's true.
Org vocabulary just as IDA.
And to trigger this video, what you have to do is to include RDF data directly in the body of the Hemi and to do so the spark time I pass over.
Yeah.
But there is a very popular format that is used for that, which is Jason and Jason is just a JSON document including no advanced metadata and especially type information.
And it's serialization format of RDS.
So it means that it's the RDF data graph, which is compatible with all the older RDF formats, including XML, RDF and Trust and all this quite academic step.
Bye.
And you can still use all the existing tooling like APH, Gene and things like that on top of RDF document, but it's more easier to manage for common web developer or API developer decode.
It's just a special design document which is formative to be easy to read and easy to develop, but with all the capabilities that are provided by Herds and all the dream of the semantic web back in the days of MDF and Parker and things like that is not actually a reality.
Yeah.
Thanks to Gold and Schema.
Org, and basically most advanced Google features are using this technical stack, the Gmail thing that I already mentioned.
But also if you want to expose your data to appear in Google shopping, you have to use schema.
Org and to use the vocabulary provided by Schema.
Yeah, that's true.
Org to map your son documents and many things like that.
So it's why it's the format that we promote and were used by default by API platform, for instance.
So you have created the public data scripture that you want to express to the API as a set of PHP classes.
Thanks to API platform, you get a working API, and as I was saying just in the previous question, it's not code generation.
Everything is entirely dynamic and so you can also the only code that you have in your object repository is the PHP classes representing the data scriptures that you want to express to your API.
And if you want to specialize the business logic or to change something that is provided by the framework.
Actually, because we are typing integrated with with Symphony, we use the dependency injection pattern a lot, and you can hook your own business logic and replace or specialize everything in the framework like that.
And with just with that you get an API which by default exposition LG resources.
This gold document can be very easily using an annotation mechanism mapped with any existing RDS vocabulary including Schema or and that means that if your matching is correct, then you can just query your API, grab the resulting JSON document and pass it in the body of email or in the body of an HTML page, and Google and also have compatible services will be able to automatically extract and use the data provided by your API, thanks to actually RDF and Gamma.
Org and the fact that it's handled automatically and without the developer rising to Rotie.
Actually by Pat.
Nice.
I think part of what impresses me about API platform is that it takes a lot of the decisions about the various API specifications away from a developer who it's quite tricky to work out which combination of things like, when do I get open API or Jason schemer involved? And how do I express different formats? And should I use Rest or Graph? Ql and API platform does both.
It just kind of lets people define their data model and in one place and business logic and another.
And then all of that other stuff is just like an implementation detail that you get out of the box.
That seems pretty handy because I've often talked to people about things like JSON.
Ld and they're just like, yeah, sounds like extra work.
But if you just kind of shove it in there and you just get it, then that makes more people use it, which makes more people likely to use it themselves because more people are already using it.
Yeah, sure.
And it was one of the main design goal of API platform.
It was to be able to create API following the best practices and even supporting very advanced tests like RDF and JSON agents like that with an extra burden for the developer.
And so it means that the cheap point of the framework is to be able to be used by the Mass.
Actually, I did a talk at an academic conference with a lot of people from the W, three C and Thunder committees and working on Sparker and RDS and things like that.
And the title of the talk was Seven Suit for the masses.
And it was exactly this idea that the developer can just write an API very easily in a few minutes, actually.
And behind the scene it gets everything in need to write something, to have an API following the most modern practices, and adding a lot of features that actually can be used by the consumers of the API, even if the developer of the API doesn't even know that this feature.
These capabilities are supported by the API, and it's one of the key point of API platform is to be able to expose a lot of advanced capabilities to an API without having to develop it because it's already included in the infrastructure in the library.
Yeah.
Yeah.
The goal is to be very, very easy to use to create a prototype and to start working on the project and to be able to scale for a very huge project with a lot of traffic and important good performance even on distributed architectures and thing like that.
That and to be able to customize everything.
So I think that actually took some time and it wasn't the case in the first version of the tool.
But now I think that we have something very and allowing to have a very good time to market and to be able to have an API just working in basically in a day or less than that.
But to also be able to make very big projects with custom business logic and with performance very good performance with the same too.
So basically the goal is to be able to support both kinds of projects and actually to scale a tiny prototype to production right deeper project without having to touch much of the code.
And mostly thanks to the community, because we add a lot of actually Android of contributions to improve the extensibility of the framework, to fix some performance problem.
To add, we have a very interesting cash subsystem allowing to start all the generated JSON documents in cash servers as Vanisha loud flower thing like that and to not touch PHP at one time, except when there is a change.
We have a lot of features like that 98 platform.
Most of them have been contributed by the community of the framework.
And so it's because it's an open for projects that we are able to have this ability to do something very quickly but also to scale the project right now.
Yeah.
I guess I should correct my earlier mistake on giving the name here, but this is API platform.
Com and for reference, I mean, we're talking 7000 stars, and it looks like you guys really have accelerated a lot in the growth of the popularity in the last year and a half or so.
I have to say, I'm particularly intrigued here.
So one we have a guest who actually knows what I mean when I say Sparkle and RDF, which is I think that's the first.
And I'm just personal curiosity, like a lot of people that kind of maybe go a little too far with graph.
Ql.
Let me tell you a story about a thing called Sparkle and RDF and why it didn't scale.
And I feel like there's commonalities with kind of some of the risks in Graph QL of sort of serendipitous querying.
I get the sense that you know something about that.
Do you feel like there are lessons that are sort of portable from some of the scale issues in Sparkle and what we see become problems with graph.
Ql.
Brad.
I think that indeed with well, we are kind of partially repeating the same mistakes with park and and type.
Okay.
But actually the seven was because at least RDF and all these complex stack was and the governance of the W three C.
And it was a joint work between a lot of companies and universities and things like that.
And now Gravel is just under the umbrella of Facebook.
So on this point and the governance and standard part in Seven was that as a Spark, the tooling is way better.
The developer experience, the marketing and everything like that in west is way better as what has been done with Parker.
But indeed the problem was adding something very open and very hard to put in cash, at least as the protocol level with something like Http.
Yeah.
Because it's all a post, right? Yeah.
Yes, and even when it's not because there are tricks with great to be able to pass the query as a get request, but even when it's not a plastic, very apt to repeating queries that you can easily store in cash.
Basically, I think that it's overused.
There are very interesting use cases for Grad shape.
For instance, if you are building an internal API that you control both older clients and the server and you want just to build your mobile app, and you want to be able basically to access to everything in the database because you trust the client, then it can be a good solution.
If you are creating proxies like you can do with a follow, they give a unified endpoint to access to all your different micro, exposing different formats and things like that as a consistent experience.
To provide a consistent experience, then it can be interesting too.
So they are use cases and the JavaScript tools and Rachel are very nice.
But for most APIs it will be easier to maintain.
It will be easier to scale, and it will be easier to secure to just follow rest strictly and to be sure that there are not so many variants of the same resources that you can expose.
So you can have a good cash to be sure that you secure your you have different URLs for different resources, so you can very easily write security roles and access control rules and to very easily also analyze your logs to see where you must improve the security of the performance or things like that.
I think that for many public APIs, at least we lose a lot when using graph QL and we bring back the same complexity as with Sparkle and things like that.
Without the benefit of the of the global interoperability.
That was the dream of space.
Yeah.
It was to be able to use the Web as a global knowledge base and with RL.
It's not located because it's designed from the ground up for Herod data model though itself build for Facebook.
And it's interesting when you want to query web database.
The good thing with Sparker that you can query many databases and cross the data of these databases.
You can even not do that with great trades.
So in my opinion you lose a lot of public API, but it has interesting use cases for internal API, an API platform.
Indeed, with super both and with the same God with the same definition of the data structures that you want to expose to your API.
You can have both arrest and gravel API.
To be honest, it has been done by someone at my company called Alan Landon.
Most of the work like that because is very interested in gradual and it is an excellent work to implement and excellent interesting work to implement.
All the features of graft and the support of graft in API platform is currently very good.
Okay.
But that being said, we spoke it because some wide contributed it and also because it has some interesting use cases, especially for private API and also because there are a lot of demands.
Okay.
It was a very popular feature request from the community.
But anyway, when we do some consultancy and things like that building public APIs, we always almost recommend to not use Gel because it's often more problems and other to scale that the benefits bring by doing 30 ships.
All right.
Cool.
Well, I'm not the only one who's made this comparison.
I made this comparison ever since Graph kind of got a big buzz around it and shout out to Brian Sletten, who I think in the late outs was talking a lot about semantic Web.
And really, I've never worked with Sparkle and RDF but went down the rabbit hole of learning going this is fascinating.
And then kind of found out actually met some people that had worked with it and said it's great.
But when you have a big complex graph of structured information, you innately create serendipitous trouble in that when you try to in the underlying data actually make those queries work in ways that you didn't plan for.
You look at a database plan, and that means you have a really weird indexing kind of strategy.
Right.
So I think I don't really have anything in Graph QL for the record, but I think it's just it's like a cautionary tale from the past that a lot of people don't know.
but actually I think that we should separate Sparker and RDS because Parker has a lot of interesting use cases, but it's not a good solution for quite at least for now, in my opinion, exactly as Graph QL.
Sure.
It's not a group solution in most use cases when you want to query live data, but when it can be interesting if you can export the data, install locally and then run the queries locally to do some stats or things like that.
Yeah.
But on the other and RDS is very interesting even without sparkle, because the way it makes data interoperable and even the way makes it recommends and it ends using standup data structures and startup vocabularies shape the data exposed to JD.
This is interesting.
And for instance, if you take a look at API platform, you will see that we have a lot of JavaScript components allowing to help you to build your client applications.
So basically we have what we call API platform Hamin, which is a tool to build back offices.
It's quite similar to in the PHP world.
We have a lot of tools to build administrations like easy admin of Sonata, and there are similar things in the Rubian wise world.
For instance, you have a Scaffolding tool in Rubian waves are going to build the back office of the application.
So API platform admin it's almost the same thing visually.
It's the same thing, but under the rule it's just a standalone react component which you can load in any React application, and that will query any API supporting RDF and exposing the documentation of the API following the Hydra Heart vocabulary.
And just with that it will build directly in the browser and administration interface for your API.
So it works out of the box with the server component of API platform, which is written in PHP.
But it also works with all other APIs and all other API framework, which are able to expose RTF documentation of the API and so this part is not related at all with Parker and it doesn't use Parker, but it uses the capabilities the standard Decission actually, which is provided by Harder.
We also have another tooling API platform, which is called the API Platform Client Generator, which is a Scaffolding tool.
This one comes with a lot of skeletons for a lot of popular front end technology.
So basically you have a skeleton for React or view to generate TypeScript definitions to generate skeletons of mobile apps in values frameworks.
And basically it works as the administration system.
It will make our first query to the API.
We tried the standardized documentation of the API in RDS, and it will use the provided skeleton to generate.
This one is a code generation tool to generate a prod application in the select technology.
So basically you select the reactor skeleton and then you get working minimalist but working react application that queries this API.
Again, it works with any API, even if it's not written with the API platform server component, as long as it exposes the data structure as a you could say that we could do that with Open API to and actually these tools have basic support for Open API.
But the thing is that even if Open API is closed from what can be done with Eyebrow and RDF, we didn't manage yet to have the same level of features with Open API, especially because with RDF and JSON and Draw, we are sure of what the API will respond.
The data to.
Those Ramona are always the same, and it's not that or if you want to implement the specification.
So it's easy to write a generic client for that with Open API because by definition it document.
You can document any data structures with Open API.
We can do things and we manage to do interesting things, but it's other and we didn't manage yet to have the same level of feature because of this.
Okay.
Yeah.
Yeah.
I have to admit, I have not spent a lot of time in JSON, LD and Hydra and some of these kind of rest oriented standards, and I didn't really grasp the relevance of RDF and all of its thank you.
Definitely gave me a good obsessive bucket of things to read up on that I feel blind to now.
That's awesome.
and what is very nice for people like you who know what art is and where is that when you take a look at this new way of using RDS, actually, you can even use all these tools without notifying that it's either the when you run the documentation of IDA and things like that, I think that the world RDF isn't written anywhere on the website, and actually it's also because in terms of marketing, it can be a bit scary for people having used the old RDF with XML, RDF and Sparkle and things like that, that was very complicated to you.
yeah.
Alright.
Well again, that's API platform dot com, and I think we've already accidentally dabbled into Kevin's involved in a lot of open source stuff, which certainly fits in nicely with stoplights open source theme.
Lately.
We've been kind of digging into this whole community and figuring out what's going on, but this is definitely a different look than we've had on the podcast here and looking at like I think it's like a common mistake with risk oriented stuff is people go Bake it themselves from scratch, get into trouble and then go rest is too much work.
And so I need to go find something that just works and you end up with the Graph QL kind of scale problems we talked about and things like that.
So this is a valuable perspective to bring.
Although I'm curious to see how many of our listeners are using PHP on a regular basis and would benefit not saying there isn't.
I'm just curious.
Well, Kevin, any kind of closing thoughts for us here on where you see all this going? Kind of things that users of these open source products might kind of benefit from with things you have coming stuff like that.
just under the the PHP thing.
I kind of agree with you.
Basically, when we hesitated when we started the project to use PHP at the time we started the project, PHP was still very popular, still very popular in France, and Symphony is still very popular.
And it's why we started with PHP.
Php is improving every year, and PHP 81 will have a lot of exciting new features.
And it is selling the gap with other languages, and it is now faster than languages as Python, for instance, and things that that has to be to be none.
But instead, if you are not already a PHP dropper, it can be an issue.
And what I really like is that all these formats and RCI one stuff, it will be very basic for API platform.
And I think the Web at World and the API community as well as well is IRA and and and and the words were more implemented by more popular framework, especially in other languages.
For instance, something like a fast API in title is very APHone tool, and it's something that is very, very similar in terms of Awash with API platform is basically the same thing that you start working on the design of your API first and then you add the code.
Something that is a shame, in my opinion, is that a fast API hasn't support for this.
These formats for RDF for granting like that.
And I think that it will be a very big and good step for the API community is more tools outside of the Sinfonia and PHP ecosystem.
We are getting support for Girondin IDA, and it's also the reason of this format is interoperability to have something very interoperable.
We need to in more ecosystem.
Nice.
You didn't have to come on the podcast to make a feature request.
You can just do that anyway.
yeah.
I guess listeners and other languages who are vibing with the story on API platform here.
You know who to talk to now.
I feel like this episode I sounded like older and stodgier than I ever have on here.
I'm like Graph QL is a new fancy crappy thing.
Just look at old sparkle, whatever.
And it maybe sounded like I was knocking on PHP there, but for the record, I love things that you can't kill.
That's why I like Python is one of my favorite things, just because in premise the thing's been around forever and you can't kill it.
It just keeps coming back better and stronger.
I think PHP is in the same bucket.
I've ran a PHP site for ten years.
Yeah, sure.
It's cheap.
It's fast.
It's good.
Every time I work with type quit, I say to myself, Actually, PHP is not that bad.
Yeah, we're a type script shop, so I feel you.
Yeah.
Typescript is a very, very good language.
I feel like PHP fixed everything.
But for instance, I tried to work on something similar to a platform with TypeScript, and I'm sure that I will manage to do something like that.
At some point.
The script hasn't reflection or introspection API.
There is a stub or something, but you have that in Go.
You have that in Python.
You have that in the but not in TypeScript.
Is it makes sense because of the history of TypeScript and because of JavaScript and because of many things.
But when you want to do something so as API is a tumor, fast API, it's a big limitation and you say, okay, PHP has a lot of limitations and had a lot of drawbacks and a bad history, even if it's better or not.
Yeah.
But it also has a very interesting feature that other popular languages that are well known by the common web developer hasn't yet.
Yeah.
Well, you definitely give us some good things to think about here.
I think again, it was kind of a good change of pace to get into some framework specific.
See what is going on in open source world.
And I think all the JSON.
Lg.
Hydra stuff sometimes discount is like, oh, that hasn't taken over.
So it's not the thing.
But I think there's tremendous progress going on.
Thanks, Kevin, for opening our eyes to a couple of things here.
And thanks again, Phil, for helping co host one more time.
So.
Yeah.
Cheese.
Thank you very much for having me for the pleasure.
Yeah.
Absolutely.
And thanks again for listening to the API podcast and we'll see you on the next one.
Alright.
So Billy will hit.
Upper.