Yes, we have increased our marketing reach by 16250%. How we made it?
Automation!

## Hello!

I’m Tomek and I’m responsible for marketing/sales in Aexol. Let me introduce you our company profile so you could understand better our business model and have a better understanding of below case study.

## We make mobile apps

We make mobile apps, what's more important, we make mobile apps that last. Creating mobile apps is easy. You can build a mobile app and have it published in one of the app stores in relatively a short time, then you just sit back and watch like money magically appears on your account. If you have ever tried marketing an app you know that the last part is far from reality, it takes a lot more for an app to become successful and the real challenges appear when you think that you have already broken the code and you dream about scaling up your project.

![top apps](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/top.webp)

## Scaling up

Let’s skip couple steps and move to a point where we already have:

* A decent mobile app
* Marketing research is done
* A monetization model that suits our product
* Our marketing campaigns are up and running

The next natural step is intensifying your activities in order to achieve better results. This usually means hiring additional people, preparing more working stations, buying additional software license or hiring an agency which will do it for us, anyhow scaling is strictly related with an increase of cost in general. You can also try to automate the process and that's what we did.

## The automation in our business model

Scaling up our mobile ads was a big challenge for us. We didn’t want to expand our marketing team, but also we were aspiring to be present in top charts across the App Store (we mostly sell paid apps). Creating multiple ad campaigns targeting different users basing on their languages, locations, interest or age is a very time-consuming task. After spending some time on thinking how could we solve this problem we came across the idea of building a very simple web app.

## Tool made with GraphQL Editor

We have created an in-house tool which we called Visual Ad Composer. The logic for this app was made with a beta version of GraphQL Editor and it was made in 8 hours by one developer, no design, simple graphics, pure technology. How does it work? It’s very simple. We define different targeting aspects (let’s use Facebook targeting as an example) we want to use in our ads, basic things like how much we want to spend and … that’s it!

Let’s say we want to try out combinations of:

* Gender (two values),
* Country (let’s say we want to create ads for 10 countries),
* Age (let’s take all age groups available on Facebook so 7).

![submit](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/submit.webp)

Our tool will create 140 campaigns covering every combination of the target groups we have picked above … with a single click! The simple automation of ad creating process saved use thousands of hours which will need to spend to create these multiple ads manually. This helped us increase our ads reach by 16250% and cost us only 10 times more than before which give us a nice quite a nice leverage level and help us made some money from our apps.

## Before

![April](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/april.webp)

## After

![August](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/august.webp)

## Final thoughts

No matter if you are a graphics designer, marketing manager, a developer or doing any other job, you should think about how simple programmes could help you save time you spend daily on performing mechanical tasks.

How we went from 0.8M to 130M impressions in 3 months


