Improve the motivation section in the readme
This commit is contained in:
parent
acadef1816
commit
6b164aed08
10
README.md
10
README.md
|
@ -8,15 +8,11 @@ Get an high-performance GraphQL API for your Rails app in seconds. Super Graph w
|
|||
|
||||
## Why I built Super Graph?
|
||||
|
||||
I have a Rails app that gets a bit of traffic. While planning to improve the UI using React or Vue I found that my current APIs didn't have what we needed. I'd have to add more controllers and ensure they are providing the right amount of data. This required designing new APIs and making sure they match what the webdevs need. While this is all to common work I was bored and there had to be a better way.
|
||||
Honestly, cause it was more fun than my real work. After working on several product though my career I found myself hating building CRUD APIs (Create, Update, Delete, List, Show). It was always the same thing figure out what the UI needs then build an endpoint for it, if related data is needed than join with another table. I didn't want to write that code anymore I wanted the computer to just do it.
|
||||
|
||||
All my Rails controllers were esentially wrappers around database queries and its not exactly fun writing more of them.
|
||||
I always liked GraphQL it sounded friendly, but it still required me to write all the same database query code. Sure the API was nicer but it took a lot of work sometime even more than a simple REST API would have. I wanted a GraphQL server that just worked the second you deployed it without having to write a line of code.
|
||||
|
||||
I always liked GraphQL it made everything so simple. Web devs can use GraphQL to fetch exactly the data they need. There is one small issue however you still hasve to write a lot of the same database code.
|
||||
|
||||
I wanted a GraphQL server that just worked the second you deployed it without having to write a line of code.
|
||||
|
||||
And so after a lot of coffee and some avocado toasts Super Graph was born. An instant GraphQL API service that's high performance and easy to deploy. I hope you find it as useful as I do and there's a lot more coming so hit that :star: to stay in the loop.
|
||||
And so after a lot of coffee and some Avocado toasts __Super Graph was born, a GraphQL server that just works, is high performance and easy to deploy__. I hope you find it as useful as I do and there's a lot more coming so hit that :star: to stay in the loop.
|
||||
|
||||
## Features
|
||||
- Works with Rails database schemas
|
||||
|
|
|
@ -62,15 +62,11 @@ query {
|
|||
|
||||
## Why I built Super Graph?
|
||||
|
||||
I have a Rails app that gets a bit of traffic. While planning to improve the UI using React or Vue I found that my current APIs didn't have what we needed. I'd have to add more controllers and ensure they are providing the right amount of data. This required designing new APIs and making sure they match what the webdevs need. While this is all to common work I was bored and there had to be a better way.
|
||||
Honestly, cause it was more fun than my real work. After working on several product though my career I found myself hating building CRUD APIs (Create, Update, Delete, List, Show). It was always the same thing figure out what the UI needs then build an endpoint for it, if related data is needed than join with another table. I didn't want to write that code anymore I wanted the computer to just do it.
|
||||
|
||||
All my Rails controllers were esentially wrappers around database queries and its not exactly fun writing more of them.
|
||||
I always liked GraphQL it sounded friendly, but it still required me to write all the same database query code. Sure the API was nicer but it took a lot of work sometime even more than a simple REST API would have. I wanted a GraphQL server that just worked the second you deployed it without having to write a line of code.
|
||||
|
||||
I always liked GraphQL it made everything so simple. Web devs can use GraphQL to fetch exactly the data they need. There is one small issue however you still hasve to write a lot of the same database code.
|
||||
|
||||
I wanted a GraphQL server that just worked the second you deployed it without having to write a line of code.
|
||||
|
||||
And so after a lot of coffee and some avocado toasts Super Graph was born. An instant GraphQL API service that's high performance and easy to deploy. I hope you find it as useful as I do and there's a lot more coming so hit that :star: to stay in the loop.
|
||||
And so after a lot of coffee and some Avocado toasts __Super Graph was born, a GraphQL server that just works, is high performance and easy to deploy__. I hope you find it as useful as I do and there's a lot more coming so hit that :star: to stay in the loop.
|
||||
|
||||
## Say hello
|
||||
|
||||
|
|
|
@ -8,12 +8,12 @@ Since you're reading this you're probably considering deploying Super Graph. You
|
|||
|
||||
### Alongside an existing Rails app
|
||||
|
||||
Super Graph can read Rails session cookies. Like those created by authentication gems (Devise or Warden). Based on how you've configured your Rails app the cookie can be signed, encrypted, both, include the user ID or just have the ID of the session. If you have choosen to use Redis or Memcache as your session store then Super Graph can read the session cookie and then lookup the user in the session store. In short it works really well with any kind of Rails app setup.
|
||||
Super Graph can read Rails session cookies, like those created by authentication gems (Devise or Warden). Based on how you've configured your Rails app the cookie can be signed, encrypted, both, include the user ID or just have the ID of the session. If you have choosen to use Redis or Memcache as your session store then Super Graph can read the session cookie and then lookup the user in the session store. In short it works really well with almost all Rails apps.
|
||||
|
||||
For any of this to work Super Graph must be deployed in a way that make the browser sent your apps cookie to it along with the GraphQL query. This means Super Graph should be on the same domain as your app or a subdomain.
|
||||
For any of this to work Super Graph must be deployed in a way that make the browser send the apps cookie to it along with the GraphQL query. That means Super Graph needs to be either on the same domain as your app or on a subdomain.
|
||||
|
||||
::: tip I need an example
|
||||
Say your Rails app runs on `myrailsapp.com` then Super Graph should be on the same domain or on a subdomain like `graphql.myrailsapp.com`. If you choose subdomain read below.
|
||||
Say your Rails app runs on `myrailsapp.com` then Super Graph should be on the same domain or on a subdomain like `graphql.myrailsapp.com`. If you choose subdomain then remeber read the [Deploy under a subdomain](#deploy-under-a-subdomain) section.
|
||||
:::
|
||||
|
||||
### Custom Docker Image
|
||||
|
@ -34,6 +34,10 @@ For this to work you have to ensure that the option `:domain => :all` is added t
|
|||
|
||||
If you're infrastructure is fronted by NGINX then it should be configured so that all requests to your GraphQL API path are proxyed to Super Graph. In the example NGINX config below all requests to the path `/api/v1/graphql` are routed to wherever you have Super Graph installed within your architecture. This example is derived from the config file example at [/microservices-nginx-gateway/nginx.conf](https://github.com/launchany/microservices-nginx-gateway/blob/master/nginx.conf)
|
||||
|
||||
::: tip NGINX with sub-domain
|
||||
Yes, NGINX is very flexible and you can configure it to keep Super Graph a subdomain instead of on the same top level domain. I'm sure a little Googleing will get you some great example configs for that.
|
||||
:::
|
||||
|
||||
```nginx
|
||||
# Configuration for the server
|
||||
server {
|
||||
|
|
|
@ -0,0 +1,36 @@
|
|||
Super Graph
|
||||
Get an instant GraphQL API for your Rails apps
|
||||
18 Apr 2019
|
||||
Tags: GraphQL, API, GoLang, Postgres
|
||||
|
||||
Vikram Rangnekar
|
||||
https://supergraph.dev
|
||||
@dosco
|
||||
|
||||
|
||||
* Motivation
|
||||
|
||||
Honestly, cause it was more fun than my real work. After working on several product though my career I found myself hating building CRUD APIs (Create, Update, Delete, List, Show). It was always the same thing figure out what the UI needs then build an endpoint for it, if related data is needed than join with another table. I didn't want to write that code anymore I wanted the computer to just do it.
|
||||
|
||||
** Subsection
|
||||
|
||||
- bullets
|
||||
- more bullets
|
||||
- a bullet with
|
||||
|
||||
*** Sub-subsection
|
||||
|
||||
Some More text
|
||||
|
||||
Preformatted text
|
||||
is indented (however you like)
|
||||
|
||||
Further Text, including invocations like:
|
||||
|
||||
.image image.jpg
|
||||
.background image.jpg
|
||||
.iframe http://foo
|
||||
.link http://foo label
|
||||
.caption _Gopher_ by [[https://www.instagram.com/reneefrench/][Renée French]]
|
||||
|
||||
Again, more text
|
Loading…
Reference in New Issue