Matteo Collina on modular monoliths, Platformatic, and Pino
===

Tejas: . [00:00:00] Hi, and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, air tracking, and product analytics. Try it free@logrocket.com. My name is Tek, and today we have Mateo Colina, co-founder and c t O of Matic, no J S T S C, member Lead, maintainer of Fify, and so much more back today to talk about his recent talk, building a modular monolith with Fify,

it's my great pleasure to introduce someone I've known for a while and I consider a good friend and colleague occasionally. Mateo, nice to see you. How are you today?

Matteo: Hi Tek. Everything is very good today. I'm very, everything is fine and not so much sunshine, but at least we are not raining here in Italy. So I'm very, things are very good. So how about you?

Tejas: Yeah, things are great. There's a lot of sunshine here too. I'm in Greece right now on the,

Matteo: Oh, wow.

Tejas: island. Yeah it's a really nice place to be. Mate, Mateo, I'm really excited to get into your [00:01:00] talk that you just had at node Congress. That was in Berlin. We missed each other cuz I was in Verona,

and you had this talk about building a modular monolith with Fast. Right. So before we do that though I'm sure there's a lot of listeners who I'm undoubtedly are familiar with your work, but I'd love if you could offer them more information about who you are in your background, things like Matic and working with Node being the maintainer at.

Matteo: absolutely. First of all , my modules on M p M . I've been downloaded 70 billion times in 2022. It's if you search Sam in the corporate notice, in your node modules folder or in Slack, Or in any other election based apps, there is my code running of your machine.

So at this point, I am pretty sure that I'm very close to be running on all developers machine. Some code , of mine is running on every developer's machines in the world. This is back in. I'm part of the Noje Technical Steering Committee. I maintain H E D P streams. And [00:02:00] a bunch of other sub-components.

I am Coine. We are a large team in Node. In the past I created the library unk, which is a new HGTP client for Node that you should be using. It is the A you probably are, is a new, it contains the new fetch implementation of no Js 

Tejas: Forgive me. What's the name of this library? You said Uchi. Okay. That's something people listening can take away and use today if they're not already.

Matteo: Yeah.. So it is, it's a library for no js then node js uses all node core users to implement fetch two. It provides a spec compliant fetch implementation. It's spec compliant, sir. So with all the thing that comes from the spec, Which means that is not API compliant compatible with node fetch, which is not spec compliant.

We made fetch happen a few years back. A fetch in node 18 is stable and then it's very happily , at the end of September.

No more, no, all supported versions of no JS will [00:03:00] have a fetch in it. Happy Dave.

Tejas: Awesome. Okay, so this is github.com/noga/oni. They will put this in the show notes for those who wanna click the link

Matteo: . I keep going with introduction, , at some point, I created this as part of Node some other point I created. Uh, Web framework called Fify which are going to talk a little bit about today. Before that, I created a library called Pino, which you should be using for logging.

If you're not using it for logging, you are probably making yourself a disservice. Make it happen. And you should also be using Fify, but I'm not trying to convince you of that. It's it's up to you what you want to do. But for Pinot, yeah, no, there is probably nothing better right now.

Over there. uh, apart from that, we have Fify. Pino. What else? Oh, yes, of course. There is a new book that I have co-authored. Now, you might want to ask how I was able to. Find the time. Okay. This is a question for probably another podcast, not the current one. But this is [00:04:00] the book on Fify that I co-authored.

I'm the small author person that will write the forward of the thing. And I passed the Link Accelerator service side, the management with Fify, which is available , from June 9th. So when you hear this podcast, this is available, so you should probably go and check it out if you want to learn more about Fify.

, since last year, I changed jobs. I was working for a company called Near Form before. And we were doing consultancy, and I moved to startup life, and I started building this company called Matic, which wants to remove all friction from backend development.

We are focusing a lot on how you build your APIs and how you, you are building them with your team. And now you deploy them, and now you don't spend time reinventing the wheel for every single time. So there is a lot of solutions in the platform GI organization that helps you create , APIs very quickly from your database, for example, [00:05:00] or create like little mesh APIs.

So something that, combine multiple things at the same time , and provide to you. A solution that works out of the box, and you don't need to add a lot of other components to make it work. It's all included in the same package, so it's pretty great.

