REST, GraphQL, and Founding a Startup, with Michael Paris and Vince Ning

We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now

GraphQL and founding a startup

In this episode of the Versioning Show, Tim and David are joined by Michael Paris and Vince Ning, founders of Scaphold.io, a backend as a service for GraphQL. They discuss quitting your job and founding a startup, Y Combinator funding, making great products by “making great users”, the advantages of GraphQL over REST, capturing the zeitgeist, and disobeying parents.

Show Notes

Conversation Highlights

It’s just been a dream of ours to be a part of this whole startup community. It’s kind of this generational movement.


we called our parents, and I was like, Dad, I’m about to quit my job, and he was like, Don’t do that. I was like, I’m going to do it, and the rest is history.


It didn’t make sense to me that every single time you wanted to start an app you had to go to Amazon and spin up web servers and databases and figure out security and figure out scalability and all these things that could really be sandboxed.


They pushed us to launch, pushed us to figure out growth, made us start thinking about metrics — and everything, you’ll find, is very metric driven. That’s one of the first things they preach is, If you’re not talking to your customers, if you’re not figuring out what’s working, what’s not working, then you’re not going to be successful.


A lot of founders fall into the trap that they end up thinking they need to do all these different things, whether it be PR, whether it’ll be this, whether it be going to this meeting, going to that meeting, talking to this person. At the end of the day, it’s all about building a product that your users will love — which means talking to your customers, and it means growing the community around your platform.


You don’t want to make a great product. You want to make a great user. I love that idea. The product’s only as valuable as the user is able to make it, and that’s something that it took us a little while to figure out.


I think our early adopters were people that were very interested in GraphQL, and something that we had going for us early on is that it was timely. I think we caught this technology in its nascency, and it was something that we were in a cool position that we could help develop it.

Michael Paris and Vince Ning on the Versioning Show

Transcript

David:

Hey, what’s up everybody? This is M. David Green …

Tim:

… and this is Tim Evko …

David:

… and you’re listening to episode 23 of the Versioning podcast.

Tim:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

David:

Today we’re talking with Michael Paris and Vince Ning, and they are the founders of a startup that’s a “backend as a service” for GraphQL, called Scaphold.io. Let’s go ahead and get this version started.


Michael, Vince, how are you doing today?

Michael:

Great. Thanks for having us on the show.

Vince:

Yeah, cool. Awesome to be here.

David:

Cool. I wanted to thank you for joining us, and because this is The Versioning Show, we like to do something special. We’d like to ask you a philosophical question, and this is going to be for each of you.

Michael:

Okay.

David:

In your current careers, what version are you, and why?

[Laughter]

Michael:

Let’s call it version 1.7.

David:

Why?

Michael:

We’re almost … Yeah, so I think of my version 1.0 or from 0 to 1, being the learning phase and the really early stage of my development, and we’re pretty recently out of college. We graduated about 2 years ago. I think of the stage after college getting me up to .7 and getting us through this first stage of Scaphold.io. And we’re still learning and still rapidly trying to absorb as much knowledge as we can, but I wouldn’t even say we’re quite to 2.0 quite yet.

David:

What about you, Vince?

Vince:

I would say on a scale of 0 to 100 versions, I would say I’m a version 10, probably. Very arbitrary, but just mentally, relatively, I’m at about a version 10. So basically the idea of that is 0 to 1 comes from just me growing up and learning how to code, learning how to build things, and then now it’s time to take it to the real show, the real deal in the industry — seeing what we can do with stuff that we learned in our formative years. So, like Michael said, we did just graduate from college, about almost two years out, but we’ve learned so much that I would say it’s past the 2, past the 3, about a 10, but there’s still a full career left. That’s the 10 to the 99 to the 100. That’s where I’m at right now.

Michael:

It’s like the Island of Knowledge analogy: the more we learn, the more we realize we don’t know.

Vince:

Exactly.

David:

Cool. So you’re fresh out of college. Did you go to college together?

Vince:

We did. We did. We actually met our first year of college. We were just hanging out. I was friends with a bunch of his high school friends, and we spent a lot of time together, but not until fourth year did we start working together.

David:

Did you study in engineering fields?

Michael:

Yeah. We both graduated with a computer science degree. Vince also double majored in economics, and I had a business minor.

David:

Well, hey, Tim. That makes these two pretty special among our guests, because usually our guests, although they work in tech, often we find that they have not had a background in studying engineering.

Tim:

Yeah. In fact, both of them have at least 4 more degrees than I do, so that’s good for you guys.

David:

So you’re working on a startup. That’s an interesting direction to go in these days. Clearly, the industry is full of fast-moving technologies, and some people go in as independents. Some people go in as engineers, and you decided to go found a company. Tell us a little about that and how you got started with that.

Michael:

Yeah, sure. When we graduated, we both had jobs at Microsoft, so the first … I think I lasted about 9 months. Vince was a little longer. When we first got into the industry, we were working for the big tech company. I used to work for SQL Server, SQL Azure, the cloud offering for databases at Microsoft. And then Vince worked for the internal tools and the financial systems. It’s always been a bug of ours. We’ve always had side projects, and in college, we pursued a couple entrepreneurial things and had some success. Some ideas were more successful than others, and we got to present at certain conferences and won some competitions. It’s something that’s always bit on to us early. It might be that we’re young and we haven’t learned otherwise yet, but from the day that we started at Microsoft it was very much, All right. How do we get the idea to quit? Let’s figure out how we get out of this place. Not to say it was a bad place to work! It was a great place to work, but we were willing to throw it all away.

David [4:02]:

I know how that is. Some people are oriented toward being employees somewhere, and some people are oriented toward running the show themselves.

Vince:

Yeah. I think there is a stage in our lives, for me at least, where I would prefer a more stable job, 9–5 kind of deal, more predictable, but for now, I think we have the young energy in ourselves — 20 or so years old — we have all the light of day and night to work on these things with no families or responsibilities, or too many responsibilities, I’d say, to work on these things. It’s just been a dream of ours to be a part of this whole startup community. It’s kind of this generational movement.

Michael:

Yeah. We’ve lucked out as well. I mean, part of the reason that got us into the company was we had this idea about a little over a year ago, and we were working on it in our after hours. We were still working at Microsoft for a long time, and then we’d come home and we’d hack from 6 to midnight and then repeat. Go to work, do the same thing, and then it really was Y Combinator that got us to take the leap, because we actually applied to the YC Fellowship program and ended up getting it back in last March/last April. They basically were like, Okay, why haven’t you quit yet?

They were the ones that were … we called our parents, and I was like, Dad, I’m about to quit my job, and he was like, Don’t do that. I was like, I’m going to do it, and the rest is history.

Tim:

Well, that certainly sounds intense. You two are the first people that we’ve spoken to that have gone through Y Combinator, so I’m sure we’ll have a ton of questions about that process. But first off, you mentioned Scaphold.io. Do you mind telling us a little bit about what that is, the problems you’re trying to solve, etc?

Michael:

Sure. The founding story goes that it was a product we were originally creating for ourselves. I mentioned that we had worked on a couple of projects in our past. We had done social media things. I had built essentially the craigslist for UVA students to trade books and all these things, and we found that often you recreate the same thing over and over again. Most applications have a lot of the same infrastructure behind them. It didn’t make sense to me that every single time you wanted to start an app you had to go to Amazon and spin up web servers and databases and figure out security and figure out scalability and all these things that could really be sandboxed.

The idea started with actually a Hacker News post that I saw first, and they were talking about this new technology called GraphQL. I dug into it, and I got Vince to start looking at it, and we really found out that this technology really improved upon the way that you could build client-side applications, but there was still a lot of headache on the back side. You still had to do a lot of the service architecture — a lot of the databases and backups and everything like that. So we decided, Let’s build a system or a service that lets people get all the benefits of GraphQL, which are primarily seen from the client side, and then we’ll do all the nitty gritty stuff underneath to make it really easy to spin those systems up. We’re essentially removing friction, allowing people to build data systems with GraphQL really quickly.

That’s what Scaphold does. In a matter of minutes, let’s say you wanted to build Instagram, for example. At a high level, you can think, Okay, I have users, and I have posts, and I have comments. They have to relate to each other in certain ways. When you’re an engineer, it doesn’t work that way. You’re worrying about all that stuff I was talking about. We allow you to think at that high level, and then you come to our system and you say, Okay, I need users and posts and comments, and they have these fields and they relate to each other in this way, and our system spins up all of the messy stuff and then exposes this API to you that lets you immediately start building applications with GraphQL.

Tim:

That sounds very cool. Just one level deeper … I’m so sorry. For any of our listeners who don’t quite understand how GraphQL works or what exactly it does, do you want to go a bit into that as well?

Vince:

Sure. The history of GraphQL is there was a project. It’s a technology that was created at Facebook, I think in 2012, and they used it a lot internally, deployed in production to power all of their mobile apps, web apps, pretty much their entire infrastructure. As you can tell, it’s a very scalable production-ready solution. About last year or early 2015, so two years ago, they open-sourced this technology to the public to get everyone — all sorts of developers across the web — to start using this awesome new technology because they said, Hey, it works great for us, and we’re one of the largest tech companies with the most data in the world. This could probably work for everyone else.

So they open-sourced it, and this is when Michael brought the idea of GraphQL and told me about it. And we started picking at it, and thought it was an amazing idea where you just have one API to interact with all of your data. And this is where the birth of this service idea came from, where you can not have to worry about generating all of the verbosity that comes with creating a GraphQL server and being able to leverage the benefits of it from the client side.

Michael [8:34]:

Right. The common misconception, though, is that GraphQL is a database. One thing that I want to clear is up is that GraphQL is not a database. If your listeners are familiar with a REST API, GraphQL is essentially REST 2.0. It sits at the very front of the server, and it’s the language that the client uses to communicate with the server, but it actually doesn’t really know much about the data. That’s what we provide. We take this awesome technology that sits at the very front, and then our customers speak GraphQL to us, and then we speak to different databases and APIs that allow us to present the data in a really friendly way to the client via GraphQL.

David:

That’s a good way to explain it. I was going to ask. I’ve heard people talking about GraphQL and talking about it in comparison to REST, and it also seems to be that it started to come into the zeitgeist right about the same time people started talking about React.

Michael:

Yeah. That’s another inteRESTing thing. I don’t think it’s coincidence that both of those projects come out of Facebook. And it’s something that we’ve found more and more. The more that we’ve used GraphQL, it almost inspires you to think in a more functional way. You start thinking about React preaches this uni-direct, this single flow of data — this one-way, one-directional flow of data. GraphQL abides by that. It essentially allows you to traverse this tree of data, and if you think of your application as a tree of components — which React inspires you to do — it’s really a one-to-one mapping between a GraphQL API and a React application.

You’ll find that when you build React apps with GraphQL, you’re often writing better code than you would if you were trying to retrofit a React app with REST or really anything else.

Tim:

You mentioned Y Combinator. I want to ask a little bit about that. What’s it like? [Laughter] How was the process for you guys?

Michael:

This is actually our second run through. We did the fellowship back this past summer, and we’re based out of Seattle — because we were working at Microsoft and we had a house. The fellowship is a remote program, and they actually changed it recently. I think we were the last batch of the previous iteration of the fellowship program. But that essentially was younger-stage companies that were in their early, early development phases. We went into our interview with a functional prototype. We hadn’t launched yet. They pushed us to launch, pushed us to figure out growth, made us start thinking about metrics — and everything, you’ll find, is very metric driven. That’s one of the first things they preach is, If you’re not talking to your customers, if you’re not figuring out what’s working, what’s not working, then you’re not going to be successful.

Vince:

Yeah.

Michael:

Then we ended up going through the fellowship program last summer, had some success, got a lot of early adopters on the platform, and then we actually reapplied to Y Combinator after the fellowship, because we hadn’t had enough. It was a 2-month program; we wanted more. We got accepted into this current winter batch. We’re actually in a house right now. 3 companies are living in this house all in our winter batch. The one thing is it’s just a lot of work. You’re working all the time, and that’s really what they preach — you’ve got to be metrics driven. You’ve got to be talking to your customers, but it’s really a 3-month sprint and it’s growth. 10% every week. If you can get more … They want you to 10x in 3 months. They’re just pushing you to really figure out what’s working, and then to keep going.

Vince:

Yeah. There’s not much magic in the program. It’s just you go in, they tell you, You need to just work really hard to work at one focused goal. A lot of founders fall into the trap that they end up thinking they need to do all these different things, whether it be PR, whether it’ll be this, whether it be going to this meeting, going to that meeting, talking to this person. At the end of the day, it’s all about building a product that your users will love — which means talking to your customers, and it means growing the community around your platform.

David [12:14]:

So you two are the founders, and you’ve started this company. You’re living in this house and you’re building this thing actively. Is the company limited to just you two at this point?

Michael:

We have a couple of other people helping us. We’ve reached out to a student at Wash U —

Vince:

Washington University in St. Louis.

Michael:

Yeah, Washington St. Louis, and we have a student at MIT, and then actually a woman that lives in my home town of Virginia Beach that was involved. They’re doing a great job helping us with marketing and outreach and finding relevant people in the space and doing a lot of the things that … We build most of the product, and then they’re helping us smooth out the edges, and helping us figure out how to track our metrics best and things like that.

David:

I’m curious how the logistics of something like that would work. Because the finances, the expense of getting people involved in something like that while you’re still essentially students on a fellowship building this thing.

Michael:

Yeah. I think we were lucky. I think that the people we found to help us really believe in the product, and it’s something that they almost came and they were willing to work for less because we’re a young company. We’re still trying to bootstrap our financials and everything, but they were very much willing to put in the work for perceived gains in the future without us having to pay the $100,000 that Microsoft would pay.

David:

That’s true. It’s expensive to get people working for you.

Vince:

Absolutely.

Tim:

Coming from an engineering background into now running your own company, are there any lessons that really hit you guys the hardest when you were just getting started in this new phase of your lives?

Michael:

The biggest thing for me was I always wanted to build product, and I think we found ourselves in a situation where we have a great product, but it’s so much more involved around community than I ever thought. So it’s very much now we’re learning how do we get the community more involved, and how do we make the people who that are building on the platform … I heard this great quote. I don’t want to curse, but it’s this book called Badass. They pitch it as, You don’t want to make a great product. You want to make a great user. I love that idea. The product’s only as valuable as the user is able to make it, and that’s something that it took us a little while to figure out.

Vince:

Yeah. I’m going to agree with Michael on that one. It’s one of those things where we’re both product-driven people, and we want to make the best product, so we spend a lot of time doing that, but then don’t end up telling people about the new features that we have. So what ends up happening is we have all these features that no one knows about, and at the end of the day, it’s just going to be stowed away in a closet. That’s what we’re trying to focus more on now — to try to build this community, tell people about what we’re doing, be more transparent and be more user-driven about our features.

David:

It’s a challenge, because sometimes it feels like you’re putting the cart before the horse trying to get people involved in something that you don’t feel, as the founders, that it’s ready to show.

Vince:

Exactly.

David:

How do you get past that? How do you get those first enthusiastic users to see the vision behind something that is still definitely in its lean, early stages?

Michael:

I think it goes back to the zeitgeist you were talking about. I think our early adopters were people that were very inteRESTed in GraphQL, and something that we had going for us early on is that it was timely. I think we caught this technology in its nascency, and it was something that we were in a cool position that we could help develop it. The people that came to us would be like, Yeah. I wanted to build something with GraphQL, and then I googled GraphQL and I found you guys.

It’s stuff like that. The technology was driving the early adopters. Now we’re trying to show the world that GraphQL is the better way of building these things, and then we’re pitching our new narrative around rapid product development, rapid application development. You can get things going so much faster. You can build four apps at the same time, and A/B test totally different ideas just because you have a platform like this.

David:

Can you encapsulate for our listeners what is the advantage of GraphQL over REST? What makes it REST 2.0?

Michael [15:48]:

Sure. The thing that does it for me is it has a type system. Too many times have I been trying to consume a REST API, and the only way to understand how to use a REST API is twofold. Either you go read pages and pages of documentation, which then the company that puts out the REST API has to maintain a lot of documentation, and that’s really the only way to figure out, Okay. What is /tracks on soundcloud.com accepting? When I make a POST request, what does it want, and what’s it going to give back? You have no idea unless you go read documentation.

