DEV Community: Vikram Rangnekar

Build High Performance GraphQL APIs in 5 minutes with GraphJin

Vikram Rangnekar — Thu, 04 Feb 2021 16:31:15 +0000

What if I told you there was an open source GraphQL backend that automatically learned the structure of your database and allowed you to instantly start querying it with GraphQL. No code or no configs it just works out of the box.

While this sounds unreal - it exists. GraphJin is an instant GraphQL to SQL compiler that converts your GraphQL query into an efficient and fast SQL query. GraphJin is written in Go and can be used as a standalone service or a library within your own app. It works with Postgres, Mysql and the Distributed Yugabyte and CockroackDB databases.

Install GraphJin

go get github.com/dosco/graphjin

You need Go installed on your system. The above command will download, compile and install GraphJin into your GOPATH which is usually ~/go/bin and should be added to your path.

Create a GraphJin App

graphjin new blog

INF created 'blog'
INF created 'blog/Dockerfile'
INF created 'blog/docker-compose.yml'
INF created 'blog/cloudbuild.yaml'
INF created 'blog/config'
INF created 'blog/config/dev.yml'
INF created 'blog/config/prod.yml'
INF created 'blog/config/seed.js'
INF created 'blog/config/migrations'
INF created 'blog/config/migrations/0_init.sql'
INF app 'blog' initialized

The newly created app will be in the blog folder and will contain a docker environment, config files and database migration files.

Setup Your Database

docker-compose run api db:setup

We use Docker Compose which is a nice way to run your entire backend in Docker and not have to clutter your machine. This above command will use docker-compose to start a Postgres database and GraphJin using the config/dev.yml config file.

It will then run the db:setup GraphJin command which will create the blog_development database and create the tables defined in the config/migrations/0_init.sql database migration script. It will then run seed.js the seeding script to add fake data to your database to help you with development.

Start Your App

docker-compose up

The up command will also run the database but this time it will run Graphjin with the serv command which will start your GraphQL API backend.

Try some GraphQL

query {
  users {
    id
    email
  }
}

Open a browser and visit http://localhost:8080. You'll be presented with the GraphJin web ui. You can craft and test your GraphQL queries here.

Some more details

Security

In development mode all named queries query getUser { user { id } } (queries with a name eg: getUser) are saved into an allow list file and in production mode only those queries are allowed to run. This makes GraphJin very fast and secure since no one can send different queries to your API and expect to get any data that you don't want to expose. Also in production mode queries are compiled to database prepared statements which makes then extremely fast.

Frontend development

GraphJin works fine with all GraphQL client libraries like Apollo and URQL. Just use named queries when building your app they are automatically saved (or updated) as your app evolves. So when deployed into production your allow list is packaged along.

Who uses GraphJin

GraphJin is fully open source Apache Licensed project. It has an active and growing community, great documentation and a clean codebase with great test coverage using integration tests.

GraphJin is being used by many startups saving them months of development time. For example the popular 42papers.com platform to discover top trending CS/ML and AI papers uses the standalone GraphJin service.

Save you time and money

Developing REST APIs to create, update, delete and fetch data from your database is a tedious job also as your UI evolves those APIs have to be maintained and updated. This all takes weeks to months of relatively boring work and can be a vector to introduce security holes in your app.

With GraphJin all this work goes away instantly. The SQL queries GraphJin generates are lighting fast and your web developers now has to power to create the query he needs while building the UI. It frees you up to focus on the interesting parts of your app. Also GraphJin starts up in milliseconds so it works great on severless scale to zero platforms like Google App Engine, Google CloudRun, AWS Fargate, Azure Container Service. It's tiny, fast and feature packed give it a try and I'm happy to help so feel free to reach out on th comments or my twitter @dosco

REST vs GraphQL - Building Startups in 2021

Vikram Rangnekar — Tue, 26 Jan 2021 15:04:16 +0000

I was an engineer at Linkedin from 2010 and had a chance to see and help its tech stack evolve to match the growing engineering challenges of a fast growing web product. I also spent several years building my own startup Socialwok which was a Techrunch50 winner. I'm currently building an automagical GraphQL to SQL compiler called GraphJin and a popular community 42papers.com around top trending research papers in CS/ML/AI. Over the years I've built many products with various languages and frameworks but until now mostly with REST APIs.

