Dear readers, I am pleased to introduce you to Ville Immonen, a co-founder of Reindex. Today we will be discussing what Reindex is, the problems it solves, the company's operation, and upcoming news for 2016.
Ville, it is great that you spared your precious time for sharing information. Let's start with your background. How did you get interested in programming and what are the things that you're passionate about?
When I was at high school, I took a university's introductory programming course and was also fortunate enough to get paid to do some projects where I built websites with PHP, MySQL, HTML and CSS. After my first year at the university, I got a summer job as a software developer and I've been doing software development ever since.
I'm enthusiastic about programming because it lets me create new things from scratch. Specifically, I like frontend development because of how it's really focused on getting new products in front of people. You can build something and get it in the hands of people right away and get immediate feedback. And now I build tools for frontend developers to make it easier and faster to build new products.
Reindex is the name of your company and service. The tagline describes the service as "Instant GraphQL Backend for Your React Apps". Most readers are familiar with React, but GraphQL isn't as known. Can you describe what GraphQL is and how and why Reindex was born?
Reindex is a service for storing data in a way that makes it very easy to access from React and React Native apps without writing any complex plumbing. Reindex was born a bit above year ago, out from the need we saw in our client projects for it.
Before starting Reindex, we had a software development company and we were building products with React, which makes the view part of apps almost trivial. But the data layer had to be built from scratch every time. For every app, there was a new backend built with a database, server-side code and a REST API that had to be integrated with the client-side code. This involved writing a lot of plumbing code on the client, and all the server-side components had to be deployed and maintained.
Then we used services like Firebase, and they really sped up the development by eliminating a big chunk of the server-side work. But none of the existing services fit seamlessly with the client-side technologies—there was always some plumbing, Flux stores to write, and things like caching to handle manually.
In early 2015 Facebook started talking about this API technology named GraphQL that they were using internally to deliver data to their mobile apps. We saw this as a solution to the data syncing problems we had, and wanted to build a backend service using GraphQL as its API. Reindex was born.
GraphQL is a data query language invented at Facebook in 2012 to deliver data to their mobile apps. The biggest differences distinguishing it from traditional API styles like REST are hierarchical client-specified queries and the strongly typed and introspective schema.
The GraphQL queries are the way for clients to request the data they need. And whereas in a REST API you usually have a predefined set of endpoints that return certain resources, with GraphQL the client can fetch exactly the data it needs and no more. And because these queries are hierarchical and composable, you can fetch all the data you need for a single screen on the app at once, without patching it together from multiple requests to different endpoints.
On the server, GraphQL is powered by a schema. It defines all the fields that can be queried, their types, and how those queries are resolved. This schema can also be queried with GraphQL using introspection queries. This is very powerful because it makes some advanced tools using the schema possible. For example, you can have autocomplete and compile time validation for all the queries, live documentation of your API, code generation, and more.
There's also a client-side framework, Relay, which ties GraphQL up with React. You can simply write GraphQL queries in your React components, and Relay handles fetching the data, caching it, and updating it, without you having to write all that plumbing yourself.
GraphQL became an open specification in July 2015, and after that an open source community has formed around it and the different implementations.
In short, Reindex is a service that lets you use this amazing tech from Facebook without having to build a new API server from scratch and manage your own servers.
I think many of the readers who have done web apps, either on frontend, backend, or full-stack, can relate to the problem you very well described with REST APIs. It is really difficult to keep REST APIs focused and at the same time keep up with the changing UI requirements, performance, etc.
Reindex CTO, Mikhail Novikov, wrote an article (Building a GraphQL Server with Node.js and SQL) that is definitely worth reading. The blog post leads to a technical question: Can you tell us little bit on your architecture, especially how do you persist data?
Unlike the examples in that article, we're not actually using an SQL database because we already host hundreds of Reindex apps and each of them has their own schema, which we would have to duplicate in the database schema. So we're storing the data in MongoDB, which is schemaless, and the different schemas are managed on the application layer. We have a bunch of scalable MongoDB clusters, and each app occupies its own database in a cluster.
All our client-side libraries and examples are released with an open source license and available at github.com/reindexio.
It would interesting to know how you guys operate on a daily basis. Do you work in the office or remotely, and how do you communicate and/or keep track of things?
We've had a small office, but at the moment we're transitioning into doing more remote work. Working remotely makes a lot of sense in my opinion—our clients are all around the world, so why would we limit ourselves to a single location? This gives us a larger and more diverse group of people to hire from when it's time to grow the team. We're also doing some consulting work on the side (we haven't taken any external funding—the development of Reindex is financed from our own savings and consulting). So we're also spending some time at clients' offices and that also has made it less necessary to have our own office.
What are the things you are expecting from the year 2016? These can be from your company perspective or GraphQL/Relay.
I think this will be the year GraphQL becomes mainstream. Despite being in production use for years at Facebook, it's still relatively unknown in the developer community. But I can see this starting to change because of the huge popularity of React and the great community support Facebook is putting behind the open source platform around it.
In Relay there's work in progress to simplify the core and to provide low-level primitives for people to be able to innovate on the API on top of Relay. This will lead to Relay being easier to adopt for different kinds of projects, big and small, and it's not even limited to React projects. There are also plans to include support for things like real-time and on-device data in Relay.
We keep on making Reindex better and hope to see more and more developers use it in their projects. We also want to take a more active role in the open source communities of GraphQL, Relay, and React. That means continuing to contribute to these open source projects, improving the learning resources, and promoting this way to build apps. Together with this community, we can shape how apps are being built in the future!
Big thanks to Ville for spending time to make this interview happen!
Make sure you check the service and the resources: