_This walkthrough / guide is intended for those who have basic knowledge about building APIs._

**GraphQL** has been on a hype recently; to be fair, it's worth it. The need might be quite insidious when building less complex APIs, however, as with all applications, increasing the API capabilities increases complexity in some way and therefore requires a newer approach to handling this complexity without causing pain to the consumers of our API - even when it's only us.

> **"A query language for your API".**
> -[_Official Website_](https://graphql.github.io/)

This simply means, we have a language with which we can query our API from the front-end (or even back-end). The goal here is to provide us with some consistency and extra power when building APIs. Issues like API versioning can be handled more subtly, thus reducing the need to force users to update their applications for trivial stuff.

**For example:**

Imagine we had an application with some endpoints: 

`http://localhost:8000/api/v1/rooms`

`http://localhost:8000/api/v1/make-rooms`

`http://localhost:8000/api/v1/say-hello`

Introducing GraphQL, our application now presents just one endpoint:

`http://localhost:8000/api`

All that consumers need to do now is send us a query string on this endpoint; we process the query using GraphQL and respond with data. Quick, intuitive, powerful.

_Moving forward..._

I want to focus on using GraphQL in PHP as so much explanation already exists for  NodeJS (Express) in the [official docs for GraphQL](https://graphql.github.io/graphql-js/running-an-express-graphql-server/).

At this point, you should read the [docs](https://graphql.github.io/learn/) to fully understand how GraphQL works before proceeding.

**DISCLAIMER:**

This is probably not the only valid implementation of GraphQL in PHP. You can choose to explore other options as well.

Set Up
------------------------------

I'll be using  [Siler](https://siler.leocavalcante.dev/) (a micro-framework with GraphQL functionality built-in) for my stand-alone app, then I'll show you the set up with my [Laravel](https://laravel.com/) app.

Also, it is more comfy to play with GraphQL in the browser using the [ChromeiQL](https://chrome.google.com/webstore/detail/chromeiql/fkkiamalmpiidkljmicmjfbieiclmeij?hl=en) extension.

GraphQL with my stand-alone app
------------------------------

Let's dive straight into the code. [See repo here](https://github.com/cmdlucas/siler-gql-play):

Clone repo into your directory

`git clone https://github.com/cmdlucas/siler-gql-play.git`

then run

`composer install`

The project is set up to have two major dependencies in order to listen and respond to GraphQL requests:

- `webonyx/graphql` - This is the core PHP implementation of the GraphQL standard. It processes the query from the incoming request and responds with the data as specified on our resolvers. 

- `leocavalcante/siler` - This wraps the core package above and adds another major functionality: enables us declare Schema Types and resolvers expressively. It basically parses our  Schema Types declaration string together with the resolvers array, then sends it to the package above.

To avoid bumping into a `class does not exist` error, you can run:

`composer dump-autoload -o`

With our setup completed, we can now run our server and test queries on ChromeiQL

`php -S localhost:8000 server.php`

Now, start the  ChromeiQL extension (ignore any initial error),  set the endpoint into `http://localhost:8000/api`, then paste this query on the left side of the page loaded:

```graphql
query Rooms {
   hello
   rooms{
     key
   }
}
mutation MakeRooms ($keys: [ID!]) {
  makeRooms(keys: $keys) {
    info {
      keyToBin
      timestamp
    }
    key
  }
}
```

Look bottom-left, drag up the area labeled QUERY VARIABLES and paste this into the text box:

```json
{
  "keys": [23, 455, 75, 746] 
}
```

When you click the Run button, you have the option to select from the dropdown between `Rooms` (which represents the label of *query* above) and `MakeRooms` (which represents the label of *mutation*).

**Note:** If we were to send this query without using ChromeiQL, we would either want to send the `Rooms` query or `MakeRooms` mutation. Within either of those, we can specify as many "sub-query" declared within either *Query* or *Mutation* as supported in the schema in our *schema.graphql* file (located in */src/config*). 

```graphql
type Info {
    keyToBin: String!
    timestamp: Int!
}

type Room {
    info: Info!
    key: Int!
}

type Query {
    hello: String
    rooms: [Room!]!
    roomsHavingKey(search_keys : [ID!]!): [Room!]!
    roomsNotHavingKey(search_keys : [ID!]!): [Room!]!
}

type Mutation {
    makeRooms (keys: [ID!]): [Room!]!
} 
```

([Go here](https://graphql.github.io/learn/serving-over-http/) to see how to send queries over http) 

After selecting which type to run, you can see the server's response is as specified within the query sent. This means we can do so many things in a single query to the server - be it a `Query` type or a `Mutation`. Alles gut? Okay...

As you can see, within the `type Query {}` schema above, we specified `roomsHavingKey` and `roomsNotHavingKey`, but there was no need to include it in the query sent to the server since we (the caller) did not need any of that information. But hey, let's try to get that information.

In your ChromeiQL, change the query field's content to this:

```graphql
query Rooms($search_keys: [ID!]!) {
   rooms{
     key
   }
   roomsNotHavingKey(search_keys: $search_keys) {
     key
     info{
       keyToBin
       timestamp
     }
   }
 }
 mutation MakeRooms ($keys: [ID!]) {
   makeRooms(keys: $keys) {
     key
   }
 }
```

In the `QUERY VARIABLES` area, change the content to this:

```json
{
   "keys": [23, 455, 75, 746],
   "search_keys": [23, 75]
}
```

To get some result, first we run and select `MakeRooms`, then we run and select `Rooms` from the dropdown. As a result of the latter action, we get this response from the server:

```json
{
   "data": {
     "rooms": [
       {
         "key": 23
       },
       {
         "key": 455
       },
       {
         "key": 75
       },
       {
         "key": 746
       }
     ],
     "roomsNotHavingKey": [
       {
         "key": 455,
         "info": {
           "keyToBin": "111000111",
           "timestamp": 1558951933
         }
       },
       {
         "key": 746,
         "info": {
           "keyToBin": "1011101010",
           "timestamp": 1558951933
         }
       }
     ]
   }
 }
```

This ran just as expected. The rooms sub-query returns a list of room objects each with the key property only. Also, since we specified it too, the `roomsNotHavingKey` sub-query returned a list of rooms with keys other than the keys in the search_key list specified in the QUERY VARIABLES.

We can take this concept to a more complex level, depending on the requirements of our application. This is amazing power lying in our hands at one API endpoint!

GraphQL with Laravel
--------------------

Here, my goal is just to show you how to easily configure Siler GraphQL with Laravel using the example specified in the README of the Siler GraphQL package.

Dive straight into testing? [Go to repo](https://github.com/cmdlucas/siler-gql-laravel-play)

Firstly, create a new laravel project into any folder on your computer:

`composer create-project --prefer-dist laravel/laravel new-project-folder`

Now, install the dependencies required (which includes those required for GraphQL to be activated):

`composer require --prefer-dist leocavalcante/siler  webonyx/graphql-php`

Navigate to _/routes/web.php_ and add this:

```php
use Siler\GraphQL;

class Init {
    public static function play() {
        $typeDefs = file_get_contents(__DIR__.'/schema.graphql');
    
        $resolvers = [
            'Query' => [
                'message' => 'foo',
            ],
            'Mutation' => [
                'sum' => function ($root, $args) {
                    return $args['a'] + $args['b'];
                },
            ],
        ];
    
        return GraphQL\init(GraphQL\schema($typeDefs, $resolvers));
    }

}

Route::post('/play', function() { 
    return Init::play();
}); 
```

Create a _schema.graphql_ file in the routes folder (could be anywhere else, just make sure you read it using the correct URL) and add this:

```graphql
type Query {
  message: String!
}

type Mutation {
  sum (a: Int, b: Int): Int
} 
```

Run: `php artisan serve`

Now, we can query from ChromeiQL and get a response. Set your endpoint to `http://localhost:8000/play`, paste this into the query field:

```graphql
query Message {
  message
}
mutation Sum($a: Int, $b: Int) {
  sum(a: $a, b: $b)
}
```

Then this into the `QUERY VARIABLES` field:

```json
{
  "a": 5, "b": 6
}
```

When we run and select `Sum`, we get this:

```json
{
   "data": {
     "sum": 11
   }
}
```

Very straightforward!

If you have questions, additions or corrections, please feel free to [connect and send me a message](/connect).

GraphQL has been on a hype recently; to be fair, it's worth it. The need might be quite insidious when buildin...

Recently, I've been doing a lot of stuff with images. However, one simple repetitive feature stood out in all of the projects: selecting images and being able to remove any or all of them from the screen after selection.

That's an easy functionality, right? Yeah, you're right. Or may be you're wrong. Well, I don't know. It's up to you and the framework or library you use. It also depends on how much time you're willing to put into making the code for this feature as clean and less smelly as possible. Even at that, it's still, well... easy, because we already have the powerful [FileReader](https://developer.mozilla.org/en/docs/Web/API/FileReader) API.

Let's take a look at this package [ImageSelectPreview](https://github.com/cmdlucas/react-image-select-pv) where the [FileReader](https://developer.mozilla.org/en/docs/Web/API/FileReader) API is used extensively. I made it because I was tired of copying and pasting codes every time I needed that "simple" feature in my project. Yes, it only works with React (because, React for the win in terms of simplicity, imo), but if you don't use React, you can take advantage of this idea and build one that works with whatever library or framework you use (unless my little speech is already making you a React convertee, then I'm winning. Haha).

#### Okay. Why should you? 

You mean, why shouldn't you? Like, why shouldn't you let your users preview their images when they select them? Yeah sure, it's not a profile picture crop-filter-adjust kill-it-all functionality but, your users will be happy when they can select images and just "unselect" them seamlessly. Who likes to be stressed? Only you, of course.

Anyway, the package is still limited to button prompt but I will definitely be adding a drag-and-drop functionality soon. You can comment below if you feel it's unnecessary. At the end of the day, we all want beautiful UIs that give amazing UXs; [ImageSelectPreview](https://github.com/cmdlucas/react-image-select-pv) is just a very tiny tool in our toolbox for achieving that goal.

__________________________________________________________________________

[ImageSelectPreview](https://github.com/cmdlucas/react-image-select-pv) has been updated to include drop-in (drag-and-drop) functionality. See the docs to learn more about the APIs as props and add it into your project.

Recently, I've been doing a lot of stuff with images. However, one simple repetitive feature stood out in all ...

### BACKGROUND

#### TLDR;

Building responsive applications is a norm. It's not so much of a complicated thing to do when working on Single Page Applications (SPA) with React. The reason for this is simple: declarative style programming can enable us selectively display contents on the browser since there is the window object. We can determine the size of the browser's window and choose the components to show to our users - or even the style to use on a component. The situation changes drastically when we want to render on the server. What does this mean?

Server-side rendering is not a new concept. It's the way we've been building for the web until Javascript became king and JSX became a worthy servant. Basically, it's just, make a request to the server, the server processes request, does due diligence (works on data), then responds with fully composed html. That is, everything has been rendered on the server giving the browser the less complex task of painting. Yes, Javascript and CSS can be sent with the response but this is optional. Whereas with SPAs we give our browser the responsibility of producing the html that the browser paints to the screen through javascript.

The task becomes tedious when we want to server-render content and be selective with what we render based on screen size. There's just no DOM; no window object either. Thanks to Next.js our pains are washed away - at least to some extent. We can worry no more about how to render  and send html responses to our clients-side.  NextJS can help us do static generation and server-side rendering. Please see here to learn more. 

However, using NextJS doesn't mean we automatically have a window object on our server. For this reason, we need to figure out how to render contents responsively. There's the React's Semantic-UI package to help us with responsiveness on the server. It's easy to plug into Next.js, but it's not so obvious. I have put together a succinct boilerplate that handles this and added some other packages often needed for development in Next.js. [Find here on github](https://github.com/cmdlucas/react-ssr-boilerplate).

The rest of this article breaks down the structure of the boilerplate and attempts to clarify any possible confusion that might arise. Keep in mind that this is not a framework or library. **It's just a boilerplate - nothing more**.

### STRUCTURE _(inline with Next.Js)_

This is the folder representation:

```
- root 
|- components 
|- pages 
|- redux 
   |- middleware 
      |- saga 
   |- reducers 
|- static  
   |- css 
   |- fonts
|- utils 
   |- components 
      |- general 
      |- mediaquery
   |- constants 

```

The most important folders here are: pages and static . While the static folder is required by Next.js as stated [here](https://nextjs.org/docs#static-file-serving-eg-images), the behaviour for the pages folder can be configured to suit your needs. [See here](https://nextjs.org/docs#disabling-file-system-routing).

The `utils` folder comprises of components and constants folder. The `/utils/component` folder is intended to house components that will be useful to the whole application. For example, header, footer or even the layout as seen in the boilerplate. Once again, this is just semantics. It can be changed to suit your needs. 

Let's pay some attention to the `/utils/components/mediaquery` folder. Here you'll find semantics.js . The vitality of the `MediaQuery` component exported from this file cannot be overstated. Anytime you need to render a component uniquely to a type of screen, pass the type as props to MediaQuery. See `/components/home.js` for example implementation. All types are constants from `/utils/constants/mediaquery.constants.js`

The `/redux` folder is for all things redux. See here to learn how you can start using redux. The `/components` folder is where components related to individual pages are kept. For example, `/components/home.js` serves only the home page through `/pages/index.js`.

### EDITING FILES

If you will need to edit `_document.js`, please do so with caution.  Global props are generated here and passed to the App component in `_app.js` by Next.js. Understand that if you edit `_app.js` and remove the `<WindowsContext.Provider>` then the `<MediaQuery>` in semantics.js will not work.

You can edit the files in the redux folder as you deem fit. Only ensure, however, that you supply the store to the `<Provider>` declared in `/pages/_app.js`.

### CONCLUSION

All you need is an understanding of Next.js and React. With these, you're good to use the boilerplate as you deem fit. It's a good way to bootstrap and save time when you want to build a responsive SSR application.

_Please submit a PR, if you feel there are dependencies that should be added to make the boilerplate more robust._

Building responsive applications is a norm. It's not so much of a complicated thing to do when working on Sing...