Tejas: Wow. So what I'm hearing is as an intro, hi, I'm Mattia Colina. I do a bunch of stuff. I power all the known modules and you should probably use all of my NPA packages which, you know that's a heck of an intro and I'm here for it. I celebrate that. awesome. . So you mentioned, Fify multiple times, and I'm really excited to get into the details of Fify and talk about um, fify what it is, why Dev should use it. You mentioned multiple times, you should be using it. And I'm sure the listeners wanna know.

Okay. I've been using something like maybe express for a long time. , why should I use Fify? What's the draw there?

Matteo: So Express was designed back at the beginning of note. It has the first mover advantage, and it's a great framework. Okay. also very stable. The last major release was done I think almost 10 years ago at this point.

Something like that. Very [00:06:00] close to, and we can check, actually, this is actually good way , to verify that.

I just want to verify that close to 10, maybe eight, nine to be honest, I don't recall much. It's 4.00. Was shipped nine years ago.

Okay. So nine years ago. So the API has been fixed in the meanwhile. We added Azi eight. We changed a lot of, not core, we changed a lot of the ecosystem. We changed it a lot of things and express stay there. So it's very stable software, not changing much. And not leveraging . The latest and the greatest is that no Jess and JavaScript can offer.

And if you want that, you should check out something else. And on top of that, fify, this is one good motive adopting latest pattern in JavaScript development. On top of that fify is significantly faster than express. , it, almost no overhead compared to no JS core. So it's really thin on the overhead [00:07:00] side of things.

However, at the same time, it offers additional features that you need. For example, it has embedded API validation data validation, so you should be able to specify, validate all the data that comes in your http request. If you're not doing that, and anybody that is telling you to not validate your data before passing it to a database or another API is telling you something that is it's encouraging you to commit to introduce a security breach in your system.

Please be very careful . Of everybody that tells you, oh, but you can just take this parameters and then forward it to a database without running date proper good data validation on it. I'm a few companies are doing that right now, so I'm not trying to put anybody specific on the spot. I'm just telling you should validate your data before doing anything.

Okay.

Tejas: And Fify it makes that easy. It makes that more approachable 

Matteo: Yes, exactly. It's embedded in the framework. Okay. The other first thing is you should not be using console log for logging.,[00:08:00] it's one of the worst possible ways to log, so it's really great. By the way, console log is great for debugging. Okay. Hey, let's debug everything using console log.

I am super behind using console log for logging. Okay.

For the bugging, but not for logging. You want something that is structured. You want structured locks. So you want something that says, oh, this time step was taken at this point in time. That has these options, these parameters, and the parameters are set as in a way that is easy to extract from a machine.

You don't want to,

Tejas: So then you can analyze the logs and do all kinds of bi tasks on them. Okay.

Matteo: Yeah, you can find the stuff and you need a proper logging solution built in to actually be able to do that properly. And And it needs to be embedded in the framework because otherwise you cannot do certain things like have certain routes [00:09:00] being logging at a higher level than others.

So you might want to have your health check to not be logging to, not to not result in your lock. It'll just pollution. Okay. And wasted money to be honest. And, but at the same time, you might want to have all your routes being log logging and so on and so forth. And console log really doesn't make this very easy to do this kind of filtering and processing and decision on top.

So don't use console log. Okay.

Tejas: And if you use a log like this, that was built into the framework. , I'm curious if there's performance implica because there's no JS and I'm really honored to be asking, the expert here on no js, you could do process dot standard out and right to that, or you could do console log.

Right? And the trade offs? Is console log even maybe slower or how does that interplay with each

Matteo: Okay where do I start? , so Pinon doesn't, neither. By default. Okay. Just to give you a hint. So whenever you do logging, okay, you need to think of what is my destination.

You need to pinpoint the [00:10:00] fact that you are producing the logs , to send them somewhere. This somewhere is very important. It can be a remote processing server. Okay? It can be a file, it can be standard output. Each one of the things you are logging to it can be a socket, okay?

As different consideration logging is one of the worst. Problem in software development. It is the reason you have your data coming in your app and you need to serve a response, right? However, your application, while it's doing this activity as , two output that is producing, one is, I dunno, changes in a database probably at some point.

