Exploring the PHP Driver With Jeremy Mikola - Podcast Episode
Rate this podcast
Jeremy Mikola is a Staff Engineer at MongoDB and helps maintain the MongoDB PHP Driver and Extension. In this episode of the podcast, Jesse Hall and Michael Lynn sit down with Jeremy to talk about the PHP Driver and some of the history of PHP and Mongodb.
Michael: [00:00:00] Hey, Jesse, how are you doing today?
Jesse: [00:00:02] Good. How are you?
Michael: [00:00:02] Fantastic. It's good to have you back on the podcast. Hey, what's your experience with PHP?
Jesse: I've done a little bit of PHP in the past. Mostly JavaScript though, so not too much, but today we do have a special guest. Jeremy Mikola is a staff engineer with Mongo DB, and he knows all about the PHP driver. Why don't you give us a little bit of background on how long have you been with MongoDB?
Jeremy: [00:00:26] Hi, nice to be here. So I joined MongoDB just over nine years. So in the middle of May was my nine-year anniversary. And the entire time of year, a lot of employees been here that long. They tend to shuffle around in different departments and get new experiences. I've been on the drivers team the entire time.
So when I find a place that you're comfortable with, you stick there. So when I came on board team was maybe 10 or 12 people, maybe one or two people per language. We didn't have nearly as many officially supported languages as we do today. But the PHP driver was one of the first ones.
It was developed actually by some of the server engineers. Christina, she was one of the early employees, no longer at MongoDB now, but. So yeah, back then it was PHP, Python, Ruby, C# Java, and I think Node. And we've kind of grown out since then.
Michael: [00:01:05] Fantastic. And what's your personal experience with PHP? How did you get involved in PHP?
Jeremy: [00:01:11] So I picked up PHP as a hobby in high school. Date myself here in high school graduation was around 2001. It's kind of the mid nineties getting home from school, load up Napster work on a personal, had a personal SimCity website. We started off around this time of PHP. Nuke was one of the early CMS frameworks back then.
And a lot of it was just tinkering, copy/pasting and finding out how stuff works, kind of self-taught until you get to college and then actually have real computer science classes and you understand there's math behind programming and all these other things, concepts. So it's definitely, it was a hobby through most of college.
My college curriculum was not PHP at all. And then afterwards I was able to, ended up getting a full-time job I working on, and that was with a Symfony 1.0 at the time around like 2007 and followed a couple of companies in the role after that. Ended up being the Symfony 2.0 framework, I was just coming out and that was around the time that PHP really started maturing with like package managers and much more object oriented, kind of shedding the some of the old
bad publicity had had of the early years. And from there, that was also the that second PHP job was where I got started with MongoDB. So we were actually across the street from MongoDB's office in Midtown, New York on the flat iron district and customer support back then used to be go downstairs, go across the street and go up to Elliot's desk and the ShopWiki offices and the Mongo old 10gen offices.
And you'd go ask your question. That kind of works when you only have a few official customers.
Michael: [00:02:36] Talking about Elliot Horowitz.
Jeremy: [00:02:37] Yes, as Elliot Horowitz, the co-founder was much more accessible then when the company was a lot smaller. And from that role ended up jumping to a second PHP company kind of the same framework, also using MongoDB.
It was the same tech stack. And after that role, I was approached by an old coworker from the first company that used MongoDB. He had ended up at the drivers team, Steve Franzia. He was one of the first engineering managers, the drivers team help build the initial, a lot of the employees that are still on the drivers team
now, a lot of the folks leading the teams were hired by him or came around the same time. So the early developers of the Python, the Java driver and so he, we had a interview came back, wasn't allowed to recruit me out of the first job whatever paperwork you signed, you can't recruit your old coworkers.
But after I spent some time somewhere else, he was happy to bring me on. I learned about the opportunity to come on the drivers team. And I was really excited to go from working on applications, to going and developing libraries suited for other developers instead of like a customer facing product. And so that's kind of been the story since then, just really enjoyed working on APIs as well as it was working on the ODM library at the time, which we can talk about a little bit later. So kind of was already involved in a lot of MongoDB PHP ecosystem.
Jesse: [00:03:46] Cool. So let's, let's talk more about that, that PHP driver. So, what is it, why is it useful to our listeners? How does it work?
Jeremy: [00:03:54] okay. Yep. So level set for the basic explanation. So every language since MongoDB to be doesn't expose a ... it's. Not like some databases, that might have a REST protocol or you just have a web client accessing it. So you do need a driver to speak the wire protocol language, and the MongoDB drivers are particularly different from some other database drivers.
We do a lot of the monitoring of servers and kind of a lot more heavy than you might find in an equivalent like SQL driver especially like the PHP SQL drivers. So the drivers much more intensive library with a lot of the network programming. We're also responsible for converting, how MongoDB stores documents in a it's binary JSON format BSON converting that to whatever the language's
natural representation is. So I can Java that may be just be mapping at the Java classes with PHP. The original driver would turn everything into associative arrays. Make sure that a MongoDB string becomes a PHP string, vice versa. And so the original PHP driver you had familiar concepts across all drivers.
You have your client object that you connect to the database with, and then you have your database, your collection. And the goal is to make whatever language to users. Running their application, make the drivers as idiomatic as possible. And this kind of bit us early on because the drivers may be too idiomatic and they're inconsistent with each other, which becomes a struggle with someone that's writing a MongoDB application, in say C# and PHP.
There might be two very different experiences over Python and NodeJS. And the one thing that we hadn't since then was writing specifications to kind of codify what are the areas that we want to be idiomatic, but we also want to have consistent APIs. And this has also been a boon to our support team because if the drivers can behave predictably, both kind of have a familiar API in the outside that our users develop with.
And then also internally, how do they behave when they connect to MongoDO, so kind of being able to enforce that and having internal tests that are shared across all the different drivers has been a huge plus to our support team.
Michael: [00:05:38] So talk, talk a little bit about that, the balance between a standards-based approach and the idiomatic approach, how does that come together?
Jeremy: [00:05:48] Right. So this has definitely been a learning process from the, some of the early specifications. One of the first specifications we had was for the CRUD API which stands acronym for create, read, update, delete. And that was one of the, that's an essential component of every API. Like how do you insert data into MongoDB and read it back? And having that API let's us standardize on a this is a fine method. What are the options that should take how does this map to the servers? And the MongoDB shell API as well.
That was another project that exists outside of the driver's team's control. But from our customer standpoint, the Mongo shell is also something that they're common to use. So we try to enforce some consistency with that as well. And the specifications we want to, at a functional level provide a consistent experience.
But in terms of honoring that every language should be idiomatic. We're going to make allowances that say in C# you have special types to represent time units of time. Whereas other languages like C or Python, you might just use integers or numeric types. So having the specifications say if you're going to express
like the query time or a time limit on the query will allow like C# driver will say, if you have a time object, you can certainly make use of that type. And another language or students providing guidance and also consistent naming. So we'll say this method should be called find or findOne in your language, if you use camel case or you use snake case like Python with underscores, we're going to let you use that variation.
And that'll keep things idiomatic, so that a user using a Python library doesn't expect to see Pascal style method names in their application. They're going to want it to blend in with other libraries in that languages ecosystem. But the behaviors should be predictable. And there should be a common sense of what functionality is supported across all the different the drivers.
Michael: [00:07:26] Is that supported through synonyms in the language itself? So for, you mentioned, find and find one and maybe some people are used to other, other words to that stand for the, the read functionality in CRUD.
Jeremy: [00:07:41] So, this is, that's a point where we do need to be opinionated about, because this overlaps with also the MongoDB documentation. So if you go to the MongoDB server manual that the driver's team doesn't maintain you'll find language examples in there. An initiative we started a few years ago and that's code that we keep in the driver project that the docs team will then parse out and be able to embed in them are going to be manual.
So the benefit of a, we get to test it in C.I. Environments. And then the MongoDB manual you're browsing. You can say, I use this language and then all the code examples, instead of the MongoDB shell might be in your, in C# or Java or PHP. And so having consistent having, being able to enforce the actual names, we have to be opinionated that we want a method that reads the database instead of calling it query or select.
We want that to be called find. So we want that to be consistently named and we'll just leave flexibility in terms of the, the casing or if you need prefixing or something like that, but there's certain common or certain core words. We want users to think, oh, this is a find, this is a find operation.
It also maps to the find command in the database. That's the same thing with inserts and updates. One of the other changes with the old drivers. We would have an update method and in MongoDB different ways that you work with documents, you can update them in place, or you can replace the document.
And both of those in the server's perspective happened to be called an update command. So you had original drivers that would just have an update method with a bunch of options. And depending what options you pass in, they could do myriad different behaviors. You might be overwriting the entire document.
You might be incrementing a value inside of it. So one of the things that CRUD API implemented was saying, we're going to kind of, it's a kind of a poor design pattern to have an overloaded method name that changes behavior wildly based on the arguments. So let's create an updateOne method I replaced one method and updateMany method.
For more information about the PHP Driver's implementation of CRUD, refer to the PHP Quickstart series.
So now that when the users write their applications instead of having to infer, what are the options that I'm passing into this method? The method name itself leads to more by self-documenting code in that user's application.
Jesse: [00:09:31] awesome. So how do users get started using the driver?
Jeremy: [00:09:35] Yeah, so I think a lot of users some, maybe their first interaction might be through the online education courses that we have through MongoDB university. Not every driver, I don't believe there's a PHP class for that. There's definitely a Python Java node, a few others and just kind of a priority list of limited resources to produce that content.
But a lot of users are introduced, I would say through MongoDB University. Probably also through going back nine years early on in the company. MongoDB had a huge presence at like college hackathons going to conferences and doing booths, try out MongoDB and that definitely more appropriate when we were sa maller company, less people had heard about MongoDB now where it's kind of a different approach to capturing the developers.
I think in this case, a lot of developers already heard about MongoDB and maybe it's less of a. Maybe the focus has shifted towards find out how this database works to changing maybe misconceptions they might have about it, or getting them to learn about some new features that we're implementing. I think another way that users pick up using databases sometimes through projects that have MongoDB integrations.
So at the first company where I was using MongoDB and Symfony to in both of them were, it was like a really early time to be using both of those technologies much less together. There was the concept of ORM libraries for PHP, which would kind of map your PHP classes to relational database.
And at the time I don't know who made this decision, but early startup, the worst thing you can possibly do is use two very new technologies that are changing constantly and are arguably unproven. Someone higher up than me decided let's use MongoDB with this new web framework. It was still being actively developed and not formally released yet.
And we need an ORM library for MongoDB cause we don't want to just write raw database queries back and forth. And so we developed a ODM library, object document mapper instead of object relational mapper. And that was based on the same common interfaces as the corresponding ORM library. So that was the doctrine ODM.
And so this was really early time to be writing that. But it integrated so well. It was into the framework and from a such an early point that a lot of users when picking up the Symphony two framework, they realized, oh, we have this ORM library that's integrated in an ODM library. They both have
basically the same kind of support for all the common features, both in terms of integrating with the web forms all the bundles for like storing user accounts and user sessions and things like that. So in all those fleet or functionalities is kind of a drop-in replacement. And maybe those users said, oh MongoDB's new.
I want to try this out. And so that being able to. Have a very low barrier of entry to switch into it. Probably drove some users to to certainly try it out and stick with it. We definitely that's. The second company was at was kind of using it in the same vein. It was available as a drop-in replacement and they were excited about the not being bound to a relational schema.
So definitely had its use as a first company. It was an e-commerce product. So it definitely made use of storing like flexible the flexible schema design for storing like product information and stuff. And then the, we actually used SQL database side by side there just to do all the order, transactional stuff.
Because certainly at the time MongoDB did not have the same kind of level of transactions and stuff that it does today. So that was, I credit that experience of using the right tool for the job and the different part of the company like using MongoDB to represent products and using the relational database to do the order processing and transactions with time.
Definitely left me with a positive experience of using MongoDB versus like trying to shoehorn everything into the database at the time and realizing, oh, it doesn't work for, for this use case. I'm gonna write an angry blog post about it.
Michael: [00:12:53] Yeah, I can relate. So if listeners are looking to get started today, you mentioned the ODM, you mentioned the driver what's the best way to get started today?
Jeremy: [00:13:04] So I definitely would suggest users not jump right in with an ODM library. Because while that's going to help you ramp up and quickly develop an application, it's also going to extract a lot of the components of the database away from you. So you're not going to get an understanding of how the query language works completely, or maybe how to interact with aggregation pipelines, which are some of the richer features of MongoDB.
That said there's going to be some users that like, when you need to you're rapidly developing something, you don't want to think about that. Like you're deciding like uncomfortable and maybe I want to use Atlas and use all the infrastructure behind it with the scaling and being able to easily set up backups and all that functionality.
And so I just want to get down and start writing my application, crank out these model classes and just tap them, store to MongoDB. So different use cases, I would say, but if you really want to learn MongoDB, install the PHP driver comes in two parts. There's the PHP extension, which is implemented in C.
So that's gonna be the first thing you're gonna install. And that's published as a pickle package, like a lot of third-party PHP extensions. So you will install that and that's going to provide a very basic API on top of that. We have a higher level package written in PHP code itself. And that's kind of the offload, like what is the essential heavy lifting code that we have to do in C and what is the high level API that we can implement in PHP? It's more maintainable for us. And then also users can read the code or easily contribute to it if they wish. And so those two components collectively form what we call it, the PHP driver. And so using once those are both installed getting familiar with the API in terms of our documentation for that high-level library kind of goes through all the methods.
We don't, I would say where there's never nearly enough tutorials, but there's a bunch of tutorials in there to introduce the CRUD methods. Kind of explain the basics of inserting and reading and writing documents. MongoDB writing queries at patient pipelines iterating cursors. When you do a query, you get this cursor object back, how you read your results back.
So that would hopefully give users enough of a kind of a launchpad to get started. And I was certainly biased from having been exposed to MongoDB so long, but I think the driver APIs are mostly intuitive. And that's been, certainly been the goal with a lot of the specifications we write. And I'll say this, this does fall apart
when we get into things like say client-side encryption, these advanced features we're even being a long-term employee. Some of these features don't make complete sense to me because I'm not writing applications with them the same way our users are. We would kind of, a driver engineer, we might have a portion of the, the average team work on a, on a new feature, a new specification for it.
So not every driver engineer has the same benefit of being, having the same holistic experience of the database platform as is was easy to do so not years ago where going to say oh, I came in, I was familiar with all these aspects of MongoDB, and now there's like components of MongoDB that I've never interacted with.
Like some of the authentication mechanisms. Some of that, like the Atlas, a full text search features there's just like way too much for us to wrap our heads around.
Jesse: [00:15:49] Awesome. Yeah. And if the users want to get started, be sure to check the show notes. We'll include links to everything there. Let's talk about the development process. So, how does that work? And is there any community participation there?
Jeremy: [00:16:02] Yep. So the drivers spec process That's something that's definitely that's changed over the time is that I mentioned the specifications. So all the work that I mean kind of divide the drivers workload into two different things. We have the downstream work that comes from the server or other teams like Atlas has a new feature.
The server has a new feature, something like client side encryption or the full text search. And so the, for that to be used by our community, we need support for that in the driver. Right? So we're going to have downstream tickets be created and a driver engineer or two, a small team is going to spec out what the driver API for that feature should be.
And that's going to come on our plate for the next so if you consider like MongoDB 5.0, I was coming out soon. Or so if we look at them, MongoDB 5.0, which should be out within the summer that's going to have a bunch of new features that need to end up in the driver API. And we're in the process of designing those and writing our tests for those.
And then there's going to be another handful of features that are maybe fully contained within the driver, or maybe a single language as a new feature we want to write, let's give you an example, a PHP, we have a desire to improve the API is around mapping these on to PHB classes and back and forth.
So that's something that tied back to the doctorate ODM library. That was something that was. The heavy lifting and that was done. That doctor did entirely at PHB there's ways that we can use the C extension to do that. And it's a matter of writing enough C code to get the job done that said doctrine can fully rely on it instead of having to do a lot of it still on its own.
So the two of us working on the PHP driver now, myself and Andres Broan we both have a history of working on Doctrine, ODM project. So we know what the needs of that library are.
And we're a good position to spec out the kind of features. And more importantly, in this case, it involves a lot of prototyping to find out the right balance of how much code we want to write. And what's the performance improvement that we'll be able to give the third, the higher level libraries that can use the driver.
That's something that we're going to be. Another example for other drivers is implementing a client side operations timeout. So that's, this is an example of a cross driver project that is basically entirely on the language drivers. And this is to give users a better API. Then so right now MongoDB
has a whole bunch of options. If you want to use socket timeout. So we can say run this operation X amount of time, but in terms of what we want to give our users and the driver is just think about a logical amount of time that you want something to complete in and not have to set five different timeout options at various low levels.
And so this is something that's being developed inside. We're specing out a common driver API to provide this and this feature really kind of depends entirely on the drivers and money and it's not really a server feature or an Atlas feature. So those are two examples of the tickets that aren't downstream changes at all.
We are the originators of that feature. And so you've got, we have a mix of both, and it's always a lack of, not enough people to get all the work done. And so what do we prioritize? What gets punted? And fortunately, it's usually the organic drivers projects that have to take a back seat to the downstream stuff coming from other departments, because there's a, we have to think in terms of the global MongoDB ecosystem.
And so if an Atlas team is going to develop a new feature and folks can't use that from drivers, no one's going to be writing their application with the MongoDB shell directly. So if we need, there are certain things we need to have and drivers, and then we've just kind of solved this by finding enough resources and staff to get the job done.
Michael: [00:19:12] I'm curious about the community involvement, are there a lot of developers contributing code?
Jeremy: [00:19:19] So I can say definitely on the PHP driver, there's looking at the extension side and see there's a high barrier of entry in terms of like, when I joined the company, I didn't know how to write C extensions and see, it's not just a matter of even knowing C. It's knowing all the macros that PHP itself uses.
We've definitely had a few smaller contributions for the library that's written in PHP. But I would say even then it's not the same as if we compare it to like the Symfony project or other web frameworks, like Laravel where there's a lot of community involvement. Like people aren't running an application, they want a particular feature.
Or there's a huge list of bugs. That there's not enough time for the core developers to work on. And so users pick up the low-hanging fruit and or the bigger projects, depending on what time. And they make a contribution back to the framework and that's what I was doing. And that for the first company, when you use Symphone and Mongo. But I'd say in terms of the drivers speaking for PHP, there's not a lot of community involvement in terms of us.
Definitely for, we get issues reported, but in terms of submitting patches or requesting new features, I don't kind of see that same activity. And I don't remember that. I'd say what the PHP driver, I don't see the same kind of user contribution activity that you'd see in popular web frameworks and things.
I don't know if that's a factor of the driver does what it needs to do or people are just kind of considered a black box. It's this is the API I'm going to do its functionally here and not try and add in new features. Every now and then we do get feature requests, but I don't think they materialize in, into code contributions.
It might be like someone wants this functionality. They're not sure how we would design it. Or they're not sure, like what, what internal refactorings or what, what is it? What is the full scope of work required to get this feature done? But they've voiced to us that oh, it'd be nice if maybe going like MongoDB's date type was more usable with, with time zones or something like that.
So can you provide us with a better way to this is identifiable identify a pain point for us, and that will point us to say, develop some resources into thinking it through. And maybe that becomes a general drivers spec. Maybe that just becomes a project for the PHP driver. Could say a little bit of both.
I do want to point out with community participation in drivers versus existing drivers. We definitely have a lot of community developed drivers, so that MongoDB as a company limited staffing. We have maybe a dozen or so languages that we actively support with drivers. There's many more than that in terms of community developed drivers.
And so that's one of the benefits of us publishing specifications to develop our drivers kind of like open sourcing our development process. Is also a boon for community drivers, whether they have the resources to follow along with every feature or not, they might decide some of these features like the more enterprise features, maybe a community driver doesn't doesn't care about that.
But if we're updating the CRUD API or one of the more essential and generally useful features, they can follow along the development processes and see what changes are coming for new server versions and implement that into the community driver. And so that's kind of in the most efficient way that we've come up with to both support them without having the resources to actually contribute on all those community projects.
Cause I think if we could, it would be great to have MongoDB employees working on a driver for every possible language just isn't feasible. So it's the second best thing we can do. And maybe in lieu of throwing venture capital money at them and sponsoring the work, which we've done in the past with some drivers at different degrees.
But is this open sourcing the design process, keeping that as much the, not just the finished product, but also the communication, the review process and keeping that in it to give up yards as much as possible so people can follow the design rationale that goes into the specifications and keep up to date with the driver changes.
Michael: [00:22:46] I'm curious about the about the decline in the PHP community, there's been obviously a number of factors around that, right? The advent of Node JS and the popularity of frameworks around JavaScript, it's probably contributing to it. But I'm curious as someone who works in the PHP space, what are your thoughts around the, the general decline
of, or also I say the decrease in the number of new programmers leveraging PHP, do you see that continuing or do you think that maybe PHP has some life left?
Jeremy: [00:23:24] so I think the it's hard for me to truly identify this cause I've been disconnected from developing PHP applications for a long time. But in my time at MongoDB, I'd say maybe with the first seven or eight years of my time here, COVID kind of disrupted everything, but I was reasonably active in attending conferences in the community and watching the changes in the PHP ecosystem with the frameworks like Symfony and Laravel I think Laravel particularly. And some of these are kind of focused on region where you might say so Symfony is definitely like more active in, in Europe. Laravel I think if you look at like USB HP users and they may be there versus if they didn't catch on in the US quite the same way that Laravel did, I'm like, excuse me where the Symfony community, maybe didn't develop in
at the same pace that laravel did it in the United States. The, if you go to these conferences, you'll see there's huge amounts of people excited about the language and actively people still giving testimonies that they like taught themselves programming, wrote their first application in one of these frameworks and our supporting their families, or transitioned from a non-tech job into those.
So you definitely still have people learning PHP. I'd say it doesn't have the same story that we get from thinking about Node JS where there's like these bootcamps that exists. I don't think you kind of have that same experience for PHP. But there's definitely still a lot of people learning PHP and then making careers out of it.
And even in the shift of, in terms of the language maturity, you could say. Maybe it's a bit of a stereotype that you'd say PHP is a relic of the early nineties. And when people think about the older CMS platforms and maybe projects like a WordPress or Drupal which if we focused on the numbers are still in like using an incredible numbers in terms of the number of websites they power.
But it's also, I don't think people necessarily, they look at WordPress deployments and things like, oh, this is the they might look at that as a more data platform and that's a WordPress. It was more of a software that you deploy as well as a web framework. But like in terms of them supporting older PHP installations and things, and then looking at the newer frameworks where they can do cutting edge, like we're only going to support PHP.
The latest three-year releases of PHP, which is not a luxury that an established platform like WordPress or Drupal might have. But even if we consider Drupal or in the last, in the time I've been at MongoDB, they went from being a kind of a roll their own framework to redeveloping themselves on top of the Symphony framework and kind of modernizing their innards.
And that brought a lot of that. We could say the siloed communities where someone might identify as a Drupal developer and just only work in the Drupal ecosystem. And then having that framework change now be developed upon a Symfony and had more interoperability with other web frameworks and PHP packages.
Some of those only triple developers transitioned to becoming a kind of a Jack of all trades, PHP developer and more of a, kind of a well-balanced software engineer in that respect. And I think you'll find people in both camps, like you could certainly be incredibly successful, writing WordPress plugins.
So you could be incredibly successful writing pumping out websites for clients on web frameworks. The same way that you can join a full-time company that signs this entire platform is going to be built on a particular web framework.
Jesse: [00:26:28] Yeah, that's kind of a loaded question there. I don't think that PHP is a, is going to go anywhere. I think JavaScript gets a lot of publicity. But PHP has a strong foothold in the community and that's where I have some experience there with WordPress. That's kind of where I got introduced to PHP as well.
But PHP is, yeah, it's not going to go anywhere.
Jeremy: [00:26:49] I think from our perspective on the drivers, it's also, we get to look longingly at a lot of the new PHP versions that come out. So like right now they're working on kind of an API for async support, a lot of the new we have typing a lot more strictly type systems, which as a software engineer, you appreciate, you realize in terms of the flexibility of a scripting language, you don't want typing, but depending which way you're approaching it, as it says, it.
Working on the MongoDB driver, there's a lot of new features we want to use. And we're kind of limited in terms of we have customers that are still on earlier versions of PHP seven are definitely still some customers maybe on PHP five. So we have to do the dance in terms of when did we cut off support for older PHP versions or even older MongoDB versions?
So it's not quite as not quite the same struggle that maybe WordPress has to do with being able to be deployed everywhere. But I think when you're developing a project for your own company and you have full control of the tech stack, you can use the latest new features and like some new technology comes off.
You want to integrate it, you control your full tech stack. When you're writing a library, you kind of have to walk the balance of what is the lowest common denominator reasonably that we're going to support? Because we still have a user base. And so that's where the driver's team we make use of our, our product managers to kind of help us do that research.
We collect stats on Atlas users to find out what PHP versions they're using, what MongoDB versions are using as well. And so that gives us some kind of intelligence to say should we still be supporting this old PHP version while we have one, one or 2% of users? Is that, is that worth the amount of time or the sacrifice of features?
That we're not being able to take advantage of.
Jesse: [00:28:18] Sure. So I think you talked a little bit about this already, but what's on the roadmap? What's coming up?
Jeremy: [00:28:24] So Andreas and I are definitely looking forward when we have time to focus on just the PHP project development revisiting some of the BSON integration on coming up with better API is to not just benefit doctrine, but I'd say any library that integrates step provides Object mapper on top of the driver.
Find something generally useful. There's also framework integrations that so I mentioned I alluded to Laravel previously. So for Laravel, as a framework is kind of a PDA around there or on that ships with the framework is based around relational databases. And so there is a MongoDB integration for laravel that's Kind of community developed and that kind of deals with the least common denominator problem over well, we can't take advantage of all the MongoDB features because we have to provide a consistent API with the relational ORM that ships with Laravel. And this is a similar challenge when in the past, within the drivers team or people outside, the other departments in MongoDB have said, oh, why don't we get WordPress working on them? MongoDB around, we get Drupal running on MongoDB, and it's not as easy as it seems, because if the entire platform assumes because... same thing has come up before with a very long time ago with the Django Python framework. It was like, oh, let's get Django running on MongoDB. And this was like 10 years ago. And I think it's certainly a challenge when the framework itself has you can't fight the inertia of the opinionated decisions of the framework.
So in Laravel's case they have this community supported MongoDB integration and it struggles with implementing a lot of MongoDB features that just kind of can't be shoehorned into that. And so that's a project that is no longer in the original developers' hands. It kind of as a team behind it, of people in the community that have varying levels of amount of time to focus on these features.
So that project is now in the hands of a team, not the original maintainer. And there, I think, I mean, they all have jobs. They all have other things that they're doing this in their spare time offer free. So is this something that we can provide some guidance on in the past, like we've chipped in on code reviews and try to answer some difficult questions about MongoDB.
I think the direction they're going now is kind of, they want to remove features for next future version and kind of simplify things and get what they have really stable. But if that's something when, if we can build up our staff here and devote more time to, because. We look at our internal stats.
We definitely have a lot of MongoDB customers happen to be using Laravel with PHP or the Symfony framework. So I think a lot of our, given how many PHP users use things like Drupal and WordPress, we're not seeing them on MongoDB the same way that people using the raw frameworks and developing applications themselves might choose that in that case, they're in full control of what they deploy on.
And when they choose to use MongoDB, we want to make sure that they have as. It may not be the first class because it's that can't be the same experience as the aura that ships with the framework. But I think it's definitely there's if we strategize and think about what are the features that we can support.
But that, and that's definitely gonna require us familiarizing ourselves with the framework, because I'd say that the longer we spend at MongoDB working on the driver directly. We become more disconnected from the time when we were application developers. And so we can approach this two ways.
We can devote our time to spending time running example applications and finding those pain points for ourselves. We can try and hire someone familiar with the library, which is like the benefit of when I was hired or Andreas was hired coming out of a PHP application job. And then you get to bring that experience and then it's a matter of time before they become disconnected over the next 10 years.
Either, yeah. Either recruiting someone with the experience or spending time to experiment the framework and find out the pain points or interview users is another thing that our product managers do. And that'll give us some direction in terms of one of the things we want to focus on time permitting and where can we have the most impact to give our users a better experience?
Michael: [00:31:59] Folks listening that want to give feedback. What's the best way to do that? Are are you involved in the forums, the community.MongoDB.com forums?
Jeremy: [00:32:09] so we do monitor those. I'd say a lot of the support questions there because the drivers team itself is just a few people for language versus the entirety of our community support team and the technical services department. So I'm not certainly not going on there every day to check for a new user questions.
And to give credit to our community support team. Like they're able to answer a lot of the language questions themselves. That's something, and then they come, they escalate stuff to us. If there's, if there's a bigger question, just like our paids commercial support team does they feel so many things ourselves.
And then maybe once or twice a month, we'll get like a language question come to us. And it's just we're, we're kind of stumped here. Can you explain what the driver's doing here? Tell us that this is a bug. But I would say the community forums is the best way to if you're posting there. The information will definitely reach us because certainly our product managers the people that are kind of a full-time focus to dealing with the community are going to see that first in terms of, for the drivers we're definitely active on JIRA and our various GitHub projects.
And I think those are best used for reporting actual bugs instead of general support inquiries. I know like some other open source projects, they'll use GitHub to track like ideas and then the whole not just bug reports and things like that. In our case, we kind of, for our make best use of our time, we kind of silo okay, we want to keep JIRA and GitHub for bugs and the customer support issues.
If there is open discussion to have, we have these community forums and that helps us efficiently kind of keep the information in the, in the best forum, no pun intended to discuss it.
Michael: [00:33:32] Yeah, this has been a great discussion. Thank you so much for sharing all of the details about the PHP driver and the extension. Is there anything we missed? Anything you want to make sure that the listeners know about the about PHP and Mongo DB?
Jeremy: [00:33:46] I guess an encouragement to share a feedback and if there are, if there are pain points, we definitely like we're I definitely say like other like over languages have more vocal people. And so it's always unsure. It's do we just have not had people talking to us or is it a matter of or the users don't think that they should be raising the concerns, so just reiterate and encourage people to share the feedback?
Jesse: [00:34:10] Or there's no concerns.
Jeremy: [00:34:12] Yeah. Or maybe they're actually in terms of our, our bug reports are like very, we have very few bug reports relatively compared to some other drivers.
Michael: [00:34:19] That's a good thing. Yeah.
Awesome. Jeremy, thank you so much once again, truly appreciate your time, Jesse. Thanks for for helping out with the interview.
Jesse: [00:34:28] Thanks for having me.
Jeremy: [00:34:29] Great talking to you guys. Thanks.
We hope you enjoyed this podcast episode. If you're interested in learning more about the PHP Driver, please visit our documentation page, and the GitHub Repository. I would also encourage you to visit our forums, where we have a category specifically for PHP.
I would also encourage you to check out the PHP Quickstart articles I wrote recently on our Developer Hub. Feedback is always welcome!
Rate this podcast