DEV Community: Divyendu Singh

CLI editor in Typescript

Divyendu Singh — Tue, 17 Sep 2019 22:37:20 +0000

Wrote a small buffer based CLI editor in Typescript. Was a great experience to implement a small buffer, cursor class.

It even supports undo. Also, without any dependencies.

Feedback 🙌🙏

Code: https://github.com/divyenduz/chi-editor

How does a software like full story or session stack work?

Divyendu Singh — Wed, 17 Oct 2018 06:42:56 +0000

They capture the interactions on the web page and "replay" them later in a deep analytic-esque session. The console is also available.

To me it looks like that the software is storing the whole document as state (including the mouse location) and uses some API to make the console available as well.

The stored data is in time-series format.

Later this stored data can be used to:-

Create frames for a video that can be played by the admin.
Play the document + interactions in browser itself (some how).
I was wondering if anyone is already aware of how this is possible?

Anyone here doing crazy stuff with Ableton and Javascript (or something else)

Divyendu Singh — Tue, 16 Oct 2018 08:30:34 +0000

I recently did some experiments with music theory and found out that Ableton also has a TCP interface.

I was curious to know if people are doing something with that. Would love to collaborate.

Prisma — Deep Dive

Divyendu Singh — Sat, 10 Feb 2018 19:33:12 +0000

Cloud Native — GraphQL — Database API Layer

A futuristic Cloud Native — GraphQL Database API Layer

P.S. This post is intended to be a giant deep dive into Prisma. If you think any part is missing OR is not clear OR can be improved in any way. Reach out to me via comments or tweet to me.

Introduction
Setup
Prisma init Command Breakdown
Directory Structure
Run the Application Server
Access the database
Teach a Man How to Fish
Permissions
Advanced Queries
Advanced Mutations
Subscriptions
Export/Import Data
Monitoring
Advanced Prisma and GraphQL Stuff
Gotchas
Plugs
Further Reading

Introduction

This post talks about one of the most fascinating GraphQL tools I have come across.

What is Prisma?

Prisma is a tool (read product that has evolved after a lot of production experience) that converts your database into a very powerful GraphQL API.

Think of Prisma as a “cloud native”, “GraphQL first” database but it is more than that as we will see.

Prisma is at the frontier of a very powerful GraphQL ecosystem.

Where does Prisma sit in my setup?

What does (can) Prisma do?

You can be in following situations:-

You are starting from scratch

Prisma can be used to automagically build tables and a powerful GraphQL API on top of it (this is what we will majorly cover in this post). You can then import your data into Prisma and be merry.

Prisma can already do this with very effectively with MySQL and others (MongoDB, ElasticSearch, Postgres etc) are coming soon.

You have an existing database but you want to expose it via a GraphQL API

Either you can also do this task at the application server level or Prisma can act as a thin GraphQL wrapper on top of your existing database.

You rely on 3rd party GraphQL and REST APIs for information

At the application server level you can use REST API as the source of data. The community is actively working on tools to make this experience much better.

Any combination of the above 3.

Prisma is not limited to one setup, it can effectively combine any permutation and combination of the above at the application layer.

On top of this, Prisma is language agnostic. All we need to do it come up with “GraphQL bindings” in the corresponding language. “What are GraphQL bindings?” is a question answered very well in this post.

Setup

Let us start with baby steps, installation first.

npm install -g prisma

This should give you a globally installed prisma command (can be installed via npm in a scoped way as well). Help available at prisma help or prisma help <command>.

You will also need to install docker, docker-compose, and node for the setup to work.

Prisma init Command Breakdown

Now we can use the prisma init command to get started. Run the command, go go go… did you do it yet. Let us explore the options it provides:

divyendusingh [prisma-examples]$ prisma init

? How to set up a new Prisma service? (Use arrow keys)

❯ Minimal setup: database-only
  GraphQL server/fullstack boilerplate (recommended)

Let us go with the recommended option in this step.

Running $ graphql create ...
? Directory for new GraphQL project (.)

It is running a CLI command called graphql — Wait what? — Remember your training (read as GraphQL Ecosystem — GraphQL CLI) soldier.

Straight from the docs: 📟 graphql-cli is a command line tool for common GraphQL development workflows.

Knowing this is helpful, prisma for many operations uses underlying graphql command.

We can specify the directory and move on, note that if you choose the current directory (via .), it must be empty.

The next question it asks you is to choose a boilerplate:

? Choose GraphQL boilerplate project:
  node-basic Basic GraphQL server (incl. database)
❯ node-advanced GraphQL server (incl. database & authentication)
  typescript-basic Basic GraphQL server (incl. database)
  typescript-advanced GraphQL server (incl. database & authentication)
  react-fullstack-basic React app + GraphQL server (incl. database )

Let us go with node-advanced. Although, you can go with whatever you feel like, concepts won’t vary much.

We will notice the it gets the boilerplate(s) from a specific repository.

? Choose GraphQL boilerplate project: node-advanced GraphQL server (incl. database & authentication)
[graphql create] Downloading boilerplate from https://github.com/graphql-boilerplates/node-graphql-server/archive/master.zip...

Which brings us to the next question. Can you create your own boilerplates? Absolutely!! — ping me or join the community if you want to explore this further.

Moving on to the next question:

? Please choose the cluster you want to deploy "deep-dive@dev" to (Use arrow keys)

❯ prisma-eu1 Public development cluster (hosted in EU on Prisma Cloud)
  prisma-us1 Public development cluster (hosted in US on Prisma Cloud)
  local Local cluster (requires Docker)

Log in or create new account on Prisma Cloud

Note: When not logged in, service deployments to Prisma Cloud expire after 7 days.
  You can learn more about deployment in the docs: http://bit.ly/prisma-graphql-deployment

The CLI prompts you to select a cluster to which your Prisma service should be deployed. At the time of writing, there are two public clusters, however, we will use the local cluster (docker based) for this post. Again, feel free to choose any — concepts don’t change much.

Aha! Selecting a cluster runs a few more commands, here is the output printed by the CLI:

? Please choose the cluster you want to deploy "deep-dive@dev" to
Added cluster: local to prisma.yml
Creating stage dev for service deep-dive ✔
Deploying service `deep-dive` to stage `dev` on cluster `local` 1.7s

Changes:
... (many changes, not listed for brevity)

Applying changes 3.8s

Hooks:
Importing seed dataset from `seed.graphql` 733ms

Your GraphQL database endpoint is live:

HTTP: http://localhost:4466/deep-dive/dev
WS: ws://localhost:4466/deep-dive/dev

Checking, if schema file changed 366ms
Writing database schema to `src/generated/prisma.graphql` 1ms
Running $ graphql prepare...

Next steps:
  1. Change directory: `cd deep-dive`
  2. Start local server and open Playground: `yarn dev`

Let us explore this output, bit by bit.

Deploying service `deep-dive` to stage `dev` on cluster `local` 1.7s

Internally, this is running the prisma deploy command (we will be using this command very often). The three keywords we can see in this line of the output are service , stage , cluster.

Service — A GraphQL endpoint that is mapping requests to an underlying database.
Stage — A service can have multiple stages (think dev, prod etc).
Cluster — A service@stage can be deployed to cluster(s). As mentioned about “local docker” for this post and two shared clusters are available. You can also create your own cluster (say on DigitalOcean) and add that to prisma by using prisma cluster add command. Ping me or join the community if you want to explore this further.

Interestingly, all of this can be set/changed in prisma.yml file. We have one such file via the boilerplate that is being used here.

Changes:
... (many changes, not listed for brevity)

Applying changes 3.8s

The prisma deploy command also takes a diff of the already deployed service (in this case there is none, because we are deploying the service for the first time) and applies the relevant changes.

Hooks:
Importing seed dataset from `seed.graphql` 733ms

Your GraphQL database endpoint is live:

HTTP: http://localhost:4466/deep-dive/dev
WS: ws://localhost:4466/deep-dive/dev

If you want a service to have some initial data, you can use the seed option in prisma.yml file.

As suggested by the output, the Prisma endpoint is live and you have built-in web sockets (GraphQL Subscriptions support, wow! wow!).

Checking, if schema file changed 366ms
Writing database schema to `src/generated/prisma.graphql` 1ms
Running $ graphql prepare...

Aha! Next up is the generated prisma.graphql file, this is essentially the full GraphQL API prisma provides for you based on your datamodel.graphql file. It defines the CRUD operations for the types in datamodel.graphql file.

Again, Prisma is using the underlying graphql prepare command which in GraphQL CLI docs is described as following :—

graphql prepare Bundle schemas and generate bindings

More on this later in the post — This is very important.

Lastly, the output suggests you to cd into the directory cd deep-dive. Let us do that and explore the directory structure before running yarn dev command.

Directory Structure

divyendusingh [deep-dive]$ tree -I node_modules
.
├── README.md
├── database
│ ├── datamodel.graphql
│ ├── prisma.yml
│ └── seed.graphql
├── package.json
├── src
│ ├── generated
│ │ └── prisma.graphql
│ ├── index.js
│ ├── resolvers
│ │ ├── AuthPayload.js
│ │ ├── Mutation
│ │ │ ├── auth.js
│ │ │ └── post.js
│ │ ├── Query.js
│ │ └── index.js
│ ├── schema.graphql
│ └── utils.js
└── yarn.lock

5 directories, 15 files

Let us explore the most important bits and see how they connect together.

The database folder:

prisma.yml — This is where we define service, stage, cluster and other options.
datamodel.graphql — Define your desired GraphQL types here and refer this file in prisma.yml file.
seed.graphql — As discussed above, initialize your service with some data, this is the file to setup and referred in prisma.yml file.

The src folder:

index.js — This is where we setup the application server (in this case with graphql-yoga but generally flexible) that will sit in front of the prisma service. The setup includes linking graphql-yoga with prisma and all the files in resolver folder are used here, check it out.
schema.graphql — This is GraphQL API of the application server. This is also known as the application schema. Note that prisma gives you a extensive API based on your datamodel.graphql but you can choose to expose a subset/combination of it in whatever shape you want by using this file. This is what makes this whole setup super flexible.
resolvers — Definition of resolvers of Queries and Mutations used by index.js file. But why is “AuthPayload” at top level? — glad that you asked. Here is why!

Run the Application Server

Now, after taking a brief look at the directory structure, we can run the yarn dev command to run the application server. Now, we have the following endpoints available.

http://localhost:4000 — Application server with custom schema that we just explored. This is for the GraphQL API defined by schema.graphql.

http://localhost:4466/deep-dive/dev — Prisma service with generated GraphQL schema, this was setup by initial prisma deploy. This is for the GraphQL API defined by database schema in prisma.graphql (also known as Prisma database schema) file.

GraphQL Playground should be available if you open these links in browser.

Resolvers in application server use the underlying prisma service by using bindings.

Reusing & Composing GraphQL APIs with GraphQL Bindings

Teach a Man How to Fish

Teach a man how to fish — Photo by Nathaniel Shuman on Unsplash

Let us discuss more about the generated prisma.graphql file (which is also known as Prisma database schema) in this section.

This file contains the full API of what prisma offers you against the current state of your datamodel.graphql file. Given this information and the nature of a GraphQL schema.

You can start to explore the potential use of documented and undocumented feature here. I am a strong believer of “code as documentation” and this is what I used when Prisma was in beta and documentation was not up to date (it is in excellent shape now).

For example, for our deployed service so far, you can go to prisma.graphql and search for type Query, type mutation, type Subscription to explore the full exposed potential of this API (note that this information is also available in the GraphQL Playground, remember the ecosystem soldier) and drill down on various input types from there. Doing so, will give you a solid understanding of the API and the undocumented features.

Access the Database

Where is my data?

In this service, it is in a MySQL hosted using Docker but it can be in your own database as well.

To access the database, run the following command

docker exec -it prisma-db mysql -u root --host 127.0.0.1 --port 3306 --password=graphcool

Notice that the password can be either graphcool or prisma by default.

mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| deep-dive@dev |
| graphcool |
| mysql |
| performance_schema |
| sys |
+--------------------+
8 rows in set (0.00 sec)

Notice that our database has the name in the shape of @

mysql> show tables;
+-------------------------+
| Tables_in_deep-dive@dev |
+-------------------------+
| Post |
| User |
| _PostToUser |
| _RelayId |
+-------------------------+
4 rows in set (0.00 sec)

mysql>

And we have tables matching types in our datamodel.graphql file. Prisma did all of this for us. Nice.

Permissions

How do I authenticate requests in this system?

We have two services, the application server and the Prisma service and both will need authentication (and possibly authorization of sorts).

Let’s talk about the Prisma service first, you might have noticed a secret field in prisma.yml file and the same secret again in src/index.js in your application server part of things. As documented here, that secret is used to sign a JWT token that we have to pass to authenticate the requests.

Which is why you need to mention the secret in application server part for it to be able to talk to Prisma service and in playground of Prisma service, you manually need to send HTTP Authorization header as documented.

You might also be interested in the prisma token command. Find out more about it in docs or by typing prisma help token.

Next is the application server part. It is unauthenticated by default and you need to add it yourself like you would do for any node service.

Since, we have installed the node-advanced boilerplate, we have the raw material to do this already.

Check out the src/utils.js file, it mentions how you can get the user id from an in coming JWT token HTTP Authorization header.

Then you can check how the exposed function getUserId is used in query resolvers file at src/resolvers/Query.js to get the user id and fetch drafts for the “logged in” user.

Advanced Queries

The documentation covers the queries and limitations very well but let us use our “Teach a man how to fish” method to explore queries. Dive into the generated prisma.graphql file and search for type Query. You will land on the following.

And you can see the whole Prisma API (WRT to your current deployed datamodel.graphql file) in front of you.

Let us explore the posts field (and related input type PostWhereInput) further: —

Just by looking at this snippet, you understand that you can do AND and OR operations recursively in the where argument. It argument supports filtering by scalar and nested fields.

Similarly, you can explore the input type for orderBy i.e. by searching input PostOrderByInput in the generated prisma.graphql file.

Pagination support is provided by Prisma by providing a relay style connection object. Take a look at the documentation or just look for “connection” in the generated prisma.graphql file.

Limitations are clearly documented in the docs, most notably they are: —

orderBy not available for multiple fields or by related fields.
In the where clause, scalar list filters or JSON filters are not available.
A maximum of 1000 nodes can be returned per pagination field on the public cluster. This limit can be increased on other clusters using the cluster configuration.

Best part is that you can join in the discussion or even write code to make it happen.

Advanced Mutations

Again, the documentation covers this really well but let us stick to use our “Teach a man how to fish” method to explore mutations. Dive into the generated prisma.graphql file and search for type Mutation. You will land on the following.

Let us explore the type User for mutations. We can notice that we have the following methods for mutation of the type User.

We can see that we have the ability to createUser, updateUser, deleteUser, upsertUser, updateManyUsers, and deleteManyUsers.

Not only that if we drill down and explore input UserCreateInput type.

input UserCreateInput {
  email: String!
  password: String!
  name: String!
  posts: PostCreateManyWithoutAuthorInput
}

We can see that we have another input type for creating/connecting posts for a user. Let us explore that by searching for input PostCreateManyWithoutAuthorInput.

input PostCreateManyWithoutAuthorInput {
  create: [PostCreateWithoutAuthorInput!]
  connect: [PostWhereUniqueInput!]
}

We have the following fields available: —

create — To create a post while creating a user
connect — To connect an existing post to this newly created user.

Similarly, we have input PostUpdateManyWithoutAuthorInput in input UserUpdateInput which looks like this: —

input PostUpdateManyWithoutAuthorInput {
  create: [PostCreateWithoutAuthorInput!]
  connect: [PostWhereUniqueInput!]
  disconnect: [PostWhereUniqueInput!]
  delete: [PostWhereUniqueInput!]
  update: [PostUpdateWithoutAuthorInput!]
  upsert: [PostUpsertWithoutAuthorInput!]
}

Here we have more options than in input UserCreateInput and it makes sense intuitively. While creating a user you can only do create and connect but while updating a user you can perform create, connect, disconnect, delete, update, and upsert on a post.

A good though experiment is why can’t we do an upsert while creating a post. Ping me or join the community if you want to explore this further.

Subscriptions

To be honest, I have not used them yet but it is documented here! I will update the post once I use them in production. The purpose of subscriptions is to implement event-based business logic using serverless functions.

Prisma Docs

Export/Import Data

Exporting and importing data is built into the CLI. This can be also used to perform automated backups.

It can be as simple as running prisma export to export the data file.

And prisma import --data <data file path>

I have used this in production and did not face any issues.

Monitoring

Monitoring is another very important aspect of moving a service to production and I am a fan of monitoring in production. GraphQL Yoga has built-in support for tracing. We can also link our service to Apollo engine for production monitoring (and more).

I used this guide to set it up for my application. Please follow it.

Set up Engine with Node | Apollo Engine

Ping me or join the community if you want to explore this further.

Such Wow — Dashboard of Apollo engine setup for https://www.divyendusingh.com powered by DS.

This is how it is looks like (wow, field level performance insights) when setup. I have done it for my personal site which is powered by DS which is powered by Prisma and Next.js.

Advanced Prisma and GraphQL Stuff

Resolver forwarding: —

graphcool/prisma

Deployment best practices: —

Advice on best practise? - Deploying graphql-yoga server w/ Prisma in production

Rest bindings: —

graphql-binding/graphql-binding-openapi

Testing: —

Guillermo Rauch

@rauchg

Write tests. Not too many. Mostly integration.

16:43 PM - 10 Dec 2016

Testing a GraphQL Server using Jest

Examples: —

graphcool/prisma

Gotchas

Public shared clusters have a limit of 1 request per second. Soon™ to be increased to 10 requests per 10 seconds.
There might still be a connection leak in subscriptions connection.
The # import on top of your schema.graphql is not a comment but a graphql-import.

Plugs

And that is all for this post, it was a great experience working on this. If you like my work and would like to subscribe to interesting future posts, please subscribe below.

https://medium.com/media/e9d4dcab1161d9df16e59865831303d1/href

You can also find me here.

Thanks to Nikolas and Nilan (legend says he is Master Yoga) from Graphcool team for detailed feedback on this post.

Learning GraphQL with React and Relay - Video

Divyendu Singh — Fri, 08 Dec 2017 17:40:29 +0000

Hello! So, I have been cooking this course for the last two months and finally, it is ready!

Tadaaa! - Learning GraphQL with React and Relay [Video]

I have put a ton of effort in this one, we will be covering the following:-

Understand the working of a GraphQL server in a language agnostic way
Use React and Relay with GraphQL backend
Create your own GraphQL API with a blog
Test a client and GraphQL backend
Implementing scaling/pagination for a GraphQL API coupled with Relay client
Write test cases for backend and frontend (Bonus: React Storybooks)

I will also be posting a ton of content on a site I have been cooking - GraphQL.in