Okay? Changing data and logs. Okay, now, What happens though if , we are writing so much logs that the underlying transport, the underlying destination, cannot keep up where we send the logs to, okay, what [00:11:00] happens? , how do we end all that? Okay. And that is the fundamental reason why Pinot was born.

We want a way to handle the destination in a way that. Is fast and minimizes the amount of memory that is consumed typically To have the two to forward them to now that's very clear. And Pino does a few way that under this in a few ways. So it has file system destination, or it has the concept on transports.

And in fact, we run transports as separate thread inside the same application. So we keep the main event loop as clean as possible. , so that the flushing can happen. a later time. Okay. Of course this cause has some memory concern on the things. So you need to be tweaking the stuff accordingly.

There are where a lot of bag reports about in one of our modules called Sonic Boom. Sonic Boom is this super, super [00:12:00] fast string only alternative to process TD out. So instead of using the one from North Core, it was too slow. So we had to write our own. And it also enable you to handle manually the case of, oh, but the destination is fully busy.

Like we are writing so much logs that the hard desk cannot keep up. How can this happen? You can ask a few of the folks that are working at Netflix, that there are a few good issues. Most of the time they open up issue impossible issues for me and they also send out the patch, so I'm not, I'm not complaining, but it's it's, they're very Oh, we are, they're writing like an enormous amount of log.

Yeah. So it's pretty great. So yes, you should be using pinot.

Tejas: right. So Pinot is this like almost revolutionary logger that will help. Transport logs to in a very high throughput way. It sounds like if

Matteo: Yes, exactly. 

Tejas: And , can the destination of a pinot log be even some type [00:13:00] of distributed system 

Matteo: yes. So we have the concept of transport. So you could write your own transport and the transport can forward the logs. Whatever they want to, and it can run inside the same process as a different thread. It's a great way of doing things. And we are using this approach heavily inside matic. So we have recently shaped a platform cloud, which is a way to deploy your applications, your fify and digest applications very easily.

And what we did, Was, we used this wall transport mechanism to ship the logs to our processor and in a way that was actually, took actually very little time to be developed. So I'm very, it's a very impressive setup and you can check out it . On our cloud, it's actually very easy. You just say, oh, no, this is just works. It's so simple in the browser that, oh, it just works, but it's not that simple. 

Tejas: I'd love to dive more into platform in, in just a [00:14:00] minute, but before we do that, I want to capture the talk that you had at Node Congress. Cause it was a very powerful talk. So I'd love it if for the next few minutes we could even talk about the gist of your talk.

Matteo: Oh, yes, absolutely. Absolutely. Okay. So we completely went. I, every single time somebody invites me to their podcast, I completed the re, the project went completely sideways.

Tejas: it's not, I can tell you as the host, I love that. It's about the conversation . But I also wanna get into the details of Pinot and of of Unci and all of this.

Matteo: . Okay. , I have worked for eight. Years and a half as a consultant helping companies implement using node js. What I have noticed is one single pattern it's most of the problems that people have that teams and developers have in node JS applications and long running projects.

Is that they structure their projects in a unscalable, unmaintainable way. Essentially, they end up developing their code in more or less in a spaghetti [00:15:00] ball fashion. Why the key, the key problem is that , . And sorry, putting the things on express, the original express tutorial at Event Express generator creates an application and treats it as a singleton running inside your process.

And more importantly than that, it has all the bootstrapping of that application done, more or less synchronously, along the way.

Tejas: For the listeners, for those of us who maybe didn't go to, computer science school Singleton. I know people are gonna be

listening and. 

Matteo: okay. Yes. So what is a singleton? , it's an object that you have only an instance of that object. Okay? Now what it happens is you create your database connection. And store it inside the module that is required. Everywhere you put your express your, your node js application, the server as an object, that gets loaded and used everywhere and 

so everything is run via these , global ish [00:16:00] components that you only have one instance of that. Now, why is this problematic and why Singleton is basically this one of the. Biggest anti pattern , that you can essentially find everywhere. Because , it's very hard to test this, okay?

In a test you need, every time you want to test your application, you need to basically, oh, but have all these single to tear down and re and relaunch and so on and so forth. Making it your test low, making your test harder to run. And uh, also exposing yourself to all sorts of bugs when developing the application.

