Forem: Akram Saouri

Using Netlify functions to host a GraphQL API with a React frontend

Akram Saouri — Tue, 15 Oct 2019 20:18:50 +0000

This quick demo assumes you’re already familiar with Netlify as a deployment service, GraphQL as an API technology and React.

The starting point was a normal React project created with create-react-app then deployed on Netlify (you know…the usual)

Then I arrived to the point where I found out I needed an API to do some backend-related stuff, I (innocently) reached out to create a new repository, wrote some GraphQL resolvers/mutations, committed the whole thing but just when I was looking for a cheap vps to host it in, I stopped for a second then said to my self: why not do it on Netlify itself?

Narrator: he did not regret it.

The process was as straightforward as this:

I’ve started by completely moving the backend files from their separate repo to inside src/ folder in the frontend repo:
Then I’ve added netlify-lambda as a dev dependency to the project; this is a tool created by the netlify team and provides a runtime for lambda functions.

I did not have a netlify.toml file at the time so I created one, and updated the content with this:

[build]
  command = "yarn build" # the command you run to build this file
  functions = "built-lambda" # netlify-lambda builds to this folder AND Netlify reads functions from here
  publish = "build" # create-react-app builds to this folder, Netlify should serve all these files statically

// This helps the `netfliy-lambda` do its job and helps Netlify figuring out where to look for your functions when deployed. 
// Note: the `functions` field will probably be different in your project depending on where you decided to put the GraphQL functions

The I’ve added two new scripts to my package.json:

- ”start:lambda”:”netlify-lambda serve src/lambda”

- ”build:lambda”:”netlify-lambda build src/lambda”

before going all lambda crazy, the backend repository was using a normal apollo-server but now I needed to find a lambda compatible one, luckily apollo-server-lambda does exactly this and barely required any changes on the existing files, the graphql.js looked like this:

    const { ApolloServer } = require('apollo-server-lambda');

    const { typeDefs } = require('./lib/typeDefs');
    const { resolvers } =require('./lib/resolvers');

    const lambda = newApolloServer({
      typeDefs,
      resolvers,
      playground: true,
      introspection: true
    );

    exports.handler = lambda.createHandler({
      cors: {
        origin: '*',
        credentials: true
      }
    });

The last piece now was to wire the GraphQl client with the Netlify function:

On the frontend, I’m working with urql so I had to update the client initialisation to this:

  const client = createClient({
    url: process.env.NODE_ENV === 'development'
       ? 'http://localhost:9000/.netlify/functions/graphql'
       : '/.netlify/functions/graphql'
   })

The http://localhost:9000/.netlify/functions/graphql URL is the default one when running npm run start:lambda locally but when deploying to Netlify the functions are hosted on the same domain hence the check.

Note: This code is still valid for your favorite GraphQL client too.

Now once I published these new changes to Netlify, it detected that I’ve added a new function and did its magic:

Couple of notes

When working with databases, the standard approach of starting the database with the server does not work in this case since the lambda function is given a limited time to run on every request and will be shut down after the request is resolved, the solution is to open a database connection on every incoming request and cache it the between requests. I was able to do that (with mongdb in my case) using something like:

    let cachedDb
    if(cachedDb && cachedDb.serverConfig.isConnected()){
        context.db = cachedDb;
    } else {
        context.db = await connectDB();
        cachedDb = context.db;
    }

You can simulate a full working Netlify runtime locally using their Netlify Dev | Netlify tool, this comes handy when you want to debug you full wired app locally.

Relevant Links

Docs for Netlify functions: https://www.netlify.com/docs/functions/
Netlify lambda: https://github.com/netlify/netlify-lambda
Apollo server lambda: apollo-server/packages/apollo-server-lambda at master · apollographql/apollo-server
Netlify dev: Netlify Dev | Netlify

Common gotchas when working with Electron.js

Akram Saouri — Sun, 31 Mar 2019 18:58:19 +0000

Common gotchas when working with Electron.js

So I had the chance to play with Electron.js past weeks building dummy applications and wanted to share my small experience with it when building cross platform desktop apps.

Architecture

An Electron application has two processes:

The main process: there is always one and only one main process per application responsible for creating web pages, picture it like a server-client architecture with the main process being the server in this case.
The render process: representing the web pages (client) created by the main process and running on chromium multi-process architecture.

I recommend the official doc for reading in-depth about the architecture.

IPC

IPC (Short for Inter Process Communication) is a protocol used on Electron apps for enabling communication between its processes (Main and Renderer)
Electron makes this possible by providing two modules: ipcMain for the main process and ipcRenderer for the renderer process(es), both these modules are based on EventEmitter and provide functions for listening on and emitting events.

A basic example for pinging a renderer process from a main process and listening for a response can be like the following:

// in the main process
const { ipcMain } = require('electron')
myWindow.webContents.send('event_from_main', 'ping_from_main')
ipcMain.on('event_from_renderer', (event, arg) => {
  console.log(arg) // ping_from_renderer
    // we can use event.sender.send to reply to event 
})

// in the renderer process
const { ipcRenderer } = require('electron')
ipcRenderer.on('event_from_main', (event, arg) => {
    console.log(arg) // ping_from_main
    ipcRenderer.send('event_from_renderer', 'ping_from_render')
})

Data persistence

Electron.js as a framework isn’t opinionated when it comes to how to store your data, it’s up to you and your needs to choose a database, be it either a local one (localStorage, indexedDB) or go big like Postgres or MongoDB (in general as long as there is a Node.js adapter for it, you’re welcome to use it)
I personally always find my self reaching out for lowdb) in small or prototype projects since it’s easy to use (lodash syntax like) and really gives you the flexibility afterwards to migrate to something bigger once you figure out what you really need.

UI and Styles

Unlike other desktop apps toolkits, views/pages in an electron application are just regular html files, this means you can bring your favorite styling friends to the party (sass, less, css grid, svgs etc…)
Also there are some boilerplates out there for using React, Vue and other UI libs with Electron.

Bonus:

@sindresorhus built tons of utilities that can help your development workflows with Electron, my favourite ones are electron-util, run-electron and electron-context-menu.
Also to package and build your application, I recommend electron-builder

Web Assembly

Akram Saouri — Sun, 01 Jul 2018 13:43:09 +0000

Web Assembly, the what, the why and the how

The what

Web assembly also called Wasm is an efficient, low level byte code for the web, the efficient part means that it’s not only fast to deliver to the client browser but also fast to execute, it’s characterised by being a safe and a portable language meaning that you won’t have to deal with memory overflows and issues like that and the generated machine code can be executed on any platform and adapts to its architecture.

The why

W3C created Wasm for two major reasons, the first one as a complementary solution to JavaScript especially for applications with heavily CPU/GPU computations (think games, encryption, image or video optimisation and editing etc..), and the second one is to enable developers to write their web apps in other languages.

The how

Wasm is defined as a compilation target meaning that in a normal scenario you would write your program in some other languages (currently supporting C/C++ and Rust) and then compile it to a web assembly executable file.
The generated binary file can be injected to your web application and the browser parsing the file will skip all the steps usually run when parsing JS files and go straight to generating the machine code for the platform you’re using, and this is happening because Wasm is already optimised and has static types informations.

Getting started

To play around with Wasm, I recommend https://webassembly.studio/ which is an awesome web editor allowing devs to experiment with Wasm and write web assembly based projects.
There is also https://mbebenita.github.io/WasmExplorer/ which is basically a tool used to translate C/C++ code to Wasm binary code and even see the linear assembly byte-code generated by the browser (this is basically the human readable intermediary representation for the machine code)