CodeSandbox — React Scraping Protection

Divyendu Singh — Thu, 30 Nov 2017 20:29:10 +0000

TL;DR; This is a fanboy post for CodeSandbox!

Introduction

One of the primary aims of CodeSandbox was to provide a completely native offline development experience in the browser and I just wrote a small component and made a Github repository out of it, all in CodeSandBox.

I just gave it a go and it looks pretty solid to me. This is an embed of the component (again using, yes, you guessed it! CodeSandbox):-

https://medium.com/media/ec59550d7c5be9ce0bd95e1922ef6f55/href

I also changed the underlying repository name and CodeSandbox was able to take care of that.

Notable things:-

All commits were made through CodeSandbox.
The Github integration (albeit, in beta) looks solid.
It has an integration for deploying to Now!
Monaco editor (based on VSCode) is sleek and provides a solid — offline like experience with auto-complete and click-to-jump functionality.
Integration with Medium (the above link is a CodeSandbox link pasted into Medium).
Ability to add npm modules through a web interface.

Component — ReactScrapingProtection

The component itself is pretty basic. The aim is to be able to render strings lazily for it to be protected from bot scraping.

Of course, this applies less to client side only apps, albeit, it is widely belived that Google can understand Javascript.

This component is made for situation when React components are being rendered on the server side with frameworks like next.js.

I have not tested the component yet in SSR environment (both locally and in production)! I was just playing around with CodeSanbox and the API might change.

That’s all for now! Happy coding!

A Comprehensive Guide to Google Cloud Functions

Divyendu Singh — Sun, 27 Aug 2017 09:11:53 +0000

Introduction

Cloud Functions allow us to write business logic without provisioning any infrastructure. In this post, we will talk about the flavors of cloud functions available at our disposal, limitations, development/deployment workflow, local development with cloud functions emulator and code.

Google describes Cloud Functions as following: –

Google Cloud Functions is a lightweight, event-based, asynchronous compute solution that allows you to create small, single-purpose functions that respond to cloud events without the need to manage a server or a runtime environment

Without further ado, let’s dive in.

Cloud Functions Runtime and Dependencies

Cloud Function are modules written in Javascript and run in a Node runtime. The Cloud Functions execution environment follows the Node “LTS” releases, the current Node version running in Cloud Functions is Node v6.11.1.

For dependencies, there is only good news as you can use the powers of npm and package.json

P.S. when deploying from local machine as we will see further in this post, you can deploy configuration files/credential keys for access (not advised to version control the credential keys though). Use Google Cloud Deployment Manager for provisioning configuration.

Types of Cloud Functions

Google Cloud Functions come in two flavors: –

Foreground (HTTP) Functions

These functions get an HTTP URL to be invoked from out in the wild. Like the one below, check it out.

https://us-central1-divu-178107.cloudfunctions.net/hello-world

Writing an HTTP Cloud Function is pretty straight forward, you export a function with the request, response arguments (like express). This is how the code for the above function looks like: –

Background Functions

This flavor of Cloud Functions allows us to handle events from our cloud infrastructure, such as listening to messages on a Pub/Sub topic or changes in a Google Cloud Storage bucket. Suppose you want to write a cloud function that resizes images to different variations on upload to Google Cloud Storage. That function would look something like this.

Important note from the docs.

Note: You should always either invoke the callback argument, or return a Promise when your function has completed. Otherwise, your function may continue to run and be forcibly terminated by the system.

Also, refer to the docs for details on event parameters and more information on the callback.

How to create Foreground (HTTP), Background Function

You get to choose the type of function you want to create while creating a Cloud Function via choosing a trigger and this is how you choose between creating different types of functions.

Choose trigger while creating a CloudÂ Function

The same can be done from command line as well using gcloud utility as follows: –

gcloud beta functions deploy <function-name> --stage-bucket <bucket-to-store-the-function-to> --trigger-http # Deploy HTTP function