The other problem is that you think that node modules are singletons so that when you do an export of something, it's a singleton. Okay? And , you just have that one instance of that specific module. This is not true. The ecosystem is built around the concept that you can have two different instance of the same module loaded from two [00:17:00] different paths, and they could potentially contain very similar code or do the similar things, and the moment you define them in that way, you are clearly defining your code.

Oh I'm never going to take part a chunk of my library and move it inside a module inside a package that then can be reused somewhere else. , what this causes is as a result of this problem there is the fact the result of this train of thought is what you're doing in that express tutorial that you show at the beginning is essentially doing you at disservice because it's actually a very great tutorial.

So you get to learn something very quick, but you're learning something that does not age very well. Okay? And every single person that has built a complex application will tell you that. Now the, what is the other complex is whenever you start adding, for example, oms that use the [00:18:00] concept of a global connection.

Then you become even less likely that you'll ever be able to split your application or decouple your application over time as much you add code, all of these singletons becomes it, everything passed through the same singletons, okay? And you are very quickly not able to split your code anymore.

So everything become more or less coupled with each other. And leads to essentially a big bowl of mud.

Tejas: Right, and everything becomes coupled to each other because they all depend on this one instance. This one singleton.

Matteo: Typically, yeah. Typically this is part of the biggest problem. Yes.

Tejas: Right, and then you get a giant monolith, and we all know that microservices, or at least we were told that microservice.

Matteo: It's not really about, like the problem is not really about monolith versus microservices. The problem is about coupling between the different part of your applications. You want the different domains inside your application, the different components, different things that you are built, the [00:19:00] part that are built by different human beings ultimately.

Okay? If you have two human being, you probably want to have them working on two different things, not at the same thing at the same time. So if you want their two parts to have as minimal interaction as possible, If you do that's easy to then scale your team and not have a single and not block everything.

But most people, most large node JS application become very hard to maintain long. I've seen a lot, quite a lot. They become hard to maintain because they're not built on top of that staff. , 

Tejas: so it sounds like avoiding these singletons helps, avoid coupling and helps, enforce the single responsibility principle. I saw a great tweet once,, I think it was Dan Ama who said you should write your code in such a way where you can just delete a whole part of it and everything else works fine.

Matteo: exactly that. 

Following that you can see , that principle is very much. Defined in how we structure react component, for example, okay? You do not use global stuff inside React components. , [00:20:00] everything is contained within the component. Why the heck you want to write your JavaScript code?

Like we were writing it in 2009. Sorry about making a good a nice comparison here, but that's the problem that I'm seeing.

Tejas: Yeah, no I, yeah, I see what you mean. Mateo. Always with the hot takes. Okay. We'll do an ad break quickly and then I wanna jump into platform. And I want, I wanna hear it from the Lion's mouth itself. Before that I should mention . Log Rocket offers session, replay, issue tracking and product analytics to help you quickly surface and solve impactful issues affecting your user experience.

With Log Rocket, you can find and solve issues faster, improve conversion and adoption, and spend more time building a better product. 

with that ad break, I want to talk to you now, Mateo, about platform. 

So it sounds like you are this person who has worked at length on Node, GS core on the technical steering committee with a lot of teams, also with Netflix and so on, on your libraries. And now [00:21:00] you're bringing all of this expertise to platform at, and to me this sounds very exciting. Also, as an angel investor in a bunch of other startups, this is a take my money scenario, right?

So I'm curious to hear about Matic, and I'm sure all the listeners are as well.

Matteo: Yes, Matic problematics started with this concept of I've seen companies rebuilding doing the same thing over and over again, doing the same problem with scaffold. My. Not just application. How do I put into production? How do I protect my even loop from thrashing? Now this is probably another alpha hour talk about how to do not make your relevant loop trash.

I would probably do that at a conference at some point. I'm actually wrote the CFP today, so that's why I'm mentioning. But this is essentially the key concept of. How do you do all of that? How do you set up logging? How do you validate, how do you map your database to crowd routes because you don't really want to redo them all over again all the single time.

How do you do microservice? How do you do [00:22:00] microservice communication? How do you set up, you build the clients for your microservice communication. Now this is one of the things that a lot of people do, takes a lot of time because, oh, I'm doing microservices now, and now you need to build clients all the time.

So yeah, it's actually a lot of fun. Okay. And I am pretty excited about platform and what we are building. We just recently opened up our cloud, so now you could essentially give us some money to run your code inside our cloud.

Which is pretty exciting. We've also launched a bunch of other features like API composition, so you can compose multiple. Routes from multiple different rest dash open API routes into the same one. Essentially removing a good part of the problem of building a b FFF and backend for frontend for the people that are watching or listening actually.

And then yeah, that's it to be honest.

Tejas: So it's you've watched a lot of these common problems. You've watched, it sounds like a lot of people reinvent the wheel with a number of things, specifically how you [00:23:00] split up your services and so on and platform addresses those problems 

Matteo: we do it in two ways. First, we provide you an open source library that you can use to build your own applications.

Tejas: but that doesn't make money.

Matteo: That Are you sure? No. Okay. Ask her that. If that does not make money. Ask Red dot, if that does not make money, okay, it's, it makes money. Okay? It can make money, especially because the moment you are doing large talking to a large companies, large enterprises offering a good super plan, it's something that companies are and can be interested on.

Especially because it, this is essentially a turnkey solution. The other thing that we do is we have a platform at cloud, so you can give us some money to run your code essentially. And uh, we support cna, you support all the things that you want. We also have preview environments so that you can easily create a PLE view environment for your app.

[00:24:00] Very quickly, which is great. Then the final bit is yeah, but yeah, our cloud also run cloud prem, so you could even run it inside your system if you want to, which is pretty great, 

to be 

Tejas: you say platform at cloud in exchange for money runs, runs my code so I can run my code on Platform Cloud. Is that comparable to something like I think of, and this is not an endorsement and there's no financial relationship. Of course . , is this similar to conceptually something like aws, e c two or Versa , 

Matteo: it's a server full environment. So you have a long running process. You don't have the problem of functions and serverless in general, which, oh, I just run thing, one thing at a time, which is the worst possible way to get build because you are basically build for not doing anything.

And this is , my main critique about the evolve functions model. Okay. You're receiving a request. And then you typically, you do a database query, or you call another [00:25:00] api,

Tejas: Correct.

Matteo: and then you need to do some CPU to generate your, the response being that the H T M L or just doing a little bit of data manipulation after you have talked to the database.

Okay? Now, the problem with that model is for a good chunk of that time your function. You are paying for the function, for the execution time, but the most of the time , when that runs, is actually doing nothing. So it's a great model to build people for. Okay. Not the model that, not a model that I personally use often because, if you have a lot of invocations, it's not money effective.

Okay. And we have seen that, very often or we are seeing that on Twitter from time to time of people having mad builds from using functions and stuff. It's because of that model essentially.

Tejas: So this is really interesting for me to hear because a lot of people say with the traditional server full approach, you get billed for nothing because if your servers are just running an idle you're still gonna get billed [00:26:00] because for 

Matteo: Oh yeah. Big time. Absolutely. Absolutely. Yes.

Tejas: So it's interesting, but don't you think you would get billed for nothing with the serverless model?

Yes, indeed. For the, like cold start period, you get billed for that. But once the function is warm I can't imagine. you still get billed for idle time or

Matteo: Yes it's, no, it's billed between the time that it take is taking, you are calling another resources to process the request. Cause you're not using that memory, that process, that CPU time to do anything.

Tejas: That's so fascinating. Okay, so then if you get built for nothing in both scenarios I'm curious what . Matics answer

Matteo: Well, The, there are two fundamental difference here. , . So with a ful environment, it's not true that you're b you're building for occupying memory and having a CPU available. Okay. What you do with that CPU is up to you now. \ and this means that if you write \ , your code well in that CPU or that chunk of the CPU that you have available for your service, you could run 10, 20, a thousand requests with the same cost.

So in reality, you, [00:27:00] if your server can process a thousand requests per second, in one case, you have a thousand execution to run and you're paid for a thousand execution. Okay. And on the other end, you're just paying for one server being idle. The moment you pass the original the call start the scale to zero problem where you don't pay for that service running all the time. You can actually enjoy a much better response time. Much better. All the things essentially compared to a serverless model, which to be honest, I had developed, treat a lot of function system. I really like functions. I really like the fact how you combine those systems together.

