Interview : Uri Goldshtein explique Meteor et ses autres travaux
Wassim continue sa série d’interviews de programmeurs de talents. Cette fois c’est Uri Goldshtein qui va devoir affronter un barrage de questions concernant ses domaines de prédilection, à savoir Meteor et Apollo.
WCH: Hi Uri.
URI: Hello Wassim
Can you introduce yourself?
I guess you’re the perfect person to answer my next question: what is Meteor?
…I guess that you mean for both the client and the server?
How does Meteor work under the hood?
Uri Goldshtein : If you think about it, when you develop an app, you need to have a front-end framework, a back-end framework and a way to distribute the data between those two, which is the hardest thing to do. You also need a build tool and a package manager around it. So Meteor gives you all of that in a very simple package. Just what you need to get started. And the important thing about Meteor is that, even sometimes people don’t think about it, everything is pluggable…
What do you mean by “everything is pluggable”?
Uri Goldshtein : By “everything”, I mean that you could for instance work with Meteor without its build system, you can use your existing webpack build system if you like. You can use Meteor with React or Angular. You also can use Meteor as a REST server. Meteor is just based on Node: this means you can use any NPM package (or Node code) with Meteor.
Nice! So what are the new features of the version you released a few months ago?
Uri Goldshtein : The v1.3 was a very important milestone for us. First of all, we landed native support for NPM. So even though Meteor has its own package manager, which is called Atmosphere, you can now use it with NPM, or just NPM if you want, of course. We’ve also added native ES6 support using BabelJs as a transpiler. With Meteor, you can add any NPM package, so for instance we created a TypeScript package which adds TypeScript support. Of course, both for the server and the client. Another important feature is ES6 modules support! You now have native support for ES6 modules out of the box. And the coolest thing is that you can start using it gradually. And one last thing to mention is the support for easier testing.
Uri Goldshtein : The next version, 1.4, which is already in beta and should be out in a week or so, will add support for NodeJs 4, 6 and MongoDB 3.2. Another thing we are thinking about is how we can transition our package system from Atmosphere to NPM. We want Meteor to be based solely on NPM future versions.
Why do you want to move to NPM?
Speaking about the community, you’re also a celebrity in the Angular one. You wrote the Angular-Meteor package. Can you tell us more about it?
Uri Goldshtein : I actually started as an Angular developer really early. I think when Angular was in version 0.9, nobody knew what Angular was. One day, I gave a talk about Angular, and there was this guy who came to me after the talk and he was talking about Meteor. He told me he was not a programmer and he managed to build his product for his startup in just 3 months with Meteor. So, I was thinking: « Ok! now I need to check this Meteor out« . So I looked at it, but back then people were saying: “you can’t use Meteor with Angular”. And they were always comparing both frameworks. I then decided to look in the source code and figured out how things worked under the hood. After that, I decided to combine both Angular and Meteor. Why do you have to choose, right?
I wrote the connector and then I was able to use Meteor into all my existing Angular applications. But more importantly, I could still use all my Angular’s knowledge. More recently, I also wrote the Angular2-Meteor, so you can use Meteor with your existing or future Angular2 applications as well. I do this because I believe in Angular!
So, you would use Meteor on the server-side and Angular2 on the front-end, right?
Uri Goldshtein : Right! Right now with Angular-universal, you can use Angular server-side. There is something interesting with Angular2 and Angular-universal: they are much easier to work with! I remember back then with AngularJs (1.x) we had to create Angular-server, which let you use your AngularJs code on the server. You could literally write your Angular code and run it on the backend. And then, call your Angular services, from the client side. For the developer, this was completely transparent. This tool, Angular-server, was the easiest way to write Angular code on the server. You could then proclaim yourself as a « full stack » Angular developer! [laughs]
I showed that at ng-vegas. I wrote an AngularJs service and then just dragged it into the server folder and it just worked! And now, with Angular2 it is even much simpler.
If you take a minute and think outside the box, you can use all the power of Meteor and do so many cool things on the server.
That sounds really cool! At this AngularCamp, you gave a talk about “GraphQL”. Please tell us more about this technology.
Uri Goldshtein : GraphQL is an application query language, that lets you query the server for data. In my opinion, it’s the best way for a front-end developer to interact with a server and ask for data. Right now, we’re all probably using REST to fetch data or WebSocket (or similar) for real-time data.
REST has some limitations. First of all, you don’t know what data you are going to fetch from the server and how it will look. Also, if you want to fetch a complex resource (with too many relations), you will end up doing this with a couple of HTTP requests. However with GraphQL, you will only need one request to get exactly the data you want. Besides, each client can fetch different resources, without having to update the server-side code that delivers those resources. For instance, let say you have an Android app that needs a list for users with their names and photos, and another Angular app that needs a list of users, with their names, photos, ages and a list of friends (including names, ages, etc.) The server side does not need to do any extra thing to handle those two different clients.
GraphQL came from Facebook. They basically had the same problem. When they built the native mobile app, they invented GraphQL in order to be able to use their huge existing backend without having the need to update it in order to support new clients. So currently, all of their apps (mobile and Web) are using GraphQL infrastructure they built in 2012. Just think of it, they are using the same backend since 2012, for multiple clients! It’s really amazing! I believe it’s the future for infrastructure that delivers content for mobile and web applications.
It seems very promising! In your talk you also mentioned « Apollo ». What is it?
Uri Goldshtein : « Apollo » is basically a set of tools for both the client and the server to work with GraphQL. Facebook released “Relay” which is a client library for React that works on top of GraphQL. Relay is really good but it is also really overcomplicated. Even some Facebook developers think that. React developers find Relay too hard too. And of course, if you are an Angular developer, you can’t use it. There are a couple of other alternatives, but they are not as good as Relay.
Apollo is an open source client-side library, that does all what Relay does but in a much simpler way. And it also has native support for Angular from the start! And later on, we’ll build services on top of Apollo, such as a hosted media layer, other services like performance analytics tools to inspect your endpoint, because GraphQL allows you to fine trace your endpoints (which field take to most time, etc.) We’ll give you those tools as well.
The most unique feature of Meteor is how it handles data transfer between the client and the server. We even had created our own protocol (DDP). With GraphQL, we think it’s a very interesting protocol and we believe it’s the future. So we took all of our knowledge from Meteor and used it to build our solution around GraphQL. And we are giving you all the tools to simplify as much as possible the data synchronization between the client and the server. This is Apollo. What’s cool about Apollo is that you can use it gradually with your Angular apps and existing REST backend. Our goal for the future is to bring Apollo to Meteor ecosystem.
So you seem to really believe that GraphQL is the next thing. What is your opinion about the future of backend technologies (REST & co.)?
Another thing that I think we will see in the future is real-time data sources. And this is exactly what Meteor is doing right now. But we are going to see more and more of those technologies. There are, of course, other alternatives such as Horizon. There are also real time databases like Firebase which push the information to the client. GraphQL already supports real time backends. All real-time features that Facebook depends on are handled by GraphQL. So unlike Firebase and Horizon, this is a standard and open protocol that also supports real time.
One last question about something completely different. At the AngularCamp, you gave an AMA session and you talked about « Digital Nomads ». Please tell us more about this way of life?
Uri Goldshtein : I don’t remember how I started being a “Digital Nomad”. As a developer, I wanted to do a lot of things but I had to deal with the priorities of my boss, like any employee. I came to realize that a manager or a company are not smarter than me. Besides, you are at your best when you do what you want and love. But of course, I couldn’t leave the company just like that: I needed money. So I was thinking: “why do I need money for?” – “What are the reasons that make me need money?” Rent, food, various bills… And I’ve always loved to travel. I just realized that if I can travel “cheaply”, I could become a freelancer and do what I love, work on projects that matter to me, in companies that I want to work with. This would allow me to be a good developer because I would be working on things that I care about. I don’t really think there are better developers or smarter developers. There are just developers that work on things they love and others who don’t (or can’t). Speaking about my own experience, everything I have is in one backpack (see picture below). I have solar panels, a sleeping bag, etc. Really everything I need. So it’s easy to manage. I think that being rich is not about how much money you earn, but how less money you need. If you earn a lot of money, you need to keep earning that amount of money, but if you don’t have a lot of expenses, you do whatever you want. The important question to ask yourself is “why do you need money?”
So after I figured this out, I could work on any project and I choose the company I wanted. That is why I’ve chosen Meteor because I really believe in that company. But again, I work there as a freelancer and it was my choice. I remember talking with Geoff Schmidt, who is probably the smartest guy I know and he asked me: “We can pay you, but if we don’t pay you would do the same job, right? » So I told him it was true. Because I believe in Meteor. And if one day I stop believing in Meteor, then I have the freedom to do whatever I want.
This is really inspiring. Thank you Uri. Do you have any last word to say to our readers?
Uri Goldshtein : It’s very easy to become an open source developer. You start doing basic contributions, like +1 answers on stack overflow, after that you start creating and sending issues. It is super easy. Then you get to meet people. I personally met people at Meteor, the Angular team, people from the React team. And when you’re outside of that “world”, sometimes you feel like those people are “super smart people” and that “they are amazing”. But again, they just work on things they love, they are not super smart. We are all the same and it’s not a different level. You just need to start doing what you love. Don’t be afraid. Fear just hold you back from doing things you love. A really good example is what you, Wassim, do on Angular-universal. This is really an amazing thing you do with Patrick and Jeff. Keep on the good job. Just do what you love.
Thank you Uri, I really appreciate what you do for the community.