Forem: Ivo Meißner

Announcing Slicknode Open-Source: GraphQL Framework + Headless CMS

Ivo Meißner — Wed, 13 Oct 2021 15:59:51 +0000

I have big news to share: I am releasing Slicknode, the GraphQL application framework + headless CMS, as Open-Source-Software!

This gives developers and digital agencies a free, more efficient, and open way for building custom digital solutions that usually require the budget for custom software development or enterprise licenses.

Watch how Slicknode makes web developers a lot more productive in this 3 min demo

Why Slicknode?

The web has evolved significantly in the last 15 years. We now have AI-powered content delivered to users across the globe, real-time communication with video, VR, and countless SaaS providers that offer functionality for every use-case imaginable. Sadly, a lot of these capabilities are not as accessible to developers as they could be. The development of such solutions happens in silos, in separate companies doing redundant work. Using and combining multiple of those functionalities requires significant integration effort and deep knowledge of the integrated system. Extending a 3rd party SaaS offering is very hard or impossible. You almost always have to create a custom backend to create something innovative. Unfortunate for countless businesses, people, and organizations that could benefit tremendously from such solutions, this is out of budget in a lot of cases.

Projects either settle for sub-optimal compromises or spend way more than they would like on a custom backend. You could circumvent the development process by using one of the page builders that come with a tempting price tag but have severe limitations and hard vendor lock-in.

Those barriers inhibit innovation. We see the result of that all over the internet: Boring websites that all look the same and do the same thing. People then spend the majority of their time on the websites of tech giants instead of on the websites of their local stores, communities, and people they see in real life.

Let's fix this with open-source software! I want to help developers create an internet where the best ideas win, not the biggest budgets. I want to enable every developer to create innovative solutions that can compete at the highest levels. But to accomplish this, we need a new approach for how we build digital solutions.

Headless Functionality

We need to free the functionality from the silos of corporations and make them easily accessible to anyone, ready to use, extend and combine. We need to decouple the functionality from the presentation layer. It gives us the flexibility we need to use any frontend framework and create solutions for any device. Headless CMSes have done this successfully in recent years, but they are mostly still limited to content. If we want to combine the functionality of multiple services, we still have to do the integration manually in the frontend, which adds complexity (error + loading states, handling authentication, etc.).

Slicknode eliminates this integration effort by applying the headless concept to any functionality you could imagine. The workflow becomes extremely simple with a modular architecture: You compose your custom backend with existing modules, 3rd party APIs, and your internal services into a unified data graph.

Need certain functionality in your project?
Just install the module - Done!

What if there is no module available for what I need?
Simply create a new one in minutes using the flexible building blocks that Slicknode provides and share it with the web developer community.

This dramatically reduces the amount of knowledge you need to build complex solutions. For example, you don't have to be a Shopify developer anymore to add eCommerce functionality to your website. You can simply install an existing module or embed an API with minimal effort.

Slicknode brings the power of all the APIs in the world right into your user interfaces. You can mix and match functionality from multiple service providers, extend their functionality with ease, and build solutions on top of the GraphQL API. You can enjoy the freedom to use any tools, programming languages, and frameworks you know and love without giving up control.

The Vision

The purpose of Slicknode is to provide a platform that empowers developers to build better solutions in less time. In 10 years, I want to look at the web and think: "There is no way I could have built those solutions with the tools from 10 years ago!"

I want Slicknode to be the platform where developers can share ideas and solutions to existing and future problems. A collaborative and welcome community where we can help each other build the next generation of the internet.

I invite all web developers to become a part of this. Share Slicknode far and wide, invite your friends and co-workers and start building great digital solutions. Let's make this the best, most friendly, and welcoming Open-Source community that empowers developers worldwide!

Where Do I Start?

The best place to start is the quickstart guide and the Github repository. Create your first project in minutes and start hacking. I will also be publishing more and more examples in the Slicknode YouTube channel and on Twitter.

I'm looking forward to working with all of you and making the world a better place through collaboration and open-source software!

Best,
Ivo Meißner
Creator of Slicknode

To GraphQL or not to GraphQL? Pros and Cons

Ivo Meißner — Mon, 13 Sep 2021 15:45:20 +0000

So you want to know if GraphQL is a great fit for your project? Using GraphQL can be a consequential decision, for better or worse. If you have never used GraphQL in a complex project, how are you supposed to know if you are going to regret it later or celebrate yourself for making the right call?

It can be hard to see through all the hype articles like "GraphQL is the successor of REST" or "GraphQL is overkill for most projects" and understanding what GraphQL would mean for your particular project. I want to save you some trouble with this post and put everything I have learned about GraphQL in the past years into one blog post that can help you make a more informed decision.

Can you trust my opinion? Maybe, always make your own judgment! For reference, here are a few things I have worked on in the GraphQL ecosystem:

I have built thousands of GraphQL APIs in the process of creating Slicknode, a framework and headless CMS to rapidly create GraphQL APIs
I have written graphql-query-complexity the most popular open-source library to secure GraphQL servers written in NodeJS against DoS attacks. It is also used by some of the big open-source frameworks like TypeGraphQL and NestJS
I have migrated a 12-year-old codebase to GraphQL
I have ported a library to create Relay compatible GraphQL APIs from JavaScript to PHP
I have removed GraphQL from a service where it turned out to be not a great fit

So keep in mind that I am a huge GraphQL fan, but I'll try my best to talk about the tradeoffs as well.

Is GraphQL Just A Hype?

At this point, it is probably safe to say that GraphQL is here to stay. In the years following its open-source release in 2015, it has gained an incredible amount of traction. It has been adopted by a large number of fortune 500 companies, and those applications don't tend to disappear overnight.

GraphQL has also sparked the interest of investors: Businesses that build products around GraphQL have raised hundreds of millions of dollars in venture capital.

There are now GraphQL clients and servers in all major programming languages available and the GraphQL library for Javascript alone has currently 5.5 million weekly downloads. The tooling around GraphQL has been a joy to work with and gives you a lot of options to get creative and solve real-world problems.

What is GraphQL?

The official website describes GraphQL as "A query language for your API". The process is explained as "Describe your data ➜ Ask for what you want ➜ Get predictable results".

I like to think of it as the SQL for APIs. When you work with SQL, you can write your SQL query in a declarative way, describe what data you want to load or change, and then let the SQL server figure out the best way to perform the actual operation. You don't care what is happening under the hood, like which blocks are read from disk, caches, or networks, this is all nicely hidden from you. When there is a new release of your SQL server available, you can safely update the database and profit from all the performance improvements, etc. without having to update a single SQL query in your codebase. If there were new features added, you can use those features in new parts of your application, but you don't have to update existing parts of your application, as the old queries will still work the same.

This is very similar to how GraphQL works, only for APIs: You write a GraphQL query in a declarative way, send it to your server, and the server figures out the best way to load that data. It is then returned in the exact format that you specified in your query. Now, if you need different data, you just change the query, NOT the server! This gives API consumers unprecedented powers. You can send any valid query to your GraphQL server, and it will on-demand return the correct response. It's like having unlimited REST API endpoints without changing a single line of code in your backend.

A good analogy: When REST is like ordering a la carte in a restaurant, GraphQL is the all-you-can-eat buffet. You can mix and match any dish that is served at the buffet on a single plate and take as much or as little as you want. With REST, the dish always has the same portion size, you first have to ask the waiter if they could combine multiple dishes, they have to check back with the kitchen and might come back telling you that they don't do that, thinking you are an annoying customer for not respecting their menu.

Also, when you want to add new capabilities to your GraphQL server, you just add more fields and types to your schema. All the existing GraphQL queries in your client applications keep working without requiring any changes. This enables you to evolve your APIs and client applications independently, but we will look at that in more detail later.

If you are not that familiar with GraphQL yet, I recommend checking out the introduction on the official GraphQL website, so you can see some GraphQL queries and schema definitions in action.

Why GraphQL?

So why was GraphQL created in the first place and what problems was it supposed to solve?

GraphQL was initially created at Facebook to solve some major challenges with the API communication between the servers and their plethora of client applications for all kinds of device sizes, operating systems, web apps, etc. As you can imagine, evolving APIs at that scale is extremely hard, especially if you are using a REST-style architecture.

There is a documentary about GraphQL where the GraphQL creators and other early adoptors talk about why they created and adopted GraphQL.

Let's look at the most important reasons in some more detail.

Overfetching

A problem with REST APIs is that you have a predefined response format that is pretty inflexible. One URL always returns the requested resource in its entirety. Sure, there are ways to mitigate that problem like passing the fields to include in the response via parameters, etc., but this is not standardized, therefore needs documentation and it has to be implemented in the backend, which adds unnecessary complexity.

This can become a problem over time, especially as you evolve your API and add new features or deprecate obsolete data.

For example: Let's say you want to add a new field to your user object with the current online status to the REST endpoint of the user:

GET https://example.com/users/2
{
  "username": "ivo"
}

You could simply add the field to the response, which then becomes:

{
  "username": "ivo",
  "isOnline": true
}

This is great and works. However, the problem with this approach is that now the online status is sent to every single client application even if they don't need it. Do this a few times and you end up with bloated, mostly useless responses that you send to every client, consuming their bandwidth and making your application slower over time.

Underfetching

Another challenge you might be familiar with when building rich user interfaces is something called underfetching: You don't get all the data you need to display in a single API request and have to call the API again to load related data. This adds additional server roundtrips, increases the latency, and can lead to poor user experience.

Let's look at a very simple example: Say you want to create the backend for a blog post detail page where you want to display the following data:

{
  "post": {
    "title": "GraphQL is awesome!",
    "text": "GraphQL solves so many problems...",
    "author": {
      "name": "Ivo"
    },
    "comments": [
      {
        "text": "100% !!!",
        "author": {
          "name": "John"
        }
      },
      {
        "text": "Couldn't agree more",
        "author": {
          "name": "Jane"
        }
      }
    ]
  }
}

When you want to implement that with REST, you have to ask a few questions:
Do you include the author in the response data of the post?

Why not put it in a dedicated /user/23 API resource to avoid redundancy and only return a reference in the post response?
What about comments? Do you return them as well?
What about the author of the comments?
Where does it end?

To keep it DRY you might implement the response like this:

{
  "post": {
    "title": "GraphQL is awesome!",
    "text": "GraphQL solves so many problems...",
    "author": "/user/1",
    "comments": "/comments?post=345"
  }
}

When the client gets this response, it does not contain all the data that we need. We have to make additional requests to fetch the author and the comments, which adds additional latency. We could create a custom API endpoint where we return the data exactly in the shape that we need. But that might add redundancy in our backend and make the API less flexible (a mobile application might not want to load the comments initially).

GraphQL eliminates this problem by giving frontend developers the ability to request exactly the data that they need on-demand and let the GraphQL server do the heavy lifting of loading (or not loading) references automatically.

Feature Deprecation

As your project evolves and requirements change, you might want to deprecate a feature and remove it from your API to not have to maintain obsolete or redundant services. This can be a major challenge with a REST architecture, especially in more complex projects. Do you release a new version for every feature that is removed? How do you make sure a removed feature is not still in use by some client application? When can you shut down the old API versions?

In a lot of cases, it is easier and cheaper to just keep the old feature in place than to go through the significant engineering effort of implementing a solid migration strategy. The problem is, you are forcing all this useless data through the bandwidth-limited connections of your users, with no easy way out, or you have to maintain multiple versions of your API.

GraphQL has a built-in way to solve this problem. You can just mark a field as deprecated and add information on how to migrate client applications. This information is available to all client applications in a standardized way, you can run a script in your CI pipeline that automatically checks if deprecated fields are used and migrate your client applications accordingly. As soon as all deprecation notices are fixed in your client applications, you can safely remove the field from your GraphQL API.

The benefits are obvious:

No need to create, run and maintain multiple versions of your API. Just one GraphQL API that evolves with your project over time.
An automated and self-documenting way to manage feature deprecations.

Decoupling Frontend & Backend Development

By introducing GraphQL in a project, you are eliminating an enormous amount of friction by completely decoupling frontend and backend development. Any number of frontend applications can be developed and changed completely independent of the backend. There is no need to create or update a specific REST endpoint for a particular view, the power shifts to the frontend developers as they can just request data on demand.

To get back to the restaurant analogy: The chefs can just place a new dish on the buffet and users can come mix and match it with anything else they pick up when they fill their plate. There is no coordination needed. Compared to the REST style a-la-carte ordering, changing the menu to combine multiple dishes requires coordination with the chef, and possibly other restaurant staff.

As an example of what this can mean in practice: In one project I was working on, a team created an entire mobile application without changing anything in the GraphQL backend.

The GraphQL Killer-Feature

There is one feature of GraphQL that gets way too little attention and is oftentimes not even mentioned in articles examing the pros and cons of GraphQL. In my opinion, this is the killer feature that makes GraphQL invaluable, especially in larger projects. All the GraphQL advantages that we have looked at so far can somehow be worked around, with some ugly compromises to be fair, but nothing was a show stopper. However, I am not aware of any widely adopted technology that even comes close to how GraphQL solves this particular problem:

Co-Location Of Data Dependencies

Let's look at an example to illustrate the problem. We have a React component somewhere in a codebase where we display the user name:

export function UserName({user}) {
  return (
    <span>{user.username}</span>
  );
}

Now we want to display the online status next to the username. What sounds like a simple task can quickly escalate into a nightmare. It raises all kinds of questions:

Is that online status even available in the user object?
How do you know or find out? Is there documentation available?
If the data is coming from an API, how do you make sure it is included in every single API endpoint that returns the user object for the component?

You need a vast amount of knowledge that is not readily available where you want to implement the feature, and also not necessarily related to the task at hand. For a developer that is new to the codebase, this can be particularly problematic. You might have to identify and change lots of API endpoints and include the online status in all the API responses that include the user object.

This becomes a complete non-issue with GraphQL APIs because you can co-locate your data dependencies with your frontend components using GraphQL fragments:

export const UserNameFragments = {
  user: gql`
    fragment UserName on User {
      username
      #Just add the online status to the fragment here:
      isOnline
    }
  `
}

export function UserName({user}) {
  return (
    <span>{user.username} ({user.isOnline ? "online" : "offline"})</span>
  );
}

You define the data dependencies right in your UI components with GraphQL fragments. The parent components can then include those fragments in their GraphQL queries that load the data, and you have a guarantee that the UserName component receives the online status, no matter where in your application it is located.

This makes it incredibly easy to extend your application no matter how complex it is. You don't have to have any knowledge about the rest of the codebase and can confidently implement a feature without leaving the component. With the right tooling, you even get autocomplete functionality, type validation, and documentation in your IDE.

Performance & Security

With great power comes great attack surface.

By exposing a GraphQL API to the internet, you are giving clients an enormous amount of power that can have big implications with regards to security and performance. Clients have access to all your data and functionality at once, on-demand. This significantly increases your attack surface and can easily be exploited if not considered from the start.

Let's look at a few problematic queries...

Load a ridiculous amount of data:

query LotsOfPosts {
  posts(first: 100000000) {
    title
  }
}

Load deeply nested data that requires millions of DB queries:

query DeeplyNestedData {
  user(id: 2) {
    name
    friends {
      name
      friends {
        name
        friends {
          name
        }
      }
    }
  }
}

Launching a brute force attack in a single request:

mutation BruteForcePassword {
  attempt1: login(email: "victim@example.com", password: "a")
  attempt2: login(email: "victim@example.com", password: "b")
  # ...
  attempt100000: login(email: "victim@example.com", password: "xxxxx")
}

The problem is that those queries are not prevented by commonly available rate limiters. You can send a single request to a GraphQL server that completely overwhelms the servers. To prevent such queries to GraphQL APIs, I wrote graphql-query-complexity, an extensible open-source library that detects such queries and rejects pathological queries before consuming too many resources on the server. You can assign each field a complexity value, and queries that exceed a threshold will be rejected. In Slicknode this protection is added automatically based on the number of nodes that are being returned.

Another common approach is to register an allow-list of queries that are permitted and reject all other queries to the API. This might be more granular and secure than dynamic rules, but it limits the flexibility of your GraphQL API and you have to keep your query registry up to date with all your client applications, which requires additional setup and maintenance.

Optimizing the requests to your internal data stores can be another challenge. The responsibility to optimize the data loading process lies 100% with the GraphQL API and can't easily be offloaded to a CDN or reverse proxy. With a REST API, you have very good control over how many and what database queries are executed, thanks to the limited scope of the REST endpoint. With GraphQL a client can request any number of objects that might have to be loaded from different DB tables. Slicknode automatically combines multiple requested objects into a single database query by analyzing the GraphQL query and generating the SQL query dynamically, but your average ORM is probably not equipped to do that out of the box.

This is also related to the N+1 problem, where nested queries make the number of database requests explode. If you want to learn more about this problem, I recommend this video and checking out dataloader, a library released by Facebook to help with batching queries and solving this problem.

Caching vs GraphQL

Caching is always a hard challenge and that can be especially true for GraphQL servers. A lot of the tools we usually rely on don't work well with GraphQL out of the box.

Take CDNs for example. The most common way to deploy GraphQL APIs is via an HTTP server. You then send your GraphQL requests via a POST request to the API and retrieve your response. The problem is that POST requests are not cached by default in the most common CDNs. You could potentially also send your requests via a GET request, but you will quickly hit the request size limit as GraphQL queries can get huge. If you are using a query allow list, you can send a query ID or hash to the server instead of the full query to get around this limit.

Cache invalidation can also be more challenging with GraphQL APIs. All the queries are usually served via the same URL, so invalidating resources by URL is off the table. Furthermore, one data object can be included in any number of cached responses. One strategy to solve this is to attach cache tags to responses and then later invalidate responses based on those tags instead of URLs. This is the approach that is used in the Slicknode Cloud to cache GraphQL responses around the globe.

A great way to add caching to your GraphQL APIs is to add a layer behind the GraphQL API itself and implement it in front of your data sources. Combine this with the dataloader mentioned in "Performance & Security" and you can fully customize the cache behavior.

Single Point of Failure

One thing to keep in mind is that your GraphQL API becomes your API Gateway replacement as the way to access all your functionality, data, and services. If the GraphQL API goes down, your entire application is offline. This is not that different from a REST architecture, but good to know that the GraphQL API will be a critical part of your infrastructure and treat it accordingly.

Best (and worst) Use-Cases for GraphQL

If you have a hammer, every problem looks like a nail. It is really easy to fall in love with all the benefits that GraphQL provides. It makes your life as a frontend developer so much easier compared to previous technologies. But some types of applications are more suitable for GraphQL than others. I have burnt my fingers too and have removed GraphQL from some parts of an application, while for other applications I would highly recommend it.

In my experience, the best use-case for GraphQL is the purpose it was originally built for: Providing the data and functionality for rich user interfaces. A central place that contains all your data and functionality in one unified GraphQL API, easily accessible for any number of teams, always up to date, and self-documenting. It dramatically reduces the complexity of your frontend code. Where you previously had to implement lots of API calls with all the complexity that asynchronous functionality entails (loading states, error handling, etc.), you can now simply define your data dependencies and let GraphQL take care of the rest. You can validate all your API calls at build time and implement solutions with end-to-end type safety. Even though GraphQL is awesome to use as a single developer, the bigger your application and team become, the more you'll enjoy working with GraphQL.

So when should you consider alternatives to GraphQL? I would consider alternatives for applications where you want to physically separate different services. GraphQL is great for combining a lot of functionality in one place. This might be a problem if you want to isolate certain services for example at the network or hardware level and only make them accessible to a subset of services. You might be better off looking at other architectures.

Conclusion

GraphQL is an awesome addition to a developer's toolbelt, especially for powering user interfaces. It is a joy to work with and I am excited to see the GraphQL ecosystem gaining more and more traction. To make it easier for developers to build GraphQL APIs I created Slicknode. It automates all the hard parts and gets you up and running in minutes. Come join the awesome GraphQL community! I also have some pretty big news to share about Slicknode soon, so make sure to follow me on Twitter and subscribe to the newsletter so you'll be the first to know.

How To Build A Media Library With Just 25 Lines of Code - Using GraphQL and Slicknode

Ivo Meißner — Thu, 15 Apr 2021 12:17:42 +0000

Our friends from AXOLIST recently asked us to build a custom media library for their Amazon Content Tool. They wanted to give their users the possibility to upload, manage and update images for their products that they sell on the Amazon marketplace. (Those product images that you see when you shop on Amazon.com)

Background: AXOLIST is a SaaS tool for agencies that help brands sell products on the Amazon marketplace, optimize the content of their product listings for users, search rankings, and ensure compliance.

Now let's see how we added this feature to their Slicknode backend with just a few lines of code.

Requirements

To enable this type of functionality, we had to create a solution with the following requirements:

Since AXOLIST is a SaaS tool, every customer needs to have their own independent media library that can only be accessed by users that are members of that customer account.
Images need to be organized in a hierarchical folder structure to make it easy to manage large product portfolios.
Images will be displayed in multiple resolutions: Thumbnails for the listview, and a high-resolution image for a zoomed-in view.
Users should get a visual warning when they upload an image that has a resolution that is too low for the Amazon marketplace.
Folders can be dragged and dropped into other folders to quickly (re-)organize the media items in an account.
Images can be searched within each folder.
Folders should have unique names within a subfolder.
Soft-delete functionality should allow admins to restore a folder that might have been accidentally deleted.

Creating this from scratch requires a significant amount of time for building API routes, data models, migrations, image processing, authorization, etc. With Slicknode, this becomes a task that is done in 5 minutes. Let's take a look!

Implementation

First, we create the media module using the Slicknode CLI:

slicknode module create media

Then we add the data model to the schema.graphql file:

type Media_Directory implements Node
@index(fields: ["account", "parent", "name"], unique: true)
{
  id: ID!
  account: Account_Account!
  parent: Media_Directory
  name: String!

  children: [Media_Directory!]! @relation(
    path: "Media_Directory=parent.Media_Directory"
  )

  """Date when the directory was deleted, for soft delete"""
  deletedAt: DateTime
}

type Media_Asset implements Node
@index(fields: ["directory", "name"], unique: true)
{
  id: ID!

  name: String!
  directory: Media_Directory!
  account: Account_Account!

  image: Image!
}

With this data model, Slicknode automatically generates the GraphQL API, database tables, and business logic that we need to build our media library. We have the tenant separation to give each account its own media library. The built-in image module of Slicknode takes care of image upload, storage, and thumbnail generation. With the composite unique index, we can ensure that the folder names are unique within each folder and with the relations directive, we create the hierarchic folder structure that scales easily.

To secure the assets and make them only accessible for users of the account, we add a permission query for the directory type.

query DirectoryPermission1($user_id: ID!) {
  scope(role: AUTHENTICATED, operations: [CREATE, UPDATE, READ])
  node(filter: {
    deletedAt: {isNull: true}
    account: {
      users: {
        node: {
          id: { eq: $user_id }
        }
      }
    }
  })
}

We use the permission query to enable multi-tenancy and only allow users of an account to see their own directories. We can also use the same permission query to hide directories that have the deletedAt value set. The filters will automatically be applied by the Slicknode query engine across the entire GraphQL API.

That's it. This is all we have to do to build the backend for our media library. Give it a try for your next project.

Slicknode Content HUB: Headless CMS powered by GraphQL

Ivo Meißner — Mon, 02 Nov 2020 18:04:06 +0000

We have some exciting news to share: After months of hard work, we just launched the new Slicknode that will allow you to build digital experiences with Slicknode better and faster than ever before. The improvements are so profound that they enable an entirely new class of digital solutions that you can build with Slicknode and pretty much change what kind of product Slicknode is.

Here are just a few of the highlights:

Global GraphQL CDN: Content via the Slicknode API will now be delivered via a global content delivery network that allows you to publish your content to millions of users while at the same time dramatically reducing the latency and response times for API requests around the globe. (In some cases < 20 ms)
Internationalization: Slicknode now supports localization of your content as a first-class feature that is fully integrated into the query engine, API, and content editing interface. Create digital solutions for global audiences and enter new markets faster.
Content Preview: There are now two stages for content in your projects, one for editing and previewing drafts and one for the published version. That way, you can make changes and updates to your content without affecting the published version, like agile software development but for content.
Content Workflows: You can set up custom publishing workflows for your content and collaboratively create content with your team. For example, you can start with a draft version and then move it through your workflow: review > translation > legal > published.
Union Types: Slicknode added support for union types. With union types, you can now create extremely flexible content models. For example, you can create a modular page builder that can be used by content editors to create dynamic landing pages without involving IT.
Array Fields: We added support for sortable array fields. While you previously had to create one-to-many and many-to-many fields via a relation, you can now create sortable array fields in which the objects can be sorted via drag and drop in the content editor. This enables a lot of new use-cases, especially in combination with union types.
New Console: The complete layout and design of the console were updated to improve the editing experience and to support all the new content editing features.

Slicknode now has all the building blocks that you need to create a central hub for all your content. And all those features are 100% backward compatible and are immediately available for all existing projects.

Check out the documentation for more details about the features and how to add them to your existing projects.

New Website

To do the major product release justice, we relaunched a new version of our own website, which is now powered by Slicknode itself. This allows us to publish more content faster and keep the website up to date. We now have a modular content builder for building pages and creating an interactive experience to learn about our product.

If you want to build a similar website for your own company, check out our...

Next.js Starter Kit

We created a Next.js starter kit that you can use to quickly set up a website with Slicknode, Next.js, static site generation, etc. in a few seconds.

Check it out on Github

Updated Pricing

With the release of the new Slicknode Content HUB, we also updated and simplified our pricing model. We now have a "Free forever" plan for development, small websites, or experiments, and you can save money by paying annually. Check out the pricing page for details.

Future Direction

This launch marks a significant milestone in the history of Slicknode: When we first started building Slicknode, we set out to create a solution that automates the repetitive work that is still required to create high-quality custom software solutions. We created a general-purpose backend that is up and running in seconds without developers having to worry about setting up infrastructure, databases, running migrations, etc.

Having such a general-purpose solution allowed us to gather valuable feedback from customers for a wide variety of use-cases and see for which solutions they considered Slicknode. We want to thank all of our customers and users for their valuable ideas and feedback, which helps us make the best decisions about how to improve our platform.

The one thing that stands out is that most customers are using Slicknode for content-centric applications. It just made sense to focus most of our efforts on adding essential functionality for managing and distributing content, like adding a global CDN, localization support, and custom content workflows. Since Slicknode was initially built for highly complex applications that go way beyond what you would usually use a CMS for, you now have a platform that has a lot more functionality out of the box than a lot of other content management systems on the market today.

We will continue to improve Slicknode for content management use-cases and would love to hear your feedback and ideas (Join us in our Slack channel).

How To Merge + Extend GraphQL APIs: Slicknode Remote Modules

Ivo Meißner — Fri, 19 Jun 2020 13:52:17 +0000

Slicknode already offers a significant amount of functionality out of the box to build rich applications, however, the reality is that in most organizations and projects there are plenty of IT systems that you want to integrate or extend, both from inside and outside of the organization.

By using those systems, you don't have to reinvent the wheel, however, you still have to spend a significant amount of time with API integrations. For example: Managing credentials for multiple environments, finding documentation, wrapping / transforming the APIs to work within the context of your application, error handling, etc.

We wanted to eliminate this integration effort, which is why we created Slicknode Remote Modules.

Introducing Remote Modules

Remote Modules allow you to merge entire GraphQL APIs into your Slicknode GraphQL APIs with just a few lines of configuration.

The use-cases for this are endless, here are just a few ideas:

Add the Slicknode CMS as the content layer to your core product GraphQL API.
Add your Shopify or Magento eCommerce store to the Slicknode GraphQL API and create landing pages or entire communities for better customer engagement and conversions.
Add customer account information to internal user profile pages.
Integrate payment providers.
etc.

All you have to do is create a module that points to the remote GraphQL API. Slicknode automatically merges the APIs into one unified data graph, taking care of naming conflicts, data fetching logic, and schema generation.

With the merged GraphQL APIs, you can then load data from multiple data sources with a single GraphQL query. This dramatically simplifies the frontend implementation as you only need to configure one GraphQL client. You also have all the data right where you need it: In your UI components.

Extending GraphQL APIs

With the merged schemas in a Slicknode project, it is then possible to create relationships between objects of completely independent systems. This makes creating custom digital experiences on top of existing systems incredibly easy, fast, and fun.

For example: Let's assume you have an eCommerce system where you manage all your products, inventory, pricing, etc.

You then want to create a microsite where you publish rich user testimonials with videos, images, reviews, etc. while at the same time showing the current pricing and product information from the eCommerce system.

With Slicknode, you can simply extend the types of your eCommerce store using the same data modeling tools that you use for internal types: One-to-one, many-to-many, one-to-many relations, etc. Slicknode automatically provisions the database tables, handles authorization, and creates the corresponding resolvers with the data fetching logic.

Here is what a schema for an extension of the Product type could look like:

extend type Product {
  reviews: [Review!]! @relation(
    path: "Product.sku=sku.Review"
  )
}

type Review implements Node {
  id: ID!
  sku: String!
  author: User
  image: Image
  rating: Float
  text: String! @input(type: MARKDOWN)
}

With the relation directive, we can freely connect types of independent systems. Slicknode automatically creates a Relay compatible relation with pagination, filters, sorting and high-performance data fetching logic. In contrast to other schema stitching solutions, Slicknode optimizes the data resolution automatically and fetches all the data of connected types in a single database query.

Check out the documentation to learn how to add other GraphQL APIs to your Slicknode projects.

How to Build GraphQL APIs that Scale, Serverless, in Minutes!

Ivo Meißner — Mon, 27 Apr 2020 21:21:43 +0000

Building high-quality GraphQL APIs is harder than one might think. Building GraphQL APIs that scale is even harder. The flexibility and power of GraphQL comes with its own unique challenges and problems as we have learned the hard way. When we set out to build Slicknode, we wanted to create a platform for building digital solutions in minutes instead of months.

We are finally here!
It has been months in the making and we are so excited to share the results with the world:

We got rid of all our servers and we are running 100% serverless! You can now build advanced GraphQL applications in minutes and never have to worry about scalability and backend infrastructure again.
You just define your data model, add the modules, and 3rd party APIs that you need, and Slicknode automatically launches a production-ready GraphQL API, powered by AWS Lambda and AWS Aurora Serverless.
Learn more...

What's new?

In addition to the massive improvements that come with the infrastructure upgrade, we are also shipping some major new features that enable a whole host of new use-cases and make it even easier to build complex applications and extend Slicknode. We will cover those features in detail
in upcoming blog posts.

Here are a few highlights:

Shareable GraphQL APIs: You can now deploy a GraphQL API directly from a git repository. Just clone it to your local machine and run slicknode deploy. (see an example) Collaborate with the open-source community on a shared backend that can easily be customized (Multi-tenant SaaS-foundation, eCommerce starter, etc.) This is also great for writing frontend tutorials or for creating demo backends.
Remote Modules: Add your existing GraphQL APIs or APIs from 3rd party providers to your Slicknode project with 4 lines of configuration. Want to add your Salesforce data, the Github API, a Magento store, your existing Wordpress blog, etc. to your Graph? Done in 2 minutes. Mode details
Apollo Federation Support: Slicknode now has support for Apollo Federation. If you are using an Apollo Federation architecture in your project, you can add the entire functionality of Slicknode as a microservice to your graph just by installing the module.
Always-On Development Environments: Create development environments in seconds without hassle. The development instances are now always on and don't go to sleep after inactivity any more. More details

Learn about all the features

Why the Relaunch?

Since we launched the first version of Slicknode, a lot has happened. People have used Slicknode to build all kinds of applications, multi-tenant SaaS products, content management infrastructure, small personal projects, and mission-critical business applications. We have also open sourced some components of the Slicknode platform, some of which have been downloaded millions of times and are used in thousands of GraphQL APIs around the globe.

With feedback from countless current and potential customers, we were able to identify two
main issues that led us to make this major upgrade:

Entry-Level Pricing: We wanted to make it free and as easy as possible to get started with Slicknode. The new serverless platform now only incurs cost when it is used and scales automatically. This is a game-changer and we were able to dramatically reduce the entry-level pricing while also offering free development instances.
Dedicated Infrastructure: Enterprise level customers with mission-critical applications need an option to deploy their applications on dedicated infrastructure in their own VPC. We can now offer the option to create an entire dedicated cluster per customer with custom limits, on a custom domain with individual configuration. Need to host thousands of GraphQL APIs for a SaaS-product at a reasonable cost? No problem.

This relaunch also dramatically improves the scalability and reliability
of our platform. All the components that power the customer APIs are managed AWS services and scale on demand: AWS Lambda, AWS Aurora Serverless, AWS API Gateway, etc.
Even on the lowest tier, we can now offer an API with no single point of failure, multiple availability zones, automatic failover, and redundant data replication.

We need your Feedback

With the major infrastructure upgrade shipped, we now have more time to focus on new features and improvements.

That's where we need your feedback. We want to know...

What projects do you plan to build with Slicknode?
What features are you missing?
How can we take the Slicknode platform to the next level?

Your feedback will shape what Slicknode is going to look like...

Join our community on Slack or try the new platform.