gcloud beta functions deploy <function-name> --stage-bucket <bucket-to-store-the-function-to> --trigger-bucket=<bucket-on-which-we-want-to-listen-events> # Deploy background function

You can also call functions from command line to test them as follows: –

functions call <function-name> --data='{"message":"Hello World"}' # HTTP function

functions call <function-name> --data='{"name":"<file-name-that-fake-triggered-this-event>","bucket":"<bucket-name-that-fake-triggered-this-event>"}' # Background function

Lastly, cloud functions have quotas that we should be aware of.

Meta information about cloud functions

I added this as a bonus in this section because I feel this is important. You have access to /tmp to store temporary files according to the docs.

Local Disk

Cloud Functions provides access to a local disk mount point (/tmp) which is known as a "tmpfs" volume in which data written to the volume is stored in memory. There is no specific fee associated with this however writing data to the /tmp mountpoint will consume memory resources provisioned for the function.

This is really handy if you want to process files and need a temporary storage before putting it in Google Cloud Storage bucket.

Also, to upload files, you need to convert them to base64 encoded strings (I could not find ability to upload files otherwise in docs, please correct me if I am wrong). Cloud Functions use body-parser and hence the limitation.

Description of parsing done by HTTP functions

Ending the meta information section with this nice blog post, that talks about sharing functions between Google Cloud and Express.

Development and Deployment Workflow

While it is possible to write cloud functions from the google developer console, deploy it and test it from there, it would make for a terrible developer experience as a cloud function may take up to 2 minutes to deploy.

Enter Cloud Functions Emulator, whilst still in alpha at the time of this writing, it is a great tool that helped me a ton while working with Cloud Functions. You can install the emulator using the following command.

yarn global add @google-cloud/functions-emulator

Once setup, the emulator can be used with functions command. Here is a list of commands (not exhaustive) available at your disposal.

functions --help
functions <command> --help
functions start
functions stop
functions kill
functions deploy helloWorld --trigger-http
functions call helloWorld --data='{"message":"Hello World"}'
functions list
functions status
functions debug <function-name>
functions inspect <function-name>

Notice how closely the functions emulator follows the syntax of gcloud command to deploy and call functions. This caters for an amazing development experience as now you can write, test, automate-tests for your functions locally and version control them before actual deployment.

You can also deploy Cloud Function directly from source control.

Next steps

Play around with Google Cloud Function for fun and glory and jump to serverless frameworks for writing production grade code.

Serverless - The Serverless Application Framework powered by AWS Lambda and API Gateway

And that’s all for this post, I would really appreciate feedback via comments or twitter and claps.

https://medium.com/media/e9d4dcab1161d9df16e59865831303d1/href

DEV Community: Divyendu Singh

CLI editor in Typescript

How does a software like full story or session stack work?

Anyone here doing crazy stuff with Ableton and Javascript (or something else)

Prisma — Deep Dive

Cloud Native — GraphQL — Database API Layer

Table of Contents

Introduction

What is Prisma?

Where does Prisma sit in my setup?

Setup

Prisma init Command Breakdown

Directory Structure

Run the Application Server

Teach a Man How to Fish

Access the Database

Permissions

Advanced Queries

Advanced Mutations

Subscriptions

Export/Import Data

Monitoring

Advanced Prisma and GraphQL Stuff

Gotchas

Plugs

Further Reading

Learning GraphQL with React and Relay - Video

CodeSandbox — React Scraping Protection

TL;DR; This is a fanboy post for CodeSandbox!

Introduction

Component — ReactScrapingProtection

A Comprehensive Guide to Google Cloud Functions

Introduction

Cloud Functions Runtime and Dependencies

Types of Cloud Functions

Foreground (HTTP) Functions

Background Functions

How to create Foreground (HTTP), Background Function

Meta information about cloud functions

Development and Deployment Workflow

Next steps