A fast, declarative framework for writing web servers, no taradiddles.

Bliz supports HTTP servers, real time servers with Socket.io and GraphQL servers with remote schema stitching.

The Problem

At first, I wanted to understand how popular web server frameworks like express.js and koa.js work and in the process, I realized I could create something that will make writing web servers in my company and for myself a bit easier, especially with Graphql. If you sometime worked at a company with > 500 people, you know it is tough to incorporate new ideas, architecture styles and languages, because, frankly, nobody has the time, so I thought, why not wrap Node’s native http module, socket.io and graphql-tools to something declarative and easy to use, so that people will not be frightened when they see it and I could somehow push our company to even better practices and somewhat similar codebase.

The Solution

Bliz.js is a framework that allows you to create an HTTP/Socket.io/GraphQL servers in no time and with no extra dependencies.

Rather than dealing with why you should use this or that package, you can focus on writing your server and Bliz will take care of bootstrapping and creating everything for you behind the scenes. All this is wrapped inside chainable functions and a coding style which enforces modularity.

What this library is not:

It is in its diapers (version 0.2.0), so I do not recommend using it in production until version 1.0.0 is released (I hope that it will happen soon). Support will be appreciated! It does not have a render engine or anything like that, it is purely for creating Restful/realtime/graphql API’s. Maybe it will change in the future.

Lets jump in and see a few examples of a GraphQL server. Note that you have to understand how GraphQL works in order to use Bliz. You can read more about GraphQL here. For examples on Bliz’s http/socket.io servers checkout the README at Github.

We will create a simple food delivery fetcher graphql API with subscriptions and mutations. Our delivery fetcher will be divided by floors. Here is an overview of the flow

The structure will look like this

folder structure

Our Schema.js has a Restaurant type with a few fields.

schema.js

We define our schema like a regular GraphQL schema, do not mind the rewrite directive, as soon as the docs will be ready, there will be a good example on how to add them to your project.

resolver.js

Our Resolvers.js file has the standard Query that returns the restaurants by floor we pass. The restaurant object has its field resolvers, in case you need custom field formatting and finally we have Mutation and Subscription.

Notice Bliz injects pubsub and withFilter helper functions to Mutation and Subscription. The pubsub injected is a local event emitter, though you can add your own pubsub implementation like Redis pubsub, as long as it implements AsyncIterator.

We simply publish an event on mutation and subscribe to it in Subscription, that’s it :)

restaurant index.js

Our Restaurant-index.js combines our schema and resolvers, notice how we pass our main app to it. This style of writing keeps all your code modular and more testable.

We declare our query, mutation and subscription here. This way we know what schema we use, what resolver and what to expect when dealing with Restaurant in our API.

main index.js

Our main index.js simply creates a new Bliz instance through a factory function. Notice we chain prettyPrint() — which is a function that prints all your web socket events if you have any registered and all http routes if you have an http server. Bliz has a lot of these options and configurations available, everything will be in the documentation as soon as its finished.

We register our restaurant schema and we have a graphql server up and running on port 4000 with graphiql playground and ws://localhost:4000/subscriptions for some real time goodness automatically.

Micro-services with Bliz

Bliz allows you to create micro services like the restaurant service above in no time, this is possible thanks to GraphQL schema stitching behind the scenes. Let’s see how we create a gateway to combine all these micro-services to one.

Let’s say we have 2 services running, how can we query both of them and abstract it away from the client ? We simply call Bliz’s registerRemoteGraphQlSchemas.

Now everything you have on both services will be passed through the gateway, including subscriptions.

Conclusion

We had people writing different software with different styles and packages. Later we saw Bliz allows creating all kinds of API’s in a small amount of time, without dependencies and without much code. All the latter are critical for people to quickly start writing software and I hope Bliz will help create easier and more maintainable API’s.

P.S.

There are a lot of tests to write, documentation to create, changes to make and projects to build with Bliz. All contributions will be welcomed and I hope we can create something amazing together. Feel free to clone the project and submit your pull requests with fixes/ideas/features.