Have you ever heard of [typestyle](https://github.com/typestyle/typestyle)? No? It is a great no-webpack styling solutions. In my life I tried almost everything possible:

- pure CSS
- SCSS
- SASS
- CSS modules
- CSS Next
- inline react styles
- typestyle

Most of solutions are bundled with webpack which means if you want to write library which have extendable replacable styles included you mustn't use webpack! So automatically you need to disqualificate these solutions:

- CSS Next
- CSS modules
- SCSS
- SASS
- pure CSS

So lets take a closer look on these:

- inline react styles
- typestyle

Inline react styles are nice but producing spaghetti code

```ts
import * as React from 'react'
export const MyInlineComponent = ({ children, style }) => (
  <div
    style={{
      fontSize: 15,
      ...style,
    }}
  >
    {children}
  </div>
)
```

Moreover you cannot include media and hover directives. Using onmouseover is ugly though and you need state to control that.

Lets try with typestyle then

```ts
import * as React from 'react'
import { style, classes, media } from 'typestyle'

export const MyComponentStyle = style(
  {
    fontSize: 15,
    $nest: {
      '&:hover': {
        fontSize: 18,
      },
    },
  },
  media({ maxWidth: 480 }, { fontSize: 10 })
)

// Extending the style

const MyNewStyle = classes(
  MyComponentStyle,
  style({
    color: '#0ae',
  })
)

export const MyStyledComponent = ({ children, style = '' }) => (
  <div className={classes(MyNewStyle, style)}>{children}</div>
)
```

Looks great yeah? It is high time for advanced programmers style solution. Imagine a component which have more styles. I will write styles in separate file for this solution

styles.tsx

```ts
import { style } from 'typestyle'

export const Title = style({
  fontSize: 18,
})
export const SubTitle = style({
  fontSize: 18,
})
export const ImageSize = style({
  width: 20,
  height: 20,
})
```

component.tsx

```ts
import * as React from 'react'
import * as styles from './styles'

export const MyStyledComponent = ({
  overrideStyles = {},
}: {
  overrideStyles: typeof styles
}) => {
  const componentStyles = {
    ...styles,
    ...overrideStyles,
  }
  return (
    <div>
      <div className={componentStyles.Title}>Hello</div>
      <div className={componentStyles.SubTitle}>World</div>
      <img
        className={componentStyles.ImageSize}
        src="https://source.unsplash.com/random"
      />
    </div>
  )
}
```

usingComponent.tsx
```ts
import * as React from "react";
import { style } from "typestyle";
import { MyStyledComponent } from "./component";

const Page = () => (
  <div>
    <MyStyledComponent
      overrideStyles={{
        Title: style({
          color: "#00F"
        })
      }}
    />
  </div>
);

```

Voila you can use the component and override its styles with full intelisense!! Just by using typeof on the module.

Power of typeof & typestyle in react apps

## Summary

Hi, I’m Robert - entrepreneur based in Poland. Last seven years I’ve spent working in software development business. Last year I made a transition from the service business to saas. In this article I’ll cover short story, mostly focusing on last year and how we got our first traction. Check more articles and updates on “My saas story.”

## First business.

Just after graduating University in 2011 I’ve started marketing agency with my best friend (lemontea.pl). I wasn’t doing very good since we didn’t have any business experience and decent idea what we want to do. After two years the company made almost no profit, a friend decided to leave the company just for me, and I was there with three developers on the payroll with no proper plan. I’ve decided to focus and brand the team as javascript consulting experts. It took a year to do so but it worked, we were quickly able to win new customers and won prestigious awards for advanced & animated front end of one project. We were overselling and since I had no experience in it business and project management I’ve decided to sell the company.

## Selling the child.

I did it after 3,5 years from starting my company. It was straightforward because we had a good brand and few enterprise customers waiting to deliver orders. It gave me a massive advantage in negotiations with potential buyers showing them what type of customers I’m able to win. I’ve decided to go with [tenderhut](https://tenderhut.com/en) New owner offered me a decent proposition and a VP of sales position, so I’ve joined the team. It was a newly formed company (30 people), but the founders had many years of experience in the one prominent software development company in Central Europe. Their previous company (SMT Software) has sold for $40M USD. I’ve spent nearly two years there developing sales & marketing department from scratch to more than ten people on board. The company itself tripled the size concerning headcount and revenue. My new founders wanted to replicate the success of their past employer.

## Need to change.

But I wanted to change. I didn’t want to do just outsourcing. I felt I’d like to do some more than only selling skilled developers by days. I wanted to focus more on marketing because it was also something I was passionate about over the years. I’ve decided to change and leave the company and search for exciting ideas. I’ve started working as a freelancer for tech companies helping them develop sales departments. Also, I’ve started talking with my colleague - Artur from Aexol. I thought it could be good to do something together, cause he had considerable experience developing his products - mostly simple mobile apps. I knew that to grow a great product I need a product experienced co-founder.

## Saas ideas.

Before focusing on our final project, we started working on three other ideas. Those projects were cute, but their vision and market were local. We wanted a big hairy audacious goal! The third project was the thing - Artur showed me the idea of visual node designer called slothking I thought - funny name and a crazy idea, let’s do it! That time he had a beta version of the app and his developers were using it to speed up the development process. It was a proper MVP with internal users. It was a great idea to start. It was a side project, and I was sharing it with my part-time freelance consulting . That time we didn’t discuss shares or positions. We wanted to deliver excellent value, focus on pure work and stay lean on the money. That time I’ve watched a few YC videos on product market fit, and we started looking for traction

## Searching for market fit.

Working on my new startup gave me huge motivation and a lot of fun. In a few hours, we made the ugliest landing page that we could and started talking with customers. We got a little bit of response, but it wasn’t a thing described in YC videos. We didn’t get that feeling. So we made a better quality version of our landing page. It also didn’t work so well. That time I thought - we need great advisors. It’s my fourth business, and I don’t want to do it myself. I’ve checked my LinkedIn and tried to find someone who I know and might be a great fit. I was looking for someone who has success experience in dev products, saas or high growth companies. I got in touch with Tomasz Karwatka from Divante.co - a global e-commerce software company. He and his brother had launched open source vue store front which had nearly 3k stars on GitHub. That was the team that I was looking for. They agreed to help for small % of shares after hearing about our idea.

## Finding product market fit?

We decided to meet with guys from Divante online a few times and then set up a meeting in Wroclaw. It was hard to catch up with guys cause they are full time in travel. After our 3 hour meeting, we decided to make a pivot. Our original idea slothking was to create an entirely new core system and then prepare it for all programming languages. It was a downside of this idea where we had to customise our tool for every different language. At the meeting, we found that there’s new technology - a GraphQL query language that’s gaining popularity in opposite to REST API. We thought if we could make and GraphQL Visual Editor than add to that fake backend, database and cloud deployment we would achieve our initial idea of Visual Node / Backend Designer. The new plan was born. Next week we had a demo since we were able to re-use our javascript diagram tool. We made nicely looking GitHub repo and posted it on hacker news. That was the thing. We posted it on Saturday 22nd Sept and in one week we had 20k views (12k unique), and 2300 GitHub starts. Till that day we didn’t spend any money.


My saas story - from IT outsourcing to saas


With the theoretical introduction from the previous post on GraphQL, we can go on to describe an essential part of this standard, namely the type system, which allows you to define the API scheme - GraphQL Schema Definition Language (SDL). It is a special syntax that has been very well documented and created in such a way that you can work with it regardless of the language or framework.

## Type System

GraphQL is strongly typed, which means that each definition must have a particular type. The Type System comes with the help, which provides several possibilities for defining elements of our API. Let’s think about library application (books and authors) declare the first types of our API.
```gql
type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```

   
The most important and most often used element of the whole puzzle is `Object Type`, which in the simplest terms is a collection of fields. Above examples: two objects were declared using the `type Book {}` and `type Author {}` definitions, while inside these declarations you can see fields that are of certain types, e.g. `name: String!`, or  `isBookOftheYear: Boolean!`.

## Scalar types

In GraphQL there are several built-in scalar types for field declarations:

- `String` - set of characters in UTF-8 format,
- `Int` - 32-bit integer,
- `Float` - floating point number,
- `Boolean` - value `true` or `false`
- `ID` - a type representing the unique identifier for the object, most often used for re-downloading (used by the cache). It's serialised in the same way as the `String` type.
## Interface

GraphQL's type system features Interfaces. An interface exposes a specific set of fields that a type must include implementing the interface.  For example, we could represent a Publication interface served as a book or magazine. These types share common characteristics, including a title and release date.

```gql
interface Publication {
  title: String!
  releasedDate: String!
}
  
type Magazine implements Publication {
  title: String!
  releasedDate: String!
  version: Int!
}
  
type Book implements Publication {
  title: String!
  releasedDate: String!
  pages: Int!
}
```
It is very likely that the author could publish both books and magazines, thanks to the interface you do not need to become dependent on a particular type of publication, in this case, we can use a more massive abstraction which is Publication.

## Union

An interesting mechanism is the Union type, which allows you to represent a group of objects that do not have the same fields. An excellent example is a query to a search engine that can search both the title of the book and the author's name.
With this declaration, you can query something like this:
```gql
union SearchResult = Book | Author
  
type Query {
  search(text: String!): SearchResult
}

query {
  search(text: "Park") {
    ... on Book {
      title
    }
    ... on Author {
      name
    }
  }
}
```
And as a result we will see the answer:
```ts
    {
      "data": {
        "search": [
          {
            "name": "Jurassic Park",
          },
          {
            "name": "Jessica Park",
          }
        ]
      }
    }
```
## Declaration scheme

When defining the API scheme, there are two top-level elements available - `query` and `mutation`, which are ordinary objects created in the same way all others. Within them, we declare the possibilities of our API. The definition of the scheme itself is trivial:
```gql
schema {
  query: Query
  mutation: Mutation
}
  
type Query {
}
  
type Mutation {
}
```
## Query

A query is a mandatory element in the schema and is responsible for reading the API. All defined fields inside this object can be compared to various API endpoints. The accepted principle is that elements issued via query are nouns that explicitly specify the entity to be downloaded - in the above example they are book and author. To better illustrate the whole, you can move the previous definitions of objects to query.
```gql
schema {
  query: Query
}
  
type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}

type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```
## Arguments

In some lines you can see the declaration of fields slightly different than in previous cases (e.g. `book (id: String!)`), Where in addition to the field name you can see parentheses with another declaration - it's nothing more than entering an argument to the query - on its basis, you can pass some parameters according to which you want to download data. In the above example, the user's id is expected and the query performed would look something like this:
```gql
query {
  book(id: "1234") {
    title
    isbn
  }
}
```
## Mutation

`Mutation` is an optional part that allows you to add, edit or delete items in our application via the API. Its definition is identical to the type `query`. The only difference is the principle of defining fields - in contrast to `query` in `mutation`, fields are most often called verbs that are clearly defining a performed action. Complementing the above example, it is worth adding the possibility of creating new books.

## Input Type

Before we go to the example declaration of `mutation`, it's worth to present one more type dropped when discussing all the basic types in the section that pertained to the Type System.
To modify or create new elements in the application via GraphQL, a particular type `input` was created, which behaves very much like a regular object, with the difference that during the declaration `input` is used instead of the keyword `type`.

```gql
schema {
  query: Query
  mutation: Mutation
}
  
type Mutation {
  createAuthor(input: AuthorInput): Author
  updateAuthor(id: ID!, input: AuthorInput): Author
}
  
input AuthorInput {
  name: String!
  bio: String
  sex: String!
}
```
In the above example, you can observe that the createAuthor and updateAuthor actions expect the AuthorInput object as an argument and return the Author object. For the declared scheme, creating a new book requires a similar action:

```gql
mutation {
  createAuthor(input: {
    name: String!
    bio: String
    sex: String!
  }) {
    id
    title
  }
}
```


GraphQL newbie tutorial - Schema definition

With the theoretical introduction from the previous post on GraphQL, we can go on to describe an essential part of this standard, namely the type system, which allows you to define the API scheme - GraphQL Schema Definition Language (SDL). It is a special syntax that has been very well documented and created in such a way that you can work with it regardless of the language or framework.

## Type System

GraphQL is strongly typed, which means that each definition must have a particular type. The Type System comes with the help, which provides several possibilities for defining elements of our API. Let’s think about library application (books and authors) declare the first types of our API.
```gql
type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```

   
The most important and most often used element of the whole puzzle is `Object Type`, which in the simplest terms is a collection of fields. Above examples: two objects were declared using the `type Book {}` and `type Author {}` definitions, while inside these declarations you can see fields that are of certain types, e.g. `name: String!`, or  `isBookOftheYear: Boolean!`.

## Scalar types

In GraphQL there are several built-in scalar types for field declarations:

- `String` - set of characters in UTF-8 format,
- `Int` - 32-bit integer,
- `Float` - floating point number,
- `Boolean` - value `true` or `false`
- `ID` - a type representing the unique identifier for the object, most often used for re-downloading (used by the cache). It's serialised in the same way as the `String` type.
## Interface

GraphQL's type system features Interfaces. An interface exposes a specific set of fields that a type must include implementing the interface.  For example, we could represent a Publication interface served as a book or magazine. These types share common characteristics, including a title and release date.

```gql
interface Publication {
  title: String!
  releasedDate: String!
}
  
type Magazine implements Publication {
  title: String!
  releasedDate: String!
  version: Int!
}
  
type Book implements Publication {
  title: String!
  releasedDate: String!
  pages: Int!
}
```
It is very likely that the author could publish both books and magazines, thanks to the interface you do not need to become dependent on a particular type of publication, in this case, we can use a more massive abstraction which is Publication.

## Union

An interesting mechanism is the Union type, which allows you to represent a group of objects that do not have the same fields. An excellent example is a query to a search engine that can search both the title of the book and the author's name.
With this declaration, you can query something like this:
```gql
union SearchResult = Book | Author
  
type Query {
  search(text: String!): SearchResult
}

query {
  search(text: "Park") {
    ... on Book {
      title
    }
    ... on Author {
      name
    }
  }
}
```
And as a result we will see the answer:
```gql
    {
      "data": {
        "search": [
          {
            "name": "Jurassic Park",
          },
          {
            "name": "Jessica Park",
          }
        ]
      }
    }
```
## Declaration scheme

When defining the API scheme, there are two top-level elements available - `query` and `mutation`, which are ordinary objects created in the same way all others. Within them, we declare the possibilities of our API. The definition of the scheme itself is trivial:
```gql
schema {
  query: Query
  mutation: Mutation
}
  
type Query {
}
  
type Mutation {
}
```
## Query

A query is a mandatory element in the schema and is responsible for reading the API. All defined fields inside this object can be compared to various API endpoints. The accepted principle is that elements issued via query are nouns that explicitly specify the entity to be downloaded - in the above example they are book and author. To better illustrate the whole, you can move the previous definitions of objects to query.
```gql
schema {
  query: Query
}
  
type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}

type Book {
  id: ID!
  title: String!
  shortDescription: String!
  description: String
  pages: Int!
  isbn: String!
  releaseDate: String!
  isBookOftheYear: Boolean!
  author: Author!
}
  
type Author {
  id: ID!
  name: String!
  bio: String
  sex: String!
  books: [Book!]!
}
```
## Arguments

In some lines you can see the declaration of fields slightly different than in previous cases (e.g. `book (id: String!)`), Where in addition to the field name you can see parentheses with another declaration - it's nothing more than entering an argument to the query - on its basis, you can pass some parameters according to which you want to download data. In the above example, the user's id is expected and the query performed would look something like this:
```gql
query {
  book(id: "1234") {
    title
    isbn
  }
}
```
## Mutation

`Mutation` is an optional part that allows you to add, edit or delete items in our application via the API. Its definition is identical to the type `query`. The only difference is the principle of defining fields - in contrast to `query` in `mutation`, fields are most often called verbs that are clearly defining a performed action. Complementing the above example, it is worth adding the possibility of creating new books.

## Input Type

Before we go to the example declaration of `mutation`, it's worth to present one more type dropped when discussing all the basic types in the section that pertained to the Type System.
To modify or create new elements in the application via GraphQL, a particular type `input` was created, which behaves very much like a regular object, with the difference that during the declaration `input` is used instead of the keyword `type`.

```gql
schema {
  query: Query
  mutation: Mutation
}
  
type Mutation {
  createAuthor(input: AuthorInput): Author
  updateAuthor(id: ID!, input: AuthorInput): Author
}
  
input AuthorInput {
  name: String!
  bio: String
  sex: String!
}
```
In the above example, you can observe that the createAuthor and updateAuthor actions expect the AuthorInput object as an argument and return the Author object. For the declared scheme, creating a new book requires a similar action:

```gql
mutation {
  createAuthor(input: {
    name: String!
    bio: String
    sex: String!
  }) {
    id
    title
  }
}
```

I’m Robert - co-founder of grapqhleditor.com. We're creating a visual tool for developers that will automate their backend development. I'm sharing our journey as part of my-saas-story. All of our team have long years of experience in the tech industry but none on saas.

It's the first week of November, and we are working the 6th month on our idea. Since then we made a pivot (half sept), and many other things happened. I'll write another post on that. Here wanted to focus on our current state and goals for this quarter. October was an excellent month for us. Check below:

## New blog!

We started a blog.graphqleditor.com. We wrote eight blog posts, published them on few places and that gave us more than 1,5k page views! Below you can see which posts are most popular:
- [Levensthein algorithm for better faker experience](https://graphqleditor.com/blog/levensthein-algorithm-for-better-faker-experience/) 555  views
- [Canvas node graph in typescript](https://graphqleditor.com/blog/canvas-node-graph-in-typescript/) 423 views
- [Twitter clone with React XP and faker](https://graphqleditor.com/blog/twitter-clone-with-reactxp-and-faker/) 415 views
- [Graphsourcing new way to build systems](https://graphqleditor.com/blog/graphsourcing-new-way-to-build-systems/) 191 views
- [GraphQL newbie tutorial - introduction](https://graphqleditor.com/blog/GraphQL-newbie-tutorial-introduction/) 144 views
- [Typescript backend with slothking](https://graphqleditor.com/blog/typescript-backend-with-slothking/) 116 views

## Outreach & Feedback calls

We organized an outreach campaign to front-end developers asking about feedback. We organized ten calls after sending around invites to 1000 people. Those calls were very good. We received a lot of feedback and added those ideas as issues to our GitHub. We had a pleasure to speak with developers from Paypal and Microsoft! It was super exciting!

Some compelling features were around offline version for the enterprise, adding icons to nodes (making them more consumable for non-tech people), generating Interface for frontend or creating fake backend out of the graph. All of them are on our GitHub.

## First OKR’s & Metrics

Together with our advisors, we created a short roadmap for this quarter. It's not 100 ready, but the first version includes our vision, mission and metrics which we want to measure to grow. Below you can find our OKR' results from October. I'll update it every month!

| METRIC                      | COUNT   |
| --------------------------- | ---- |
| github faker stars          | 19   |
| github diagram stars        | 54   |
| github graphql-editor stars | 2550 |
| blog views                  | 1500 |
| website views               | -    |
| blog articles               | 8    |
| mailchimp subscriptions     | 16   |
| demo runs                   | 200  |
| outreach to developers      | 1000 |
| slack users                 | 10   |
| quality calls               | 10   |
| close issues                | 20   |

## Development:

Graphql Editor: Total open issues: 16. Last month we closed ten issuse in our main repo (21 from pivot).

Javascript Diagram: Total open issues: 14. We have rewritten our tool to canvas to handle large schemas. It was an idea by users. Try GitHub schema! IT Rocks!

Team: Artur is working on the front end with few hours of help from Hubert and Kamil is working on backend features.

## Other:
- Launched a slack group (pm me to join). 
- Three guys agreed to contribute
- Created landing page for diagram.graphqleditor.com



 My saas story - oct'18 first OKRs

## Introduction

Have you ever heard about graphsourcing? Sure you have. UML system is a system where you make graph that define your system. Then you write code which must meet the requirements of your UML diagram. Then frontend developer also have to write frontend which is compliant with UML diagram and backend. Also graphic designer is the one that should know something about UML technology.

This is too much for me.

## Graphsourcing good way

Few months ago we created our own graphsourcing tool named Slothking. Learning to use it may not be an easy thing, but benefits we have from graphsourcing are huge. First of all you need to create graph which defines your system. Then you generate frontend, backend, app and so on type definitions. So everybody knows whats going on

## One state to rule them all

With all the benefits of graphsourcing, the one I like most is one state. It is possible to make one state with same types on backend and frontend. With fabulous typescript autocomplete you get a superfast workflow where frontend and backend devs dont have to talk to each other.

## Proof of concept

![graphsourced](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/graphsourced-1730824279208.webp)

As a proof of concept we rewrote our food delivery service system [Foodeli](https://foodeli.pl) in [Aexol](https://aexol.com). First phase of rewriting backend we finished ( 3 people team) in 8 hours + we had everything in one place.

It's a perfect example because Foodeli ecosystem consist of:

* Administrator panel, Web
* Restaurant individual panels, Web
* Driver app, iOS, Android
* Client app, Web

And all of them have to use the same backend system.

## Code

So how graphsourcing looks in practice?

### Backend

Generation command:

```bash
sloth sync nodets foodeli api.ts
```

Small Part of the generated code

```ts
export type DriverType = {
  _id?: ObjectId;
  name: string;
  phone?: string;
  Address?: ObjectId | AddressType;
  pushToken?: string;
  snsEndpoint?: string;
  snsSubscriptiom?: string;
  foodeliDriver?: boolean;
  User: ObjectId | UserType;
  PESEL?: string;
  deliveryRate?: number;
};
export type GPSType = {
  _id?: ObjectId;
  geoLocation?: ObjectId | geoLocationType;
  Driver?: ObjectId | DriverType;
  created?: Date;
};
```

Types for endpoint and middlewares are also provided

### Frontend

Generate api and state

```bash
sloth sync fetch-api foodeli api.ts
```

Part of frontend state

```ts
const endpoints: {
    name: string;
    endpoints: {
      addOrder: (params:{props:         {
          comments?: string;
          paymentForm: string;
          totalPrice: number;
          readyin: number;
          phone: string;
          Address: Partial<AddressType> | string;
          token: string;
        },method?: 'GET'|'POST'|'PATCH'|'DELETE'|'PUT'}) => Promise<        {
          Order: OrderType;
        }>;
      myOrders: (params:{props:         {
          period?: string;
          token: string;
        },method?: 'GET'|'POST'|'PATCH'|'DELETE'|'PUT'}) => Promise<        {
          Orders: OrderType[];
        }>;
      restaurantOrderDetails: (params:{props:         {
          orderId?: string;
          token: string;
        },method?: 'GET'|'POST'|'PATCH'|'DELETE'|'PUT'}) => Promise<        {
          Order: OrderType;
          orderSteps: orderStepType[];
        }>;
      updateOrderStatus: (params:{props:         {
          status?: OrderStatus;
          orderId?: string;
          token: string;
        },method?: 'GET'|'POST'|'PATCH'|'DELETE'|'PUT'}) => Promise<        {
          Order: OrderType;
        }>;
    }
} = foodeli: {
    name: 'foodeli',
    endpoints: {
      addOrder: ({ props, method = 'POST' }) =>
        fn(`${host}foodeli/addOrder`, {
          props,
          method,
        }).then(res => res.json()),
      myOrders: ({ props, method = 'POST' }) =>
        fn(`${host}foodeli/myOrders`, {
          props,
          method,
        }).then(res => res.json()),
      restaurantOrderDetails: ({ props, method = 'POST' }) =>
        fn(`${host}foodeli/restaurantOrderDetails`, {
          props,
          method,
        }).then(res => res.json()),
      updateOrderStatus: ({ props, method = 'POST' }) =>
        fn(`${host}foodeli/updateOrderStatus`, {
          props,
          method,
        }),
    },
  },
}
//Small part of the state
export type foodeliExtensionState = {
  Order: OrderType;
  Orders: OrderType[];
  orderSteps: orderStepType[];
  Restaurant: RestaurantType;
  restaurantDeliveryZone: restaurantDeliveryZoneType[];
  geoParams: geoParams;
  deliveryCost: deliveryCost;
  dishCategoryList: dishCategoryType[];
  DishList: DishType[];
  dishVariantList: dishVariantType[];
  dishAdditionList: dishAdditionType[];
  Drivers: DriverType[];
  Address: AddressType;
  deliveryZones: deliveryZoneType[];
  Settlements: OrderType[];
};
```

So you just call generated endpoint with certain params on front end and you have typed response automatically injected to state using [state](). If everybody were using it , it would be a huge boost to Backend Driven development

### Corona SDK Apps

Yes we are writing apps in corona so we decided we should have Api generator for Corona SDK too. Here is a small part of it.

```ts
local json = require 'json'
local library = {}

function library:init(host,errHandler)
    self.errorHandler = errHandler
    self.host = host
    self.requestTab = {}
end

function library:removeRequest(id)
  for i=1,#self.requestTab do
    if self.requestTab[i] == id then
      table.remove(self.requestTab,i)
    end
  end
end

function library:addRequest(id)
  table.insert(self.requestTab,id)
end

function library:cancelRequest(id)
  for i=1,#self.requestTab do
    if self.requestTab[i] == id then
      network.cancel( self.requestTab[i] )
      table.remove(self.requestTab,i)
    end
  end
end

function library:cancelAllRequests()
  for i=1,#self.requestTab do
    network.cancel( self.requestTab[i] )
  end
  self.requestTab = {}
end
function library:aws_sns_registerDevice(callback,token,platform,applicationArn, method)
  local requestId
  if method == nil then
    method = "POST"
  end
  local function networkListener( event )
    self:removeRequest(requestId)
      if event.isError then
            if self.errorHandler then
                self.errorHandler(event)
            else
                callback(event)
            end
      else
      if callback then
        callback(event)
      end
    end
  end
  local headers = {}
  headers["Content-Type"]="application/json"
  local params = {}
  params.headers = headers
  local bodyParams = {
    token=token;
    platform=platform;
    applicationArn=applicationArn;
  }
  params.body = json.encode(bodyParams)
  requestId = network.request(self.host.."/".."aws_sns".."/".."registerDevice", method, networkListener, params )
  self:addRequest(requestId)
end
```

## Conclusion

Graphsourcing is so powerful man, all this code has been generated from visual graph!

I presented only micro parts of it as it is a huge one!

## Alpha user?

If you want to become an alpha user, mail me for instructions or you can start your self for free, just by using few repos( as this is oopen source technology )

Slothking app
[CLI](https://github.com/graphql-editor/sloth)
[Boilerplate to start with backend](https://github.com/graphql-editor/backend-nodets-boilerplate)
[State manager based on unstated](https://github.com/graphql-editor/state)

 Graphsourcing new way to build systems


I’m Robert - Head of Growth at grapqhleditor.com. I’m responsible for every non-tech part of the project -  talking with users, building feature roadmap, building traffic and promoting it in tech community. To grow my tech skills I’ve also decided to learn GraphQL. Since I’m a newbie, this tutorial is also for newbies.

## Where GraphQL came from?

GraphQL was introduced in 2015 by Facebook as an alternative to REST. Back then It wasn’t just an experiment - it was already in production inside facebook mobile apps since 2012.  Just after public release, It became extremely popular, and around that time many companies were working on similar solutions. This technology started to gain attention since it can be used with many other languages and there’re many ready to go libraries to most popular styles. Right now according to Stackshare there’re nearly 2k companies using it. Early adopters included Coursera, Github, ProductHunt, Yelp or Twitter.

## What is GraphQL?

To introduce GraphQL we I’ll use an example of data and compare functionality with REST. This example will show you why new technology is more efficient, simpler to use and what was motivation to create it. 

Let’s assume that we are creating a backend for application with two versions (web and mobile). The core of the system will contain information about football players, teams they played and some other details. Mobile version of the application should show less information.

| Web                       | Mobile     | 
| -------------| -------------| 
| Name| Name| 
| Bio| Team (Years)|   
| Team (Description, Years) | Team (Years)|   
| Team (Description, Years) ||   

If we would create API based on REST, therefore, we would need to write two requests:


    GET /player/{id}
    {
      "id": „101”
      "name": „David Beckham”
      "bio": „…”
      „age”: „43”
    }


    GET /player/{id}/teams
    {
      „Teams”: [{
        „id": „201”,
        „name”: „Real Madrid”,
        „description": „…”,
        „goals”: „…”,
        „matches”: „…”,
        „years”: „2003-2007”
      },
      ...
      ]
    }

By looking at the response, you can see that we get more data than we need in both cases. It is essential in mobile apps because of mobile data and the speed of loading.  Of course, we could overcome that by writing different endpoints which will get us only what we want. Another way is to implement API in a way that we could choose what we want I.e. GET /player/{id}/teams?only=name. But that’s hard the solution to maintain in agile software development where requirements are changing every week.


## Opposite to that, we can introduce GraphQL.

Backend with GraphQL is more flexible because it has only one endpoint. Customers write a query and specify what do you want exactly and gets data in JSON. In our football example, we can create queries for each platform (web and mobile).

**Web application:**

    query {
      player(id: "101") {
        name
        bio
        teams {
          title
          description
        }
      }
    }

**Resposne:**

    {
      "data": {
        "player": {
          "name": "David Beckham",
          "bio": "...",
          "teams": [{
            "title": "Real Madrid",
            "description": "..."
          }, ...]
        }
      }
    }

**Mobile app**

    query {
      player(id: "101") {
        name
        teams {
          title
        }
      }
    }

**Resposne:**

    {
      "data": {
        "player": {
          "name": "David Beckham",
          "teams": [{
            "title": "Real Madrid"
          }, ...]
        }
      }
    }

As you can see with each query, we are getting only what we want. That’s the power of GraphQL - flexibility. You don’t need to create endpoints for different screens. Various clients can use a once defined schema in a way that they need to.


## Fewer requests.

In traditional REST approach usually, there are many GET requests to show data on one screen. It’s not super efficient when it comes to mobile apps - it slows them down and needs more internet data transfer. GraphQL allows a user to create only one endpoint. Thanks to technology introduced by Facebook engineers communication between client and a server is better optimised.


## Query language

The most important feature of GraphQL is that it’s language agnostic. It’s not created to work with specific technology. It’s a query language with its own rules which for most popular programming languages. There’re many supportive libraries on the internet for: C#/.NET, PHP. Javascript, Java, Python, Ruby and many more.


## Summary

GraphQL is a query language and runtime that we can use to build and expose APIs as a strongly-typed schema instead of hundreds of REST endpoints. Your clients see the schema. They write a query for what they want. They send it over and get back exactly the data they asked for and nothing more. GrapqhQL advantages:

- fewer data and requests for mobile apps,
- simplicity and visible API structure
- can be used with many technologies
- is used by Twitter, Facebook, Github and many more

GraphQL newbie tutorial - introduction

I’m Robert - Head of Growth at grapqhleditor.com. I’m responsible for every non-tech part of the project -  talking with users, building feature roadmap, building traffic and promoting it in tech community. To grow my tech skills I’ve also decided to learn GraphQL. Since I’m a newbie, this tutorial is also for newbies.

## Where GraphQL came from?

GraphQL was introduced in 2015 by Facebook as an alternative to REST. Back then It wasn’t just an experiment - it was already in production inside facebook mobile apps since 2012.  Just after public release, It became extremely popular, and around that time many companies were working on similar solutions. This technology started to gain attention since it can be used with many other languages and there’re many ready to go libraries to most popular styles. Right now according to Stackshare there’re nearly 2k companies using it. Early adopters included Coursera, Github, ProductHunt, Yelp or Twitter.

## What is GraphQL?

To introduce GraphQL we I’ll use an example of data and compare functionality with REST. This example will show you why new technology is more efficient, simpler to use and what was motivation to create it.

Let’s assume that we are creating a backend for application with two versions (web and mobile). The core of the system will contain information about football players, teams they played and some other details. Mobile version of the application should show less information.

| Web                       | Mobile       |
| ------------------------- | ------------ |
| Name                      | Name         |
| Bio                       | Team (Years) |
| Team (Description, Years) | Team (Years) |

If we would create API based on REST, therefore, we would need to write two requests:

```ts
GET /player/{id}
{
"id": „101”
"name": „David Beckham”
"bio": „…”
„age”: „43”
}
```

```ts
GET /player/{id}/teams
{
„Teams”: \[{
„id": „201”,
„name”: „Real Madrid”,
„description": „…”,
„goals”: „…”,
„matches”: „…”,
„years”: „2003-2007”
},
...
]
}
```

By looking at the response, you can see that we get more data than we need in both cases. It is essential in mobile apps because of mobile data and the speed of loading.  Of course, we could overcome that by writing different endpoints which will get us only what we want. Another way is to implement API in a way that we could choose what we want I.e. GET /player/{id}/teams?only=name. But that’s hard the solution to maintain in agile software development where requirements are changing every week.

## Opposite to that, we can introduce GraphQL.

Backend with GraphQL is more flexible because it has only one endpoint. Customers write a query and specify what do you want exactly and gets data in JSON. In our football example, we can create queries for each platform (web and mobile).

**Web application:**

```ts
query {
player(id: "101") {
name
bio
teams {
title
description
}
}
}
```

**Resposne:**

```ts
{
"data": {
"player": {
"name": "David Beckham",
"bio": "...",
"teams": \[{
"title": "Real Madrid",
"description": "..."
}, ...]
}
}
}
```

**Mobile app**

```ts
query {
player(id: "101") {
name
teams {
title
}
}
}
```

**Resposne:**

```ts
{
"data": {
"player": {
"name": "David Beckham",
"teams": \[{
"title": "Real Madrid"
}, ...]
}
}
}
```

As you can see with each query, we are getting only what we want. That’s the power of GraphQL - flexibility. You don’t need to create endpoints for different screens. Various clients can use a once defined schema in a way that they need to.

## Fewer requests.

In traditional REST approach usually, there are many GET requests to show data on one screen. It’s not super efficient when it comes to mobile apps - it slows them down and needs more internet data transfer. GraphQL allows a user to create only one endpoint. Thanks to technology introduced by Facebook engineers communication between client and a server is better optimised.

## Query language

The most important feature of GraphQL is that it’s language agnostic. It’s not created to work with specific technology. It’s a query language with its own rules which for most popular programming languages. There’re many supportive libraries on the internet for: C#/.NET, PHP. Javascript, Java, Python, Ruby and many more.

## Summary

GraphQL is a query language and runtime that we can use to build and expose APIs as a strongly-typed schema instead of hundreds of REST endpoints. Your clients see the schema. They write a query for what they want. They send it over and get back exactly the data they asked for and nothing more. GrapqhQL advantages:

* fewer data and requests for mobile apps,
* simplicity and visible API structure
* can be used with many technologies
* is used by Twitter, Facebook, Github and many more

## Introduction

Hello, today I will write a little bit about tooling. 2 weeks ago I thought about starting this blog. I asked my friend who blogs what blog engine should I use. His answer was rather suprising as he told me I should have used static website and commit blog posts as pull requests to it 😮.

## Searching for the perfect solution

So, I started exploring the internet to find the best blog layout ( reactjs ) tool to write my static blog. I was able to dig out `gatsby starter blog` from hundreds of chinese repos which github is flooded with right now. At the moment I created this blog I had no experience with Gatsby ecosystem but it looked promising for me.

## Running

Running this kind of gatsby package required me only to install `gatsby-cli` and run command `gatsby develop`. Pretty easy? Huh?

## Modifications

I decided to add some tweaks to this simple blog package as it was really pure blog with one author. So to add other authors( who I don't have yet :( ) I added authors folder, so to add you as an author you need to create folder with your name and create `index.js` file with this kind of content inside it:

```ts
export const Artur = {
  photo: require('./Artur.jpeg'),
  desc:
    'GraphQL passionate. Code generation guru. Short code lover. Father. CTO. CEO.',
  name: 'Artur Czemiel',
  email: 'aexol@aexol.com',
}
```

and add of course this line to `authors/index.js` :

```ts
import { Artur } from './Artur'
export const Authors = {
  Artur,
}
```

Later on you can use it inside your blogpost.

## How to add your blog post

Adding your blog post is pretty easy though. Again you have to create a folder inside pages folder with blog post slug like `my-very-interesting-article`. Add an `index.md` file to it with this kind of header which is formatted by `graymatter` package then:

```json
---
title: My very interesting article
date: '2018-10-27T13:23:04.284Z'
author: Artur
---
```

That's it. After writing article you just submit pull request to your fork. I merge the pull request and publish your article to website.

## Publish tools

Sometimes I am kinda lazy person. I added small publish CLI to this project, which automatically using `opn` opens browser with prefilled url and title fields for: `reddit` `LinkedIn` `twitter` `hackernews`. So it is much easier to share your blog posts from this blog. It lives in `bin/index.js` folder of this blog and uses `yargs` and `inquirer` and `graymatter` which I mentioned before.

![publishTools.gif](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/publish-tools.gif)

After that it opens a window so I can post on reddit. Simple and beautiful!

![redditpost.webp](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/redditpost.webp)

## Your support

If you want to support me just star GraphqlBlog repo. The link is in the navigation bar. Of course you can write your own article here and submit a pull request. I promise I will improve the bloggin system to be the best open source blog in the world ; ).

Blog publish tools inside gatsby blog

A story about one [Diagram](https://github.com/graphql-editor/diagram)

## Introduction

Hello again. Today I am going to present my journey with node diagrams. I used to love them when I was working as a VFX scripter 8 years ago especially Maya dependency graph. For years as a Frontend developer I had been looking for totally abstracted way of creating visual diagram. After that I have not found satysfying solution, this year I decided to write my own library for that

## First Version

First version was based on react DOM Nodes!

Yeah it was a crazy idea. However, ux handled by dom was cool and the overall experience satysfying.... with 30 nodes. With bigger number of nodes things started getting slower and slower.

## Going canvas

After trying many possible optimizations I decided again to rewrite everything( almost! as space bar menu looks cool in react(for now)). Also leaving some components in react gives me an opportunity to find contributors for this project. Now the performance of it is stunning. I don't know why it was so slow on DOM engine?

## Abstracting the renderer

Right now I am keeping the diagram data inside state and renderer separatly. That means you can write another renderer for example Augmented Reality renderer and it should just work with drawing functions only. How? Because all the picking is done inside ts functions and its not connected to for example canvas pixel color.

## How it works

```ts
import { Graph } from '@slothking-online/diagram';
import * as React from 'react';
let allCategories = [
  {
    name: 'middlewares',
    items: [
      {
        name: 'middleware',
        type: 'middleware',
        inputs: [
          {
            name: '',
          },
        ],
        outputs: [
          {
            name: '',
          },
        ],
      },
    ],
  },
];

export const MyGraphComponent = () => (
  <Graph
    serialize={(nodes, links, tabs) => {
      // Do whatever you want with node data from diagram
    }}
    categories={allCategories}
  />
);
```

So you can use it inside any React JS/TS application

## Support Me!

If you like my Idea and want to support me, please give me a star or even contribute to my projects!

[Diagram](https://github.com/graphql-editor/diagram)

[Editor](https://github.com/graphql-editor/graphql-editor)


Canvas node graph in typescript


Today I am writing about faking data again using [ts-api-faker](https://github.com/graphql-editor/ts-api-faker) . Usually we pass this kind of data to faker

```json
[
  {
    "name": "name.firstName",
    "surname": "name.lastName",
    "mail": "internet.email",
    "profilePhoto": "internet.avatar",
    "animalPhoto": "image.cat"
  },
  {
    "name": "name.firstName",
    "surname": "name.lastName",
    "mail": "internet.email",
    "profilePhoto": "internet.avatar",
    "animalPhoto": "image.dog"
  }
]
```

and then we receive faked data

```json
[
  {
    "name": "Van",
    "surname": "Veum",
    "mail": "Corbin.Fritsch49@gmail.com",
    "profilePhoto": "https://s3.amazonaws.com/uifaces/faces/twitter/pixage/128.jpg",
    "animalPhoto": "https://source.unsplash.com/200x200/?cat"
  },
  {
    "name": "Serena",
    "surname": "Wilderman",
    "mail": "Mariam_Thiel@hotmail.com",
    "profilePhoto": "https://s3.amazonaws.com/uifaces/faces/twitter/imcoding/128.jpg",
    "animalPhoto": "https://source.unsplash.com/200x200/?dog"
  }
]
```

It works perfect but... Usually a schema looks like this.

```json
[
  {
    "name": "String",
    "surname": "String",
    "mail": "String",
    "profilePhoto": "String",
    "animalPhoto": "String"
  }
]
```

The answer from faker is inappropriate then

```json
[
  {
    "name": "atque",
    "surname": "eos",
    "mail": "voluptas",
    "profilePhoto": "similique",
    "animalPhoto": "earum"
  }
]
```

What if you use levensthein algorithm on keys of values and transform values to the closest to key name option?

Again we pass

```json
[
  {
    "name": "String",
    "surname": "String",
    "mail": "String",
    "profilePhoto": "String",
    "animalPhoto": "String"
  }
]
```


Voila, we get the correct faker structure.

```json
[
  {
    "name": "Edgar",
    "surname": "Alyce64",
    "mail": "Eusebio.Gottlieb@yahoo.com",
    "profilePhoto": "https://source.unsplash.com/200x200/?profile",
    "animalPhoto": "https://source.unsplash.com/200x200/?animal"
  }
]
```


I've just added this feature to my repo [ts-api-faker](https://github.com/graphql-editor/ts-api-faker)

Feel free to contribute and extend this library functionality. If you support me and this idea please star this repo to help me get more contributors and extend ts-api-faker library.

In future we can add machine learning to this and get ultimate intelligent faker for our apis and databases :)