I really like Lambda. I have built system with Lambda. I build system. Mix the system most of the time. Okay. , if you can see the same concept that I'm talking about very, in a similar way in the article that was published recently from Amazon moving away from Lambda back on a full server.

It's the same concept to be honest. . It's actually very [00:28:00] funny because the marketing part is of the functions is, oh, you can just uh, scale as many as you want. We take care of the scaling, so you don't have to, but then even Amazon says, oh at a certain point it doesn't scale.

Which if , somebody has done some formal studies . On distributed systems. Everybody will tell you that a system scales well within a certain boundary, okay? And that's the problem with Lambdas and so on. And they're great tech.

Okay? It's, they work very well. If your system has no traffic,

Tejas: Yeah.

Matteo: it's 

Tejas: What I hear is Lambda is great if you have low traffic because then you know you don't pay much. But once you pass a certain threshold of invocations, then it becomes way better to switch to a cervical environment, cuz you can service way more people for a fraction of the cost.

Matteo: pretty much. Yeah. The tldr. Yes. This is a good answer from it.

Tejas: This is a practical tool for everybody listening. Is, serverless functions are not the only answer and they may be even worse for you. I think that's something more people need to hear. So thank you for [00:29:00] sharing that. , you mentioned the platform at cloud, which we've discussed now, and I understand and it's actually pretty great. You mentioned two more things that maybe we'll dive into one of them for the sake of time.

You mentioned this open source project where I was like, you don't, that doesn't pay, but you were like, check out Red Hat, which indeed it does pay. I'm curious if you could tell me more about this open source project.

Matteo: Yes. What we have, it's you can add to gi.com/platform platform. And then we have here this contains most of platform, code, dashboard of the cloud. Okay. It has all the basics to build APIs and you can even just run it on top of your dock containers and so on, so it doesn't need much.

You can even run it on Lambda. Okay? This is actually when it gets even more funny because. I even have a guide on how to run it on Lambda. So you could technically run it on Lambda. Do I recommend that? Probably. No, but a lot of people do it anyway, so I'm not who am I to judge? Okay. And by the way, it's great. Like for certain cases [00:30:00] it's actually great. For others, maybe less but it's actually very little line of code like, I dunno, it's like 20 lines of code to run a matics thing on, on Lambda. So you just load the config file and you're good to go.

Essentially. 

Tejas: this is the code then for Matic Cloud as well.

Matteo: Yes. So basically Platform Cloud takes is based upon the service, the this open source project and , what we do at Platform, what we want. The problem that we want to solve really, is we want to standardize the plug that you use when , running, no JS application.

For a server. Okay. And standardize. What is that plug compared to? What you standardize the plug between your service and the cloud running it in. That way . You can actually develop your systems and your teams and your colleagues.

Can actually, oh, but I don't need to do a new fancy deployment pipeline that's done already. Okay. I don't need to do, [00:31:00] I can reuse all the things all the time. Okay. And this is why we can provide, for example, very easy to use ephemeral environments that just disappears. Because we can scale to zero very quickly, it does not depend on the complexity of your app.

It's all about how we run our code. Yeah.

Tejas: Awesome. That helps me understand matic and it also makes me wanna use it, especially cuz it's open source and I can deploy it myself. Awesome. With that. Let's leave it here. Honestly, I wish we had more time, and I say this with every podcast guys, cause I wanna poke your brain for hours and hours and maybe we'll get that chance one day.

But for now I'm curious where can people find you? I'm sure I'm not the only one eager to continue the conversation. So where can people find you and ask you questions and follow you, et cetera?

Matteo: So I have a little bit of a website. Which contains all the links to where I am. This is not land.dev, it's just on my website. It land links to platform and links to everywhere. You could also find platform@platform.dev, 

Tejas: fantastic. Mateo, it's always a pleasure [00:32:00] to talk to you, my friend, and honestly from a personal note, thank you for teaching me about serverless functions and where the cost doesn't make sense and so on. I appreciate the discussion as always, and I look forward to the next one. Thanks again.

Matteo: Amazing.