I have a love-hate relationship with REST APIs. Having spent years consuming APIs from building startups to helping move Linkedin to EmberJS and with various apps in React and Vue. And as a producer of APIs external and internal APIs as part of Linkedin's Ads Engineering and other teams. The key takeaway I have from all this experience is if a technology is slowing you down then it's the wrong choice.

REST

In the REST world building an API first required you to name it and think up the URL structure. I found that even these simple things are really hard since neither quite fit. Should it be /users/3/products, /products?user_ids=3,4,5 or something entirely different /products_page?q=user:3. Does it make sense to use PUT, POST or PATCH, etc. While REST and GraphQL are both just de-facto standards with REST even the basics are over the place.

Most of REST world focuses on building resource specific APIs while in the real world your needs are more view or action specific. This is also why backend rendering like in Rails makes so much sense as opposed to firing tens of API calls.

Let me tell you a story that you'll find familiar. Say you're working at your job and the product team decides that a profile image and a full-name should be added to each comment on the page. The current API only returns the first name so the PM adds a ticket on the backend team. The backend developer now has to change the SQL and the JSON structure to return these new fields this takes a day or more blocking the React, Android and IOS developer. And with smaller teams it turns into a massive context-switch into the backend stack to make this change. In short it's not great we wasting time, money and productivity. And This happens over and over again.

So what's good about REST? Well its popular cause it was simple to start with and it native to browsers. All the good-ness of ETags, Cache-Control, etc comes out of the box. you can use GET, POST, DELETE. All you need is an HTTP client.

What seems simple to start with has an added cost that you pay as long as you continue to use it. I've even sat in meetings to decide the url path of an API. I can bet like me you'd like that hour of your life back. REST APIs are too limiting and too restrictive for the fast and data rich applications of today.

But REST is not all bad there are several use-cases where REST continues to be the best choice. For OAuth based auth flows, file upload or download endpoints, sharable links and web hooks to name a few.

GraphQL

Life has shown me that the best products are built by teams that value the developers experience as much as the customers experience. Technology that allows your team the freedom to move fast will provide you the highest return on investment. This is exactly why Github, Shopify, Twitch, etc were all built on Rails. A complex stack that came with all common requirements included and minimizes context switching. It allowed the developer to do focused work faster.

Yes, the infrastructure required to use GraphQL is more than REST but it gives more back by helping developers to do more focused work faster.

Frontends today, mobile or web are increasingly complex and designed to provide rich experiences to your customers. It's a highly specialized skill. A React developer has to juggle the state management, user-experience, javascript tooling and the same with Android or IOS developers. The last thing you want is for him to be blocked or have to also fix APIs.

GraphQL gives power back to the person building the customer facing apps. He can query for the data he needs when he needs it. He does not have to remember complex REST APIs semantics and or if to use a POST, PUT, GET or whatever. He just writes out his query in GraphQL and the data just shows up. It's simple.

Almost 90% of all apps require fetching complex related data to render page views. GraphQL allows your frontend devs to fetch all the data they need in a single query without waiting on anyone else. This results in faster apps for your customers and to iterate on for your devs.

GraphQL has many more useful capabilities for example subscriptions. Once your initial view is rendered you can then subscribe to the same view query to get instant updates over web-sockets. This is much more efficient and nicer than the long polling that you'd have to do with REST.

People often bring up caching as a weak point of GraphQL. And I'll agree somewhat since it's not easy to leverage browser caching with POSTGraphQL endpoints. However GraphQL client libraries like Apollo and URQL have come far and have quite sophisticated caching capabilities that even go further than what browser provide REST APIs. Additionally GraphQL now has features like automatic persisted queries or APQ that allow you to use GraphQL over REST APIs leveraging that browser caching you wanted.

In short GraphQL is a querying language that when done right can help your team build data rich modern app experiences quicker leaving you more room to iterate towards a product your customers love.

Conclusion

You'll probably need both. REST APIs will continue to play their part in your stack and GraphQL will take on the job of the primary driver for fetching and changing the data that your app deals with.

Getting started with GraphQL is very easy there are several open source options out there all of which are pretty solid. While I'm a little biased I'll recommend checking out GraphJin a GraphQL backend in GO that will save you countless hours. Just point GraphJin at your Postgres or MySQL database and start writing your GraphQL queries, it will automagically convert them into an efficient SQL query and fetch the data needed from your database. It also learns the schema and relationships in your database on its own so no config or code required.

I'd love to hear what your thoughts are on this debate. Would you pick GraphQL and if not then why? And if you are using GraphQL currently then what is your stack made up of?

You can find me at twitter.com/dosco.