The other way is to use an SDK. These REST APIs are so difficult to use that people have to actually provide software to let people use them. So GraphQL changes the game, and it provides this type system, and that’s huge for developers because it allows you to actually introspect the schema, which means that at any given time I can see exactly what’s going in and exactly what’s coming out with full clarity. I can completely understand the API just by looking at simple tools.

Vince:

Yeah. I want to expand on the SDK thing a little more. GraphQL queries are all made with strings, so you can make it from any sort of client-side networking library, whether it be cURL or jQuery or anything. Whether it be mobile web or IoT. That’s really cool, because we actually just launched this new VR tutorial so you can build VR apps and AR apps on Scaphold as well. The idea is we don’t have to provide any proprietary SDKs because everything is made with a normal POST request with a string appended to the content body of the payload. Yeah.

Michael:

I could talk about this all day. There’s more benefits. The type system’s huge. There’s also cool things with traversing relationships. This can get kind of in the weeds, but essentially if you’re thinking in REST, if you want to get a user’s profile, then you’re going to grab the user and then you’re going to get a list of IDs and then you’re going to go make ten requests to get all the posts of that user. Then you’re going to get those IDs that are related to the comments, and then you’re going to go get the comments.

GraphQL gives us really easy language to basically say in one request, I want my user and my posts and my comments. Also, I’m going to give these filters and these pagination arguments. And then the language aspect makes it concise and also standard. Instead of Google having a different REST API than Facebook, having a different REST API than Twitter, when you use GraphQL, it’s all GraphQL. You can structure the schema however you want, but you’re still writing the same language to interact with the data. It’s almost the SQL for the web. It’s like the standard way of interacting with these complex data structures, but you can also connect it anywhere. It’s more freeform than something like SQL, because you can put SQL behind it, you can put a Elasticsearch behind it, you can put Mongo DB behind it. You can really put anything you want.

Tim:

Have you heard from people using your product who have really started to get involved and love it as well?

Michael:

Yeah. We’ve spent a lot of time talking to our customers. We have a pretty large European publisher moving onto the platform, and they’re using it for a lot of serving. They essentially run lifestyle magazines and stuff like that, and they were one of the people that came out and were like, I really want to use GraphQL, and then they found us. We provide these tools that you instantly spin up these GraphQL systems. They love it from that. It’s 0 to production API in 15 minutes instead of 3 months.

David:

I noticed that you also have a lot of tie-ins to other companies that expose their APIs. Are these specific GraphQL APIs that they’re exposing?

Vince:

No, they’re not actually. The cool part is not only can you hook up a database or a different REST endpoint, you can hook up a variety of these and mix and match them. Right now we hook up my SQL database along with these integrations that you just mentioned, and those are all traditional REST endpoints. Whether it be Stripe, one of our most popular ones, or Auth 0 for authentication, we made wrappers around their REST endpoints and given you an exact mirror of that in a GraphQL translation, in a GraphQL translated way.

Instead of having to interact with all these different services that you normally would to build an app nowadays, you just have to interact with one API through GraphQL with one language and get data from 18 different places without even knowing about it.

Michael:

Right. A good analogy would be the Babel fish from Hitchhiker’s Guide to the Galaxy. We speak GraphQL to our customers, and we can go behind the scenes and talk 50 different languages. The customers only speak GraphQL. They get this universal translator of sorts to the data across the web.

David [20:00]:

As a developer, what do I have to put in my ear?

Michael:

We’ve got these VR apps coming out. Hopefully one of those.

[Laughter]

David:

Very cool. One of the things that really interests me is that this is built on technologies that have been open-sourced, and I’m curious about your interaction with the open source community.

Michael:

Yeah. It’s something that we’re getting more and more into. A lot of our open source thus far has been learning content. We just actually rolled out a community page today that we’re really encouraging people to contribute to, just trying to grow this knowledge of a hub for GraphQL, practical GraphQL knowledge. We’re also getting more involved with the Apollo project. We’re trying to make some contributions there, because we love … Apollo is a GraphQL project coming out of the guys that made Meteor JS. They’re doing some really awesome stuff, building a lot of cool developer tools, and that’s one project in particular that we’d love to start contributing to more.

Vince:

Yeah. So far, I guess most of our content is boilerplate tutorial, so we go a step further than just the back-end API that we expose to you. We help you by getting started with whatever framework you want — whether it be React with Apollo, React with Relay, Angular 2 with Apollo, all different flavors and combinations of frameworks, so that you only have to go in, git clone it, change one line in the config file to point to your GraphQL API, and everything works. It’s pretty magical in that aspect, and we want to continue to do more of that and get the community more involved as well, which is the inspiration for this community page is to collect and create an aggregation of all of these different things that people are building on top of our platform, so that other people can benefit from it.

Tim:

For any of our listeners who are interested, where can people connect with you guys, learn more about your startup and learn more about GraphQL?

Michael:

Sure. If you go to Scaphold … and I’ll just explain the idea behind that really quick, because people are always curious. The idea when we first started the company was we’re the foundation upon which everyone builds, so the immediate thing that we thought of was scaffolding. We have these beautiful buildings in New York and Seattle and San Francisco, but they don’t just grow out of nothing. They have this scaffolding, this messy scaffolding that goes up around them, and then slowly this beautiful building comes out of it. That was a cool analogy that we really liked, and we attached to early on. The PH comes from GraphQL. So it’s scaphold.io/community would be the best place to start learning about this stuff. You can also join our Slack. If you go to that website, there’s a link directly to join our Slack. There’s a bunch of people on there talking about GraphQL things, talking about Scaphold things, all over the place — just general web development stuff from React to Angular to React Native, and now even more iOS and Android as that tool set gets more developed.

David:

Very cool. Well, I’m looking forward to digging in and finding out a little bit more about this, and I believe you have a free tier as well, right?

Michael:

We do.

Vince:

Yeah. We have a pretty large free tier that extends your database storage, a good amount of traffic. The idea is we wanted to give you a fat-free tier to help you with your development phase. We don’t want you to feel the restriction of having to pay for anything when you’re just starting your app, and then once you launch, the idea is you’ll probably be consuming enough data, saving enough data on our servers or files such that you’re only paying $25 a month at the end of the day. It’s a flat fee. Most startups don’t know how much data they want to use, so we just bucket it in that way, and I think it helps clear the confusion a lot for a lot of these younger startups because they can project, I’m only going to pay $25 for my infrastructure, which is amazing, which not a lot of people can say.

Our third tier is the business tier, which scales up infinitely, and that’s more for the larger enterprise customers who have a lot of data, who can predict how much traffic they’re getting and, at scale, they get a much better value.

Michael:

Right. We have some cool features coming down the pipeline that may bump up some more premium services, but we’ll see.

David:

Of course.

Vince:

Stay tuned.

David:

Again, thank you so much for joining us on the show. It’s been really interesting talking with you, and good luck with the startup.

Vince:

Thanks a lot.

Michael:

Yeah. Thanks so much for having us. This was really fun.

[Musical interlude]

Tim [24:02]:

I always get a brief moment of terror when I hear about people quitting their jobs and just going for it, especially at such a young age. I can’t talk. I’m around the same age as them, but still it’s hard to imagine. I mean, you really have to believe in your product or your service to be able to go and do something like that.

David:

I think it’s a personality thing, too. There are just some people who are more inclined to going off and trying something experimental and exciting, as opposed to people who are looking for something more stable and where somebody else is taking on a lot of the market risk and just paying you a paycheck on a regular basis.

Tim:

Yeah. I mean, there is definitely a risk factor in that. I think there are also some of us who just haven’t had an idea yet. Yeah, it’s interesting, and it really takes a lot of discipline, which you wouldn’t think. It takes a lot of discipline to be able to do that, because once you make the commitment and, Okay, I’m going to quit my job no matter what you say, Dad. I’m going to go and do it, you really have to make sure that you have your stuff together, that you have a plan, that you commit to it, that you’re now waking up every day on time and being your own boss. That’s not an easy thing to do.

David:

No, tell me about it. I’ve been working independently now for at least two years, but before that I was a full-time employee at several different companies. My dad is still crazy about the fact that I did that. Why aren’t you going out and getting a salary and working at a job, and I keep telling him, Dad, the world doesn’t really work that way anymore. This is the gig economy. This is the way things are, and you’re much more stable and much more secure if you’re out there selling yourself to multiple employers. If one person ends up no longer needing your services, there’s another person out there or five other people or 20 other people who are out there getting your services and you have a more stable income and also a closer connexion to the market so that you know that what you’re providing is actually what the market needs.

Tim:

That helps a lot in our industry as well, because there are, I think, Dave Rupert on the Shop Talk Show likes to refer to them as “dark matter developers” — people who have been at it a long time and are really talented but there’s just no traces of them. Those people are fine. They always will be fine, but I’ve always preferred branding myself across the web, because it helps mainly just to come across more opportunities. For example, SitePoint: that definitely wouldn’t have happened had I not been interested and had my finger on the pulse of the community and responding to things and replying to stuff on Twitter. A portfolio site always helps. But those opportunities do, I believe, tend to present themselves more when you are making an effort to brand yourself in this industry.

David:

It’s not only about them presenting themselves. It’s about you saying yes, because these opportunities can present themselves in very subtle and ingenious ways that you don’t even notice. If you’re not out there actively saying yes to opportunities, you miss them. One of the things that impressed me about talking with Michael and Vince is the fact that they noticed that there was this interest in GraphQL, which meant that they had their finger on the pulse. They were listening to what people were talking about, and they realized there’s a piece missing there. I know how to build APIs, and I know GraphQL. It’s complicated for people to put together these back-end services that are required in order to support something like that. I can build something that can help people. I can build something that there are people out there looking for, that they need. They figured out a way to do it, and they put it together in such a way that they were able to go through Y Combinator which is an amazing accomplishment and get it presented to people. Now they’re living in a house. It sounds almost like some sort of reality show, but it is reality for them.

Tim [27:36]:

Yeah. It sounds like from what they’ve described that it’s working very well. They have clients that are interested, and you really can’t say that it’s not something that’s appealing. As a front-end developer myself, I don’t want to spend time building an API. That’s not something that … I mean, sure. I’d learn. I’d be interested. I might even like it, but if I have an idea for a product or service, I just want to get it going. Those are the services that are not only making it easier but are also starting to make a lot of sense. I mean, back end as a service is something that is really going to help startups of all sizes. You can be a very large organization, but if your priority is less on back-end development or more on front-end development, or you’re not really dealing with a lot of data but you’re still a large organization, that really comes in handy, and that can be a pivotal service for your product.

David:

I was thinking about that, too, because I also come from a front-end engineering background. I’ve worked with some of those back-end engineers, and it’s amazing the things that you need to consider when you’re putting together a stable, secure, reliable, efficient, effective back-end for your service. There’s so much to keep track of, so much to stay on top of, so much that changes so quickly in that field as well where people … you never know when a DDOS is going to come in, and what the source is going to be, and what the new security patches are going to do to what you’re trying to build and make stable. This idea of having back end as a service available for free from companies like this and from Firebase and from other places, the fact that that’s out there just opens up a world of possibilities to people with a little bit of front-end knowledge.

Tim:

Yeah. We should probably spend some time focusing on some of those resources that are available, because we don’t talk about it a lot. Often, in my career, I hear about people saying, I just deployed this thing on Firebase, or, I just pushed it up to AWS, but there’s not a lot of, Hey, this is exactly how you go about doing that thing. Here are all of the resources available if you want to get an API for testing up and running, or if you want some quick storage or if you really just want to put some static thing up for free. You can do that. Those aren’t necessarily the cool things anymore, and I feel like they’re not always focused about as much, but there are some crazy good resources out there that can, if you don’t know, do most of the work for you, and I think like we should maybe spend some time going over that.

David:

Oh, absolutely. I see no reason why we shouldn’t, and it’s important for people to realize that it doesn’t have to live completely on your shoulders. This idea that you have to be a unicorn, essentially, and be able to create everything from top to bottom in order to put out a service and know that it’s yours, that’s no longer the case. With so many different services out there, it’s possible to build on top of something else, and people don’t know enough about how those things are changing out there. GraphQL, REST, all of these different ways of thinking about an API, the pre-REST APIs, the notion that we should think about structured data as part of what we’re doing, whether the structured data is enforced by a database or enforced in the API or somehow lives in a graph in the app itself. All of these things are things that people need to take into consideration when they’re building something for the front end.

We have frameworks like React. You can do so much on top of that. I’d be interested in finding out from our listeners if there are technologies that they think are the cutting edge, the things that are happening next that they’d really like to hear more about — and also, how they’re taking advantage of older technologies, and why they’re sticking with them.

Tim:

Yeah. As we know, it’s 2017. React isn’t cool anymore. There’s something else, and we have to know what it is. That’s our job. So, dear listeners, please tell us, because we don’t know. We don’t know what the next thing … I don’t know. What is it?

David:

We have to be cool. That’s the imperative.

Tim:

We’re both wearing sunglasses right now. That’s what’s happening. That’s how hard we’re trying at this.

David:

I think that’s an effect of the gig economy, too, because if you don’t look cool, they’re not going to hire you.

Tim:

Yeah. You’ve got to wear flannel shirts and distressed boots or something. I’m not that cool, guys. I don’t really know, but I tried.

David:

I have such a collection of hoodies.

Tim [31:44]:

Yeah. Exactly. But, that being said, GraphQL is really interesting and really exciting, especially if you have gone through the process of talking with a back end developer to get an API built and then grabbing that API and then formatting more data on that API. I’m sure you have, David. I’ve gone through this a number of times, wherein I need to get some user data, and for me it was eCommerce. What does this user have in their cart? I get a list of IDs. I need to go make more requests to find out what those IDs map to, then it’s not filtered the right way and I have to go and do that. It’s more work for everybody, because it’s really every time I need a new API, I just go to one of the back-end developers available and say, Hey, give me this now, and it’s slightly different from that but not really, but still I need a new one.

Lots of money gets wasted, because that’s what it really ends up to be. It’s just a lot of wasted hours on building similar things, formatting those things and you get this spaghetti mess, but now it’s on your back end.

David:

What little I know about GraphQL indicates that it’s going to be solving some of those problems with the ability to use types, with the ability to define interfaces that those types can implement. I think it’s going to make it possible to create variations and multiple versions of things inside of a data access layer that really will make sense and really will be more versatile, and maybe solve some of those problems and make some of that communication more visible. Because one of the things I’ve always noticed when I’ve been in those conversations is the issues around documentation, which Michael and Vince did bring up.

It’s important and it’s critical to document your REST API very specifically, and have all of these endpoints and exactly what everything means and what all of these different possible variations could mean. And, apparently, with GraphQL a lot of that documentation gets carried within the structure of the schema itself.

Tim:

Just like Michael was saying, when you are the SoundCloud API — which I have worked on before on podcasts trying to get right — and you really do run into those problems of, Okay, what does this thing accept? Is this parameter correct? Why am I not getting this thing? Oh, here’s a random person’s profile. It really gets you thinking, and it’s not necessarily SoundCloud’s fault. It’s a really large product. It’s a giant API. There are tons of ways to interact with it. If you rely on a human to get that documentation right every time, it’s never going to work.

David:

No. I will definitely confess I’m thinking through some of the REST APIs that I have had a hand in helping to design and occasionally build, and I’m thinking about all of the silly, stupid detailed things that are difficult to figure out and you would never … they’re completely unintuitive unless you understand exactly what the thing is trying to do in the first place. It sounds to me like bringing these things to the surface, and getting people thinking about them more, is going to be more critical, especially going forward. As front-end engineers ourselves, and working with designers and with back-end engineers, these conversations … it just helps bring these things to the surface, and I’m looking forward to this.

Tim:

That’s why my motto as a front-end developer is make the server do the work, because I don’t have to anymore. It’s not just lazy. It helps. Its helps everybody — because, again, some of the things that GraphQL helps with, you can rewrite the API on the back end and not have to change a single thing on the front end.

David:

A good engineer is a lazy engineer — and yes, you may quote me on that.

Tim:

It’s true. Our job is to write the least amount of code, not the most.


David:

Well, thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

Tim:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

David:

We’ll see you next time, and we hope you enjoyed this version.

We teamed up with SiteGround
To bring you up to 65% off web hosting, plus free access to the entire SitePoint Premium library (worth $99). Get SiteGround + SitePoint Premium Now