DEV Community: GraphQL Editor

GraphQL benefits and why you should adopt it in 2024

Tomek Poniatowicz — Fri, 19 Jan 2024 17:10:51 +0000

The digital world is changing faster than ever. In an environment where new frameworks, technologies and tools are coming out almost every minute, scalability is not just an empty phrase, but the bare minimum to allow the development of an IT project. In this busy and ever-changing landscape, GraphQL architecture is steadily gaining popularity. Why? Thanks to its flexibility and precise data fetching mechanism. However as applications grow in scale and gain more users, the efficient scaling of GraphQL APIs becomes not only important, but actually crucial to ensure consistent performance and reliability.

In this short blog, we'll explore a variety of practices that allow you to smoothly adapt to the rapidly changing digital environment. From leveraging caching mechanisms and query optimization, to exploring advanced tools that allow you to expand your infrastructure as your applications grow - all to show how important it is to ensure the consistency, performance and reliability of your GraphQL API.

Let's start with the topic closest to my heart, due to the fact that our tool is used mainly (but not only) for designing GraphQL schemas.

Efficiently designed schema is the key

The foundation of a performant GraphQL API lies in its schema design*. When thinking of your schema there are a lot of things you need to cover (or at least be aware of), but to fully enjoy the DX and the speed of working with GraphQL lest start with data fetching. The main points I want to cover here are:

over-fetching & under-fetching: which is handled out of the box with the GraphQL queries system which enables retrieving only the required data, preventing unnecessary data retrieval or messing up your network bandwidth.

and its biggest nightmare which is:

deep nesting: when planing your GraphQL schema avoid going to deep or your will bury yourself with nested queries that can lead to performance bottlenecks and may nullify the highly optimized fetching system which you're getting for free in GraphQL! Keeping query depth shallow will let you enjoy faster query execution and reduce logic complexity for your team.

*if following the schema first path; schema first is our preferred approach here at GraphQL Editor & the entire blog post may be seen as biased in favor of schema first

Data fetching, batching & caching

When we talk about making things run faster, getting data quickly is super important. Using some basic data caching & batching techniques you can really amp up how well your API works, giving it a serious speed boost without much hassle.

use DataLoader: DataLoader is a utility that can be used as part of an application's data fetching layer to provide a simplistic and consistent API for different remote data sources (web services, databases etc.) through batching and caching.
implement layered caching: Using caching in different places, like on the client's side, the server's side or CDN (if used) can really help as it stops things from being fetched over and over and makes the general server response time way faster.
pick right cache eviction policy: Once again caching is critical for any high-performance system so make sure to use a cache eviction policy (when things which are not needed anymore are kicked out of the cache) that fits your project. Keep in mind you need to figure out how to keep all the different caches in sync so they have the same information. This way, you make sure everything stays up-to-date and works smoothly.
batch your data: Merge multiple data requests into a single query to minimize round trips and improve efficiency, leveraging GraphQL's ability to fetch multiple resources in a single request.

Monitoring, optimization, load balancing & horizontal scaling

Continuous monitoring and optimization are required to keep your app running fast and smooth. Good monitoring tools, load balancing and horizontal scaling are your pals when it comes to handling peak traffic... and it also helps to retain customers as bad latency can wreck customer experience even for the best designed, shiny app. Keep your eyes on:

profiling & monitoring: regularly check and analyze query execution times using monitoring tools to pinpoint and address performance issues effectively.
resolver optimization: always aim to improve the efficiency of resolver functions to boost query performance. Don't wait and try to immediately address any issues with slow-performing queries for better overall system responsiveness.
load balancing: most cloud infrastructures have a load balancing feature available out of the box, but if you're working on your own infrastructure (which is becoming a new trend after the "serverless hype" era), make every effort to evenly distribute incoming requests across multiple servers to prevent overload, ensuring a balanced workload and maintaining system responsiveness.
horizontal scaling: scale your application by adding more server instances to handle increased demands and manage them efficiently through tools which help achieve seamless orchestration like K8s the open-source system for automating deployment, scaling, and management of containerized applications.

Don't rush with GraphQL adoption

As always, the old saying that haste makes waste rings true. Rather than rush, take your time to give yourself and your users peace of mind. Transitioning from REST to GraphQL is one thing, overcoming obstacles that you didn't foresee at the beginning (let's not kid ourselves, there is no such thing as smooth transition and if there's even a small chance that something might go wrong you can be sure it will) so be prepared to handle one of the greatest scalability challenges which is:

backward compatibility: with GraphQL you get backward compatibility out of the box and new fields can be added to the schema without impacting existing queries. This is in contrast to REST, where changes to the API may disrupt existing clients. So when you finally decide to transition from REST to GraphQL remember to ensure backward compatibility.

Teamwork makes the dream work - collaborate!

Having effective communication and maintaining detailed documentation - these are the two keys for ensuring your team enjoys effective collaboration and is working effectively. Find a platform that can streamline and simplify communication over your schema (the most important piece of your GraphQL project) leave no room for understatement as the key to your project's success is:

teamwork: GraphQL is all about collaboration between frontend and backend teams, helping develop a common understanding and an efficient query optimization approach. This is where our GraphQL Editor can help increase the work effectiveness of teams through such features as Live Collaboration that allows multiple team members to work on a GraphQL schema & in general through its visual features that provide a better picture of the schema overall.

From niche to mainstream

It's been 8 years since Facebook released GraphQL and the days when it was some fresh, niche technology are long gone. By now it has moved way past the hype phase, and has easily maintained its status as the main competitor to the steadily declining REST over the past few years. Hardly surprising taking into account the various GraphQL benefits mentioned above, especially with the schema-first approach I've recommended earlier. So while rushing into adoption isn't a good idea, considering it definitely is!

Conditional rendering in React

Tomek Poniatowicz — Sun, 05 Nov 2023 16:46:05 +0000

I recently saw some posts and comments about conditional rendering in React and to my surprise some of them stated && was outdated and should be dropped in favor of using if/else, : ? and || conditions. It struck me as odd as from what (admittedly little) I have learned so far AND is fine and in some cases simply more straightforward. Especially when compared with sticking nulls everywhere just to avoid using it. Far be it from me to criticize anyone but I decided this would be a good idea to elaborate more on conditional rendering in React.

if/else and ternary operator :?

This is most likely the first type of conditional you’ve learned, honestly I didn't even know it was called a ternary operator until writing this as I’ve heard our devs simply call it an ‘if’ or ‘conditional’. Both are very straightforward and work pretty much the same although with a slightly different syntax:

PowerLevel  > 9000 
? console.log(‘Its over 9000!!!’) 
: console.log(PowerLevel)

if (PowerLevel > 9000)
{console.log(‘Its over 9000!!!’)}
else
{console.log(PowerLevel)}

Both of these will do exactly the same thing but the syntax is slightly different. For a simple thing like this the ternary operator is just more succinct and makes more sense to use. It's obviously down to personal preference but from what I’ve heard from devs the rule of thumb is:

use :? for smaller things that can fit in one line or two (eg. for registered users show a button with “Log in” and for unregistered show it with “Register”)
use if/else statements for executing bigger segments of code (like say a different navbar for desktop and mobile versions of a website)

Just to give you a real example this is a simple code snippet from our language switcher:

push(pathname.replace('[locale]', newLang === 'en' ? '' : newLang));

It's pretty simple - when the user selects a language from the dropdown it pushes the user to the selected language version of the page adding the locale tag to the url address, but omitting it if it's the default language ie. English. (sidenote here: this is actually very important for SEO as I’ve had multiple issues with language selectors adding a default locale tag to the url which caused example.com and example.com/en to be flagged as duplicate pages)

While using ternary and if/else is the go-to it can be overused because of that, as sometimes other conditionals make more sense. Take this simple snippet for a metaDescription meta tag in my custom helmet - it uses the provided metaDescription if there is one and a fallback value if it is not provided:

<meta
  name="description"
  content={metaDescription ? metaDescription : defaultDescription}
/>

OR (||) condition

While that works fine I’ve actually started using OR conditions for cases like this since they are simpler and quicker to write. From my experience this is used way too little since you get tons of situations like this (especially when dealing with websites) where you just need one value and a default fallback just in case. Following the above metaDescription example we can just use this to get the exact same result:

<meta name="description" 
content={metaDescription || defaultDescription} />

It will simply always use a metaDescription if one is provided, and fallback to the default one if it is not, which is perfect for use cases like this. Yes you can use multiple || and it will simply always render the first one that is true, but I think that’s overusing it since you can't specify different conditions for each one anyway and at that point using a ternary condition or if/else makes more sense anyway. You can also use || with a null for an element you only want to render under certain conditions, but for that case && actually makes more sense in my opinion.

AND (&&) condition

Like I said before I have seen some claims && is outdated, which surprised me since I consider it by far the cleanest to use when I want to render an element only under certain conditions. It works the simplest of all of the ones I mentioned here as it just does nothing if the condition is not fulfilled. Yeah you can do that with the others - just use a null and you’ll likely get the same result - though writing nulls everywhere just for the sake of avoiding && seems pointless.

Sure you can get a displayed 0 error like the one on the screen below:

Obviously if you’re afraid you might get one for something like products.length on your ecommerce store it's also pointless to force yourself to use && just for the sake of it - it's way better to go with what you feel more comfortable with. That said, this particular error was solved by simply using !! to force a boolean representation and the && was left untouched - which goes to show once again that all this comes down to what you're most comfortable using.

For me I can say that on the SEO side I’ve fixed enough bugs and issues where someone forgot to add a null and I had off-screen or hidden elements picked up by crawlers. If you like the seo guys in your workplace you can be nice and save them an hour or so which they might otherwise spend looking for a mobile langSwitcher with a 404 link which was hidden somewhere on the desktop version of the page. So for a simple component that you want rendered only if a certain condition is fulfilled && is still perfectly fine in my opinion. Here's an example case of where I use it in my custom helmet element:

{
  LocalizedPage && (
    <>
      {hrefLangs.map((lang) => (
        <link
          key={lang}
          rel="alternate"
          hrefLang={lang}
          href={`https://example.com/${lang}${location}`}
        />
      ))}
      <link
        rel="alternate"
        hrefLang={defaultLang}
        href={`https://example.com${location}`}
      />
      <link
        rel="alternate"
        hrefLang="x-default"
        href={`https://example.com${location}`}
      />
    </>
  );
}

As you can see that is even simpler than the others - only render this code if the page is localized. I don't have to specify the outcome for false or a fallback null value - I just say this is solely for that condition and that's it. This is a simple way of ensuring I have alternate links included in the head for pages which are translated into other languages, while making sure they won't appear in the dom for those which aren't translated (like say blogposts) which would be flagged as a SEO error. I think it's also a good approach to keep things as simple as possible when it comes to seo so if I go into someone’s frontend code to add this little element they figure out exactly what this is intended for at a glance.

Obviously if you’re comfortable with using if/else everywhere and that works for you there's no reason to force yourself to use something else, even if it can make more sense in certain situations. But as you can see in using OR or AND can be handier so it's perfectly fine to use those as well, they are in no means outdated or wrong if used correctly.

I18next translations inside maps & React dynamic import

Tomek Poniatowicz — Thu, 19 Oct 2023 09:32:33 +0000

Recently while browsing through one of our projects I found some atrocious piece of code I wrote a few months back. As ugly as it looks I think it can serve as a decent example of how much you can progress in a short time, even as a ‘copywriter-turned-not-really-a-dev’ like myself, and also how much you can do wrong in just one simple component.

While the code here serves as an example for the sake of the blogpost, it is an actual piece of my code from one of our websites. It's a simple component with four tiles with an image, some text and icons that illustrate the features of one of our applications. In case you're wondering why fixing it matters, I can tell you that if there's one thing that impacts SEO - it's poorly written code. It can worsen performance causing our website to work too slow and incur something Google calls Cumulative Layout Shift. It's basically a measurement of how much crawlers see your website's layout change as components or elements are loading in, which may happen if your code is bloated. Google considers that bad for user experience and can penalize your website's positioning for it. Aside from that obviously fixing bad code just for the sake of it is reason enough (especially if you don't want to get yelled at during code review). So here's the code for the component:

import { useTranslation } from 'next-i18next';
import { AutomationIcon, FastIcon, ProcessorIcon, AccurateIcon } from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    <li>
                        <div>
                            <AccurateIcon />
                            {t('features.features.accurate')}
                        </div>
                        <p>{t('features.features.accurateText')}</p>
                    </li>
                    <li>
                        <div>
                            <FastIcon />
                            {t('features.features.fast')}
                        </div>
                        <p>{t('features.features.fastText')}</p>
                    </li>
                    <li>
                        <div>
                            <ProcessorIcon />
                            {t('features.features.ai')}
                        </div>
                        <p>{t('features.features.aiText')}</p>
                    </li>
                    <li>
                        <div>
                            <AutomationIcon />
                            {t('features.features.automated')}
                        </div>
                        <p>{t('features.features.automatedText')}</p>
                    </li>
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};

As you can see even though I had some basic understanding of html and the useTranslation hook, but I made a mess of it because I didn't do any mapping and just wrote out every segment of the component as a list item. The component is rather simple, it has two columns - one is an image and the other has a header, description and four smaller tiles with titles, descriptions and icons. First we need to properly map the translated text and for that we have to restructure the json file with the translations:

"featuresSection": {
        "header": "lorem ipsum header",
        "description": "lorem ipsum desc",
        "features": {
            "fast": {
                "name": "Fast",
                "text": "lorem ipsum dolor",
                "icon": "FastIcon"
            },
            "accurate": {
                "name": "Accurate",
                "text": "lorem ipsum dolor",
                "icon": "AccurateIcon"
            },
            "ai": {
                "name": "AI powered",
                "text": "lorem ipsum dolor",
                "icon": "ProcessorIcon"
            },
            "automated": {
                "name": "Fully automated",
                "text": "lorem ipsum dolor",
                "icon": "AutomationIcon"
            }
        }
    },

Now that we have everything neatly organized in our json files it's time to map it using the i18next useTranslation hook. Lets use a const for the section of the landing json file we're using so that we can then access it via just curly braces like in the h2 and desc div here:

import { useTranslation } from 'next-i18next';

const { t } = useTranslation('landing');
const featSection = t('featuresSection');
<h2 className="header" dangerouslySetInnerHTML={{ __html: featSection.header }} />
<div className="desc">{featSection.description}</div>

Alternatively you can use the built-in i18next attribute KeyPrefix. I think this works the same way regardless (unless there's some key difference I’m unaware of) but I just like using the const as that way I can access every translation string by just calling the const name in curly braces {featSection.whatever} instead of doing {t(‘whatever’)} but that’s just personal preference and you can do it like this as well:

const { t } = useTranslation('landing', {keyPrefix: 'featuresSection'});
<h2 className="header" dangerouslySetInnerHTML={{ __html: t('header') }} />
<div className="desc">{t('description')}</div>

With that done let's change the html code for the list items. We can simplify it since all the list items are structured the same way:

<li key={key}>
  <div>
    <IconComponent />
    {name}
  </div>
  <p>{text}</p>
</li>

Now for the whole list we still need to map these elements, at first I went with this:

const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.keys(featSection.features).map((key) => {
        const { icon, name, text } =
            featSection.features[key as keyof typeof featSection.features]; const
                IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key="{key}">
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

While that worked it required an extra const and a somewhat hacky workaround for a TypeScript type error via as keyof typeof and pointing it to featSection.features. We can definitely do better! In general there’s three methods of mapping objects: keys, values and entries (which contain both keys and values). As you can see at first I went with keys, but using values makes more sense since that way TypeScript can infer the type values and we can just use idx which will also let it identify the key values. That approach lets us get rid of the const and simplify the code again:

const iconComponents = {
        AutomationIcon,
        FastIcon,
        ProcessorIcon,
        AccurateIcon,
};
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        const IconComponent = iconComponents[icon as keyof typeof iconComponents];
        return (
            <li key={idx}>
                <div>
                    <IconComponent />
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

That's nice and simple but as you can see I'm still defining the icon types and values via an extra const and the hacky as keyof typeof workaround. To get rid of that we can use React's dynamic imports. Since the json file already defines what icon should be in each component we can use that to import the icons dynamically. So now instead of using import for each icon individually we can import them dynamically by using this:

import * as Icons from '@/assets';
<ul>
    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
        return (
            <li key={idx}>
                <div>
                    {Icons[icon as keyof typeof Icons]()}
                    {name}
                </div>
                <p>{text}</p>
            </li>
        );
    })}
</ul>

Now we can even use different icons for different language versions if we want to, by simply specifying their names in that language json file. Let's look at the whole component:

import { useTranslation } from 'next-i18next';
import * as Icons from '@/assets';

export const FeaturesSection = () => {
    const { t } = useTranslation('landing');
    return (
        <FeatureSectionWrapper>
            <FeatureText>
                <h2 className="header" dangerouslySetInnerHTML={{ __html: t('features.header') }} />
                <div className="desc">{t('features.description')}</div>
                <ul>
                    {Object.values(featSection.features).map(({ icon, name, text }, idx) => {
                        return (
                            <li key={idx}>
                                <div>
                                    {Icons[icon as keyof typeof Icons]()}
                                    {name}
                                </div>
                                <p>{text}</p>
                            </li>
                        );
                    })}
                </ul>
            </FeatureText>
            <FeatureImg
                src="/images/results.png"
                alt="feature image"
            />
        </FeatureSectionWrapper>
    );
};

That's a lot cleaner and less painful to look at, and it only took a couple simple changes. Obviously it's a reach to call this a refactor or really anything but a small fix, but going over earlier mistakes makes things easier to remember (at least for me). It's also a small step towards writing cleaner and simpler code which is a good thing to keep in mind. It's also the best route to take especially in regards to SEO where better safe than sorry is the only correct approach. You can be sure that it's a whole lot easier than figuring out which piece of code on your website is causing the dreaded layout shifts Google has flagged you for.

Eleventy components woes

Tomek Poniatowicz — Tue, 03 Oct 2023 15:27:55 +0000

So far so good, in part one we managed to do a very basic setup of a blog website sticking to just markdown and html (with a little bit of Nunjucks admittedly). If that's all you wanted from Eleventy then you're good to go and you'll find a lot of possible improvements and additions if needed. If you wanted to build a more complex website, well... this is where things get a bit tougher as modern websites use components and for Eleventy those are a bit of a touchy subject.

Components

Components are used almost universally now so it's hard to imagine web dev without them. At first glance everything looks really promising - not only does Eleventy support components but since it will compile them to static html and CSS we're getting a true server-side component system! While that sounds great in theory, sadly things aren't as simple as that. To get to know why first let's look at the numerous methods of creating components in Eleventy:

Liquid Render/Include
Nunjucks Include & Macro
Eleventy Render Plugin
Eleventy Vue Plugin (soon to be archived)
Eleventy Shortcodes
WebC Plugin (new!)

Templating

We've done a bit of that already with collections and this approach follows the same logic. Since we already have our blog posts now we need a bit of navigation, let's add a go-back button for users, letting them return to the index page after they're done reading a post. For that we need a button component in our _includes folder which will have typical button props like label and URL.

<a href="/">Go back</a>

Now we need to include it in our layout template:

{% include "button.html" %}

That works, but it isn't really fair, is it? We simply imported a static piece of html. If we want a real button component it should have props and to do that with Eleventy we need to use Nunjucks and create a button.njk component with those props:

<a href="{{ url }}">{{ label }}</a>

with that we can go to our template and specify what that url and label for the included button will be:

{% set url = "/" %}
{% set label = "Go Back" %}
{% include "button.njk" %}

No thanks

So we managed to create the simplest button component with props. The downside is that not only is this very similar to React and importing components - it's also more boilerplate compared to something like a simple import statement and <Button href="/">Go Back</Button>. Just to hammer this point home, this button was the simplest example. Let's imagine some standard website component which will have not only a button but also localized text, which will vary depending on which language the user selects and styling which will vary if a different theme is selected.

Liquid includes/render works basically the same - you can include a global reusable component like button.liquid in your _includes folder and render it in a template or page as {% render 'button' %}. It does have additional options but since we're looking for simplicity and this method has already soured us on that, I won't be going over them in more detail here.

Similarly there's also an option of using Nunjucks Macros for larger components like a pricing card:

{% macro pricingCard(title, description, price) %}
  <div class="pricing-card">
    <h2>{{ title }}</h2>
    <p>{{ description }}</p>
    <span class="price">{{ price }}</span>
  </div>
{% endmacro %}

{% import "pricingCard.njk" as pricingCard %}

{% block content %}
  <div class="container">
    {{ pricingCard.pricingCard('Basic Plan', 'Includes essential features', '$1.99/month') }}
  </div>
{% endblock %}

The issue with all these methods is they are doing something similar to React, but in a more complicated way. What about conditional props which in React are as simple as a single ?, well for those you'll have to do even more javascript boilerplate and use if/else conditions. It's pretty apparent that neither of these approaches fits our simplicity requirement, so that's 0-2 for Eleventy and let’s proceed to the others.

Custom Template Shortcodes

The Render Plugin I mentioned before is a little addon which gives you two shortcodes for quick and easy use, so let’s go over shortcodes in general. You might be wondering why there’s a plugin with just two shortcodes when Eleventy supports them out of the box. The answer is very simple - adding them is even more of a hassle and even more boilerplate code.

Going back to our button example, let’s say we want to get closer to React and use something like:

{% button url = "/", label = "Go Back" %}

That is doable, but for that we need to tell Eleventy what this button is and this is done via a function in the main eleventy config file. I don't think I need to go over this step by step because a quick look at the code will tell you everything you need to know:

const fs = require('fs');
const path = require('path');
const nunjucks = require('nunjucks');

module.exports = (eleventyConfig) => {
  eleventyConfig.addNunjucksShortcode('button', (props) => {
    const filePath = path.join(__dirname, '_includes/button.njk');
    if (!fs.existsSync(filePath)) {
      return 'missing file';
    }
    const content = fs.readFileSync(filePath).toString();
    return nunjucks.renderString(content, { component: props });
  });
};

Holy boilerplate, this just looks terrible and remember this is all for just one basic button component. I guess I get the idea, but I shudder to think how that config file would look for some of our websites. Now I have seen some example of getting around that using functions to loop over a directory with components, but that's just digging a deeper hole with even more js code. Even if you make that work it's just another makeshift solution which will then run into the fact that most websites use nested components as organisms, atoms, sections etc. which you'll have to do even more clunky workarounds to handle. Once again we were looking for simplicity - and we arrived at the opposite end of the spectrum - tedious boilerplate code shoved into a bloated config file. I mean just compare the atrocity above with a simple export like this:

const Button = ({ href, children }) => {
  return <Button href={href}>{children}</Button>;
};
export default Button;

Vue woes

So with that we're down to 0-4, not great to put it mildly. Eleventy has also cooperated with Vue on a specific Eleventy Vue Plugin. This approach had its benefits as it used Vue components out of the box rendering them to plain html providing you with a very nice base. The issue here is that after a while Eleventy ran into the same problem I mentioned in the first blogpost - maintenance. Maintaining a plugin like this requires cooperation on all the connected things and long story short that has broken down and the Eleventy Vue plugin is on its way to being archived after VUE shut it down on their end.

WebC to the rescue?

Now being completely honest I'm probably a bit too harsh on Eleventy as it did its job as a SSG wonderfully as I outlined in the first post. It's just a bummer that we got into this roadblock with components and looking at the various methods has put me off trying it for even a simple landing page. Just to make it perfectly clear I'm not comparing Eleventy with React because I want it to be React - far from it! We were looking for something that isn't React and thats why wrapping components in boilerplate js code to get them to work kinda like React is missing the point entirely.

But thankfully from what I've read there's a light in the tunnel in the shape of a new WebC Plugin. I have to say I am a bit skeptical after going through the sad tale of the Vue plugin, but from what I've seen this looks a lot more promising. Which is great because Eleventy really is promising and solves a lot of the basic problems. All that's missing is some less hacky way to do components and it can be truly great. So thanks for reading and see you in part three where we look at the new WebC plugin and if that solves our component issues.

Making a simple Eleventy blog template

Tomek Poniatowicz — Sun, 01 Oct 2023 16:16:22 +0000

If you’ve worked with TypeScript, React or Next odds are you’ve encountered an update that broke a number of features on your page. When that happens you’re left wondering if there’s some simpler or older technology you could use that would just be less hassle. Well at least that’s what we were talking about at the office after the last Next update with translations.

Back to the past

Thinking about simplicity the things that come to mind are languages like css, html or even markdown. Simple is one thing and stability is another, there's zero chance we’ll get a groundbreaking markdown update next year, which will break our projects. That’s why we looked at some frameworks that could work with something as simple as that, going in the complete opposite from our usual TS, Next & React stack. That’s how I stumbled upon Eleventy, a versatile SSG which works with a number of file formats - among them Markdown which is exactly what we were looking for and as simple as it gets.

Setting up a simple blog page

So the next question was could we actually create a page using only simple languages like markdown? The answer is Eleventy and it's really simple to use just like we wanted. Obviously you’ll need to npm install the run it and since we’re already on a blog page let's use that for our example.

First we’ll need a index.html page from which we will be able to access our content and a posts folder for our blogposts in markdown. We can add an example post in markdown and run localhost to see eleventy will automatically render it to html (neat and simple just like we wanted)

├── posts
│   ├── my-first-post.md
│   ├── my-second-post.md
├── index.html

We'll also need to do some layout for our blog, this is by default kept in a _includes folder, but it's easy to rename it in the settings if you want to call it layouts or whatever.

├── posts
│   ├── my-first-post.md
│   ├── my-second-post.md
├── _includes
│   ├── layout.html
├── index.html

To use the layout for our index page we need to include it in a front matter section at the top of the page like this:

---
layout: layout.html
---
the content of our page

We also need to tell the layout file where the content will go and for that we use double curly braces, reminiscent of liquid or nunjucks (more on that later btw.)

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Our blog</title>
  </head>
  <body>
    <h1>Welcome to our blog</h1>
    <div>{{ content }}</div>
  </body>
</html>

Obviously our blogposts will also need a layout and Eleventy has a neat trick to do it for all of them with just one line. We simply need to go to our posts folder, create a json file with the matching name (ie. posts.json) and point it to our layout file.

{ 'layout': 'layout.html' }

Front Matter

The fact we're using a json file to import the layout into our blog pages doesn't mean we can't also use front matter there. For example we'll definitely want to use different titles for our posts so we need to add them to the front matter:

---
title: the title of our post
cover: /images/FirstPostCover.png
---

and then import them in the layout

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>{{ title | default: "Our blog"}}</title>
  </head>
  <body>
    <img src={{ cover | default: "/images/default.png"}} alt={{ title | default:
    "Our blog"}} />
    <h1>{{ title | default: "Welcome to our blog"}}</h1>
    <div>{{ content }}</div>
  </body>
</html>

This is best suited for simple SEO tags like titles, meta descriptions, open graph tags etc. which we can now make sure will use dynamic titles, descriptions or images that we will specify in the front matter. For other things we can use something called collections.

Collections

Collections let us iterate over a group of files, like our posts. To do so we need to set a tag in that same json file we created and set a tag for them:

{
    "layout": "layout.html"
    "tags": "post"
}

Now we can for example list our blogposts on our index page. To do so we need to iterate over the post collection in the data:

---
layout: layout.html
---
{% for post in collections.post %}
<h2>{{ post.data.title }}</h2>
{% endfor %}

If the syntax looks weird to you it's Liquid - or Nunjucks here specifically, a simple templating language used for static site generators. If you don't like it you can also achieve the same result using JavaScript as Eleventy does support that as well but it would kinda defeat the whole purpose of going away from React.

Static Site Generator

That said with these few simple steps we can get our blog page running in no time at all, which is exactly what we were looking for - quick and easy! I should say it's hardly a surprise that a static site generator works well for generating a pretty straightforward static site. I might've painted a too rosy a picture with this simple overview so I promise I'll go over some of the downsides of Eleventy in part 2 (where we'll get into components!)

AI-Generated GraphQL Schema and Fake backend

Tomek Poniatowicz — Fri, 29 Sep 2023 15:10:58 +0000

if you want to check it out without reading just click here and go test it out yourself

Looking for a springboard

For a while now we have seen data from both analytics and community feedback that GraphQL Editor has a pretty steep learning curve and a lot of users have trouble getting their projects off the ground. We've tried pretty much everything to remedy that:

youtube tutorials
detailed documentation with gifs
step-by-step guides
pop-up onboardings
interactive in-app tutorials

While that has had positive effects it still didn't satisfy a lot of users who wanted to get going right away without following tutorials or guides. While brainstorming someone floated the idea of creating an example project that would give users some basic view of what they can do. This made a lot of sense, but why stop at a generic project when we can use AI to tailor it to what the user needs?

AI-generated Docs

We actually were already working on utilizing Chat-GPT for generating documentation. While that will be a sweet feature (as nobody likes writing documentation) it's a bit more complicated and we're still working on it. That said, we have decided that giving new users a jumping-off point was a priority and more importantly a lot easier to implement. So while ai-generated docs are coming soon, we do have two new AI features to show off!

AI-generated schema

From now on, when starting a new GraphQL Editor project you will notice a new field with some sparkles. This is where you can enter your prompt and the AI will then generate a schema for your project based on what you have entered. It can be anything - a food delivery app or a twitter clone and the AI should give you a nice base schema to play around with.

Here's what I got after typing 'schema for a twitter-like app':

type User {
  id: ID!
  username: String!
  email: String!
  password: String!
  createdAt: DateTime!
  followers: [User!]!
  following: [User!]!
  tweets: [Tweet!]!
}

type Tweet {
  id: ID!
  content: String!
  createdAt: DateTime!
  author: User!
  likes: [User!]!
  retweets: [User!]!
  replies: [Tweet!]!
}

type Query {
  getUser(id: ID!): User
  getTweet(id: ID!): Tweet
  searchUsers(query: String!): [User!]!
  searchTweets(query: String!): [Tweet!]!
}

type Mutation {
  createUser(username: String!, email: String!, password: String!): User!
  deleteUser(id: ID!): User!
  createTweet(content: String!): Tweet!
  deleteTweet(id: ID!): Tweet!
  likeTweet(tweetId: ID!): Tweet!
  retweetTweet(tweetId: ID!): Tweet!
  replyTweet(tweetId: ID!, content: String!): Tweet!
}

scalar DateTime

schema {
  query: Query
  mutation: Mutation
}

Ai-powered fake backend

Additionally you can now go to the API section and test out your queries and mutations against a fake backend with AI-generated field values! The AI will provide mock responses automatically based on the information it can gather - so if your query is something like getUsers with fields of usernames and email addresses the mock backend will return faked responses for those fields with random names and emails and the same for anything from listMovies to getListofPizzaToppings and the like. We had used the popular FakerJS database for this for years but that had its limitations and more importantly, required the user to choose and click the type of value they wanted faked for each field. While handy that was only a small step from writing them in yourself in an array. Now all that happens automatically without requiring the user to do anything!

Here's the result I got for the searchUsers query:

{
  "searchUsers": [
    {
      "createdAt": "Wed, 27 Sep 2023 18:42:23 GMT",
      "email": "Santos_Murray@yahoo.com",
      "username": "Chanel.Cummings"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 07:48:07 GMT",
      "email": "Howard_Romaguera30@yahoo.com",
      "username": "Lexie.Langosh"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 22:31:15 GMT",
      "email": "Ulices.Brown@yahoo.com",
      "username": "Johnathon_Krajcik"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 20:31:03 GMT",
      "email": "Bart_Emmerich97@hotmail.com",
      "username": "Scot20"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 00:13:46 GMT",
      "email": "Jaylin_Marvin@gmail.com",
      "username": "Loren.Harris65"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 23:01:56 GMT",
      "email": "Rylan3@gmail.com",
      "username": "Alysson.Heaney88"
    },
    {
      "createdAt": "Wed, 27 Sep 2023 16:35:04 GMT",
      "email": "Angelo81@yahoo.com",
      "username": "Katheryn.Bednar0"
    },
    {
      "createdAt": "Thu, 28 Sep 2023 05:54:44 GMT",
      "email": "Nichole_Schamberger@yahoo.com",
      "username": "Lottie.Fay63"
    }
  ]
}

For fun or as POC

As you can see it's very easy to play around with. Our main hope is that with this users (especially new ones) will have a way easier time getting acquainted with the basic possibilities of the tool. Obviously that's just one use, it can also be pretty handy to show proof of concept for an app showing both the overall structure and possible query and mutation results. It also serves as a nice starting point as you can easily edit all the fields the AI has created for you - changing the schema to whatever fits your needs. The whole process is so simple it requires only a few clicks without writing or even knowing any code - so even non-coders can easily do it and show their idea for an application!

Apollo Supergraph: A GraphQL stack for everything

Tomek Poniatowicz — Thu, 23 Jun 2022 09:51:34 +0000

The folks at Apollo have been working with GraphQL since 2016, back when they were still Meteor Software. Versatility has always been at the core of Apollo, when they released their GraphQL-based datastack in 2016 its calling card was ‘any backend, any language, any client’. The idea was clear, to have one tool for building a GraphQL client and server which can then be used to either build a new app from scratch or fit into an existing project, so that it can take full advantage of the perks of GraphQL.

Apollo Server and Apollo Client

At the core of the stack were Apollo Server and Apollo Client and both became popular tools in the community in their own right. Apollo Server ran as a GraphQL translation layer on top of the existing backend and Apollo Client was a Relay-like client that could be adopted in any application. The same flexible approach was clearly apparent in both. Apollo Server works with a wide range of different data sources via open-source implementations (HTTP/REST APIs, SQL databases, MongoDb and others) and Apollo Client is view-layer agnostic and works with a number of frameworks like React, Angular, Vue or even vanilla JS.

The Supergraph

The versatile approach, started with those two tools, has now produced a new stack called Apollo Supergraph. It's a single solution for bringing together data from a wide variety of sources into a single Supergraph, a unified layer made from modules interacting with each other. Apollo has always worked according to their principled GraphQL approach, inspired by the Twelve-Factor App methodology. It's easy to see here as well as the entire Supergraph concept is based around three core principles:

a unified composition layer: Supergraph is meant to be a graph of graphs, connecting all of the company’s data, microservices and digital capabilities into a new unified composition layer.
modular architecture: Supergraph’s modular and declarative architecture lets teams quickly integrate modular data, services and business logic into that unified layer.
agile approach: Taking a bottom-up instead of a top-down approach makes for faster and more involved development. Every dev and team is encouraged to publish changes into the schema on their end, and the actual use of schema is what pushes development forward, by having everyone focus on decisions and improvement.

Three building blocks

So everything is about making a unified layer by using modules and focusing on constant improvement. While that gives us some indication of what were the main ideas behind creating the stack, we still need some more specific information to get the full picture. Similarly to the three principles the Supergraph also has three core components:

Apollo Federation is what is actually responsible for building the Supergraph, by composing a number of subgraphs (GraphQL services) into a supergraph. Following the modular principle each subgraph is an independent self-contained component with its own schema, which can be worked on and deployed individually. Subgraphs can be written in 20 different programming languages so the bottom-up, flexible approach is also evident here.
Apollo Router is what is responsible for running the Supergraph. The runtime is a successor to the previously used Apollo Gateway: it boasts 10x lower latency, 10x higher throughput and 12x lower variance compared to its JavaScript predecessor.
Apollo Studio is what delivers the Supergraph. Validation, automation, observability, all that good stuff you need to make delivering changes quickly and safely possible. It's even more true in the rapidly evolving environment of the Supergraph where devs and teams are encouraged to work on each other's contributions. Schema Checks and Launches automatically validate the schema in development, which helps prevent breaking changes before they occur and makes past and ongoing changes easily visible.

Spread the word

I think it's safe to say Supergraph aims very high. It wants to be a true enterprise stack that you can adopt and work on company-wide regardless of what languages the programmers use and what types of services and data sources need to be integrated. If the hype is real it can really become a catch all solution that will streamline work and make full use of the advantages of GraphQL along the way. The Apollo team has been very reliable so far so if you’re a GraphQL enthusiast it's definitely something you want to keep an eye on and tell others about. After all wide adoption is key if we ever want to start working together using the Supergraph.

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz

Speed up your GraphQL API development

GraphQL Editor is a supportive tool for both advanced GraphQL users as well as those taking their first steps with GraphQL APIs. Our all-in-one development environment for GraphQL will help you build, manage & deploy your GraphQL API much faster. Try GraphQL Editor for free!

GraphQL Yoga 2.0 - a light but fully-featured GraphQL Server

Tomek Poniatowicz — Thu, 05 May 2022 08:03:23 +0000

Everyone including beginners who are just getting into GraphQL sooner rather than later arrives at what you can call the server question. In GraphQL everything is basically dealt with in two parts, the schema (type definitions and resolvers) and the HTTP server. On the client side you can find many useful libraries that will help you build your schema and everything is in SDL which is a pretty transparent language that isn't too hard to get a hang of. The server side might be a bit tougher to handle, but there’s also a number of options that can help you with that as well. One particular library just got a big revamp so it's a good idea to check it out.

Yoga 1.0 - quick and easy

Graphql-yoga has been around since 2017 and while not nearly as popular as Apollo-server it did have a lot of advantages. Its documentation described it as ‘create-react-app for building GraphQL servers’ and it's hard to argue with that. It required minimal setup, kept most of the boilerplate code you usually get when starting a server hidden and handled much of the initial project setup for you. Together this made it the easiest server option for beginners to get into as well as a useful tool for experienced users looking for a way to make a quick NodeJS GraphQL server. Down the line if your project grew too large for Yoga you could’ve simply swapped it out for a more complex tool like the above mentioned Apollo-server. All wasn't rosy though as by 2019 the project stopped getting updates and was basically abandoned. This resigned it to the role of a learning tool with some uses in case you need to get up a server quickly, but pretty much ensured you wouldn't ever use it for a fully fledged project. The fate of the Yoga library might’ve been a bit of a bummer considering the lack of an alternative lightweight and versatile GraphQL server option.

The Guild comes to the rescue

In late 2021 Yoga was taken over by The Guild and they decided to rewrite it from scratch. Their main focus was performance, flexibility, easy setup and improving overall developer experience, in other words a lot of what the old Yoga was about combined with new more comprehensive solutions. The key thing here is that The Guild promises to be here for the long run and not only update Yoga, but also keep working on improving it with new features. They can be trusted to uphold that as they have quite a bit of experience with GraphQL with a number of popular and still developed libraries like GraphQL Tools or Envelop. On GitHub you can already see Yoga has received hundreds of commits and lots of updates so the project is very much alive. In late March the big 2.0 update finally arrived so let’s check out what the key features are:

flexible: Built around W3C Request/Response which is supported in all major serverless, worker and serverful JavaScript environments, Yoga is designed to run basically anywhere
lean: Yoga has a really light core and a small bundle size, three times smaller than Apollo-server, which can prove very significant for performance in serverless environments and make maintenance much easier in general
out of the box: Some popular GraphQL API features like advanced error handling, file-uploads, subscription support or CORS come built-in with Yoga
easy to get a hang of: Keeping up with the beginner firendly approach Yoga has robust documentation and comprehensive tutorials to help you get to know all the features and functionalities
plugin system: With Envelop The Guild has started a large plugin system for GraphQL, which Yoga has built-in and comes with a default preset enabled (which can be disabled or customized)

Beyond 2.0

Yoga has been a useful tool for easily and quickly creating a GraphQL server, especially great if you just wanted to get a hang of it. Now though it looks like the aims are quite a bit larger and the team behind it wants to make it a viable or even superior alternative to other server options. It already had its niche and now fusing the old Yoga approach of getting started quickly with the rich ecosystem of Envelop can prove to be a powerful combination. The Guild know their way around GraphQL and have already created a number of very useful and popular tools so we pretty much know we can expect good things to happen to Yoga as well. With the development picking up speed so quickly additional new features will probably arrive soon, so even if you’re still not convinced it's a good idea to keep an eye out on the growth of Yoga and how it compares to other server options.

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz

Speed up your GraphQL API development

Apollo Kotlin - getting started with GraphQL on Android

Tomek Poniatowicz — Tue, 18 Jan 2022 07:49:58 +0000

Using GraphQL on Android has been a niche topic for quite a while and that might be a bit surprising, especially considering the prevalence of Android devices and the steadily growing popularity of GraphQL. Still even a quick google search will show you REST still dominates in the Android community. That said, something not being popular isn't a reason to discount it out of hand and since it's a new year, why not check out something different instead of going with the flow.

Who doesn't like GraphQL?!

If you’re here you’re probably quite familiar with the advantages of GraphQL so you might be wondering why the Android community has been slow in getting on the GraphQL hypetrain. While there are a number of factors, one is pretty glaring, the number of available tools. Thankfully there are some new libraries popping up here and there, but it's safe to say that if you’re trying to work with GraphQL on Android right now, Apollo's Android library is the only way.

So it looks like we’re stuck picking it, but what is it exactly? Well GraphQL was released publicly all the way back in 2015 and in early 2017 Apollo released Apollo Android v. 0.2 which provided some basic support for GraphQL model generation. It's been a few years since then and it has grown quite a bit larger, version 1.0 introduced Kotlin code generation and 2.0 introduced multiplatform query and subscription support. To get a better look at it's state let’s check out the main features:

multiplatform: the library is designed with Android in mind, but can be used in any Java/Kotlin app
makes full use of GraphQL: from basics like queries, mutations and subscriptions to more advanced stuff like query batching, persistent queries and an AST parser
3 levels of catching: HTTP Response Cache (for caching raw http responses), Normalized Disk Cache (per node caching of responses in SQL) and Normalized InMemory Cache (Optimized Guava memory cache for in memory caching)
RXJava support ...

RXJava

On that last one if you’re familiar with Java you’ve probably heard about RXJava, if not it's an extremely useful implementation of Reactive Extensions that has been popularized by Netflix. While Android Apollo generates Kotlin/Java models from GraphQL queries, RXJava (to quote the official description here) is a library for composing asynchronous and event-based programs by using observable sequences. That’s just the technical terms, to use simpler language it reverses the usual process where you request data, to an event based process where you're notified about data in the stream. Since you’re using GraphQL for requests (or rather queries) anyway it's simply very handy for use with subscriptions. That’s obviously not the only advantage and you can find a ton of info on the uses of RXJava so let’s just say it's popular for a good reason.

Apollo Android -> Apollo Kotlin

That’s not all, about a month ago Apollo Android made version 3.0.0 public. While the most noticeable difference was clearly the name change from Apollo Android to Apollo Kotlin, the changelog was a bit longer than that. Aside from the usual bugfixes and an update to Kotlin version 1.6.10 we can see a few new features:

extended multiplatform support for Android, JS, iOS, MacOS and linux
coroutine APIs for easier concurrency
response based code generation engine
SQLite batching

Your own niche

I hope that gave you a somewhat decent overview of the Apollo Kotlin library and maybe piqued your interest at least a tiny bit. As I mentioned previously it's not a very popular topic, so if you’re looking for your own niche this might be it. If not, the growing popularity of GraphQL will certainly keep influencing the Android community anyway, so it might be a good idea to beat others to it and start early. While Apollo Kotlin is the go-to tool now, no one can say that has to be the case forever. Maybe it will soon face competition from some new libraries and who can say one of those libraries can't be created by you?

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz

Speed up your GraphQL API development

Saleor - a GraphQL-first open-source e-Commerce platform

Tomek Poniatowicz — Wed, 08 Dec 2021 09:57:47 +0000

The pandemic has changed many aspects of our lives. Because of the lockdowns, almost all of our activities have moved online. Work? Remote. Meetings? Zoom or Teams. Shopping? Ecommerce. One of the areas most impacted by the pandemic is the retail industry.

The changes have caused a significant acceleration of e-commerce, but also increased competition in the field. With such rapid growth and the race for the biggest market share, keeping in touch with customers and making sure they get what they need has become a challenge. Just as Zoom, Teams and other apps have helped with conference calls as remote working has entered the lives of most people permanently, automation and tools that allow for better management of sales, customer service and customer relations has become essential for the ecommerce industry.

Customer Relationship & Process Management Platforms

The most basic customer relationship helpers are Customer Relationship Management (CRM) apps. CRMs are a sort of company archivists, keeping track of all matters related to its business operations in order to create a “company's memory" independent of the changing of its employees. The data gathered this way can be easily subjected to multidirectional analyses leading to more accurate business strategies.

The above definition was valid 20 years ago, currently CRMs have transformed into something more than just company business data storage & there's a lot more to them than that. Modern CRMs track every interaction with every client, the chain of email conversations and the progress of each individual customer case. This can be anything from tracking:

potential leads,
sales,
purchases,
customer support or complaints.

The strength doesn't come from just having the data, but from being able to streamline the whole process through various automations and integrations, while still having everything in one place. This keeps the whole process and each case transparent and easy to analyze for the person handling it. CRMs evolved from a company archive into Business Process Management (BPM) platforms which, with a little of help from 3rd party tools, can be not only the company's archivist but also a sales and marketing person.

Mix and match

I said the strength comes from automations and integrations, because CRMs do not aim to be the be-all end-all. These platforms are aimed at keeping things tidy and easily accessible for non coders while most of the work happens in the background. Some of the more popular CRMs are Pipedrive and Pipefy, so let’s take a quick look at what they’re about.

Pipedrive:

vertical platform developed with sales in mind
batch processing
sales force automation and sales tracking

Pipefy:

horizontal platform developed to fit the needs of various businesses
easy to learn automations to make personalization easier
custom workflow management

Source: pipefy.com

As we can see here Pipedrive is focused on sales and Pipefy is geared towards a broader audience, still both use integrations to fill in the gaps, so if you need to hook them up with some other app, for example to import data, you’ll have to rely on those. They do have a bit of basic built in integrations with things like Slack, Zoom or Google Sheets etc. but if you need something else it's pretty likely you’ll have to use something like Zapier to bridge the gap. Alternatively you could also use web hooks or a little thing called GraphQL. While Pipedrive requires third party libraries, Pipefy does handle both GraphQL queries and mutations by design, so it is a lot more flexible in terms of what you can do with it using that.

Saleor

Well if you’re a GraphQL enthusiast (and you probably wouldn't be here if you weren't one) this probably sounded like something right down your alley. After all, GraphQL is all about getting exactly what you want and not about jumping through hoops and integrations to get what you need. Well this is where Saleor comes in, a GraphQL-first headless sales platform. Most CRMs are geared towards non-coders, trying to keep everything simple by using tailored solutions and templates to make tracking everything easier. Saleor is a platform that helps connect that with both customers and developers, it’s aimed at providing maximum flexibility by giving them free reign over the platform:

aimed at developers: no proprietary templates, just GraphQL, JAMstack, Next.js and modern front-end tools,
simple integration: teams don't need to focus on integrating various platforms (like CRMs) or tools and can just rely on the GraphQL API,
frontend freedom: it's entirely up to you how the frontend looks, you can write a client from scratch using the language or platform of your choosing or you can use use the default PWA storefront or JavaScript SDK,
decoupled presentation layer: the frontend is separate from your core business so you can manage any number of stores, apps, and devices from a single back-end.

Source: aleor.io

Is it for me though?

As always choosing the right platform depends on your particular situation and needs. If you just want something, which will make working a bit easier for sales people with no knowledge of coding a CRM is still very useful. But things tend to pile up over time, so if it's a bigger project you might find yourself using a bunch of makeshift integrations down the line (of which not all are free). That might prove problematic in case something stops working and will take additional time to get a hang of in case you bring new people in. Saleor is a solution that can help you with that as it keeps everything decoupled. Sales people work on the CRM platform, devs work on the GraphQL API and customers just see the end result. The only drawback is you'll need someone who knows GraphQL to make use of it.

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz

Speed up your GraphQL API development

GraphQL Editor - the journey from initial release to version 5.0

Tomek Poniatowicz — Tue, 07 Dec 2021 11:57:24 +0000

From the very beginning of our adventure with GraphQL, we were impressed by how great its community is. The amount of content, libraries and great tools generated by GraphQL users amazed us from the very start. The more time we spent working with GraphQL the more things we saw that could be improved to make working with it easier and better. We also knew that we wanted to give something back to its wonderful community.

The origins

Three years ago we were working on quite a schema with a lot of complicated relationships, then a thought occurred to us:

"It would be nice to be able to visualize it well enough to understand all the connections."

Yes there were several solutions on the market that would let us do that, but hey everyone knows how it works. The question always arises, why not do it differently, better, and most importantly in our own way. A few days after saying:

"OK, lets do it"

came

"What if we could build a GraphQL scheme out of visual blocks?"

and that's how it all started. We begun with the PoC version, which included just these two functionalities, namely:

GraphQL schema visualization,
the ability to build it using viusal elements.


The very first version of GraphQL Editor from 2018

Our project has been very warmly received by the GraphQL community which resulted in quickly amassing 3 000 stars on GitHub. Users were not only happy to use these two simple features but also started suggesting some cool new ones. Users were not only happy to use these two simple features but also started suggesting some cool features.

What's new in GraphQL Editor 5.0

When we started we had a roadmap in mind which we tried to stick to, as much as it was possible. But with all the additional feedback we also kept adding features suggested by the community, which after more than 2 years has led us to the point we are at now, namely the release of GraphQL Editor 5.0.


Many graph improvements & various view modes

So once again we would like to thank all our users for their valuable feedback, including those that were critical, it all really helped us improve. So without further ado, let's get into the new features.

Microservices

It's the most exciting as well as the most requested feature. What's even more satisfying about it finally being released, is that, we've been trying to figure out how to tackle this one since the first release of GraphgQL Editor. GraphQL Microservices allow users instantly deploy their GraphQL backend prototypes using JavaScript or TypeScript. What's worth mentioning is microservices is powered by our open-source library called Stucco.

Stucco is a backend engine for our microservices. Its main goal is to keep you in charge of your infrastructure decisions. No risk of vendor lock-in, no worries. With Stucco you can use TypeScript, JavaScript or Golang to create GraphQL backends & deploy them easily using:

GraphQL Editor Shared worker
Local environment
Docker
Kubernetes

You can deploy microservices directly from our built-in Live Editor (similar to those you may know from Git-based platforms), but the recommended way is to do it using graphql-editor-cli. Although microservices are great for testing and development purposes, we do not recommend using them on production as they run on very small machines with rate limit of 200 requests per minute & 1 000 000 requests per month. Additionally this feature is very much work-in-progress and is being released mostly because we need live testers to iterate on it and improve it.


With Microservices you can deploy NodeJS GraphQL backends using JavaScript or TypeScript

JAMStack Engine

Although JAMStack was introduced a couple versions back, in this one it received a significant update. We have added TypeScript and the most popular JS library for building user interfaces support - ReactJS. Among other notable features you can find:

better ES modules support - j just give our Live Service a CDN URL & it will fetch all types from your server and also look for typings,
relative ES modules imports - now you can have user relative ES module imports inside our online code editor,
deployment - built-in static page deployment feature to easily show off your work to your team or a wider audience.


JAMStack with ReactJS, TS support & easy static deployment

GraphQL Cloud

We want GraphQL Editor to become a self-sufficient IDE for GraphQL based project development. Following this goal we’re adding more and more "responsibilities" for our tools. Now you can:

create your own queries with ease,
preview easily using built-in GraphiQL,
save & access your work anytime you need from any device.

We have also added a proxy to support every GraphQL URL & CORS issues which frequently appear during development.


GraphQL Cloud offers GraphiQL-like queries preview, configurable mock backend & CORS support

Last but not least

Aside from core features we have also been working on some quality of life improvements like:

Graph improvements - the graph module has been significantly improved:
- node & fields creation is now much faster thanks to keyboard support,
- relation view includes all scalar fields,
- selected node state persists between view,
- code editor view can be toggled anytime now,
Spotlight menu (CTRL/CMD + K) - spotlight menu added for easier navigation,
Color Themes - we have added 4 new color themes,
Learning center - from now on every start, you will be welcomed with recent projects and a learning center to level up your editor skills,

as well as tons of bug fixes & minor UI improvements.

So that's basically what we've been working on for the last 12 months. I must say it feels great to be able to finally share all these new features with a broader audience (thanks David!). If your are using GraphQL already I would love to hear your feedback, if not I hope GraphQL Editor would make working with it even more efficient as:

If once you start down the GraphQL path, forever will it
dominate your destiny.

Speed up your GraphQL API development

Neo4j GraphQL Library 2.0.0

Tomek Poniatowicz — Mon, 27 Sep 2021 11:03:20 +0000

A while ago I wrote a bit about the GRAND stack, an integration of GraphQL, React, Apollo and the Neo4j Database. While working with the stack carries numerous benefits (and hey if you’re curious about those head on over and read about them here) it can be a bit overwhelming to get straight into it if you’re just starting out. So this time let's just look at the integration of the ‘G’ with the ‘N’ and with good reason as there is quite a bit of new stuff to check out there.

From GRAND to .js

The GRAND stack has made use of combining the strengths of the Neo4j database with GraphQL for a while, but the team at Neo4j wasn't resting on their laurels and has been hard at work to improve on the benefits of combining the two technologies. In 2018 they released a library neo4j-graphql.js, a GraphQL-to-Cypher based query execution layer for Neo4j and JavaScript GraphQL implementations. To put it short, something that gives you a fully functioning GraphQL API backed by Neo4j just by using type implementations from the GraphQL schema. The library was very useful and quite popular so it's not surprising they decided to build on that.

Beta and 1.0.0

In early april of 2021 the Neo4j team announced that after a year of hard work they’re releasing a beta of the Neo4j GraphQL library. Since then they’ve only picked up the pace with the full stable 1.0.0 release coming in that very same month. Even at just a glance the features look pretty enticing

Automatic query and mutation generation for CRUD interactions
Object Graph Mapper for programmatic interaction with your GraphQL API
node and relationship properties support
custom resolver support
multiple pagination options
authentication and authorisation options with additional access control options

Onto 2.0.0

Continuing with their blistering pace, neo4j dropped version 2.0.0 of their library on august tenth. While you could say that on the whole this library is a replacement or rather a continuation of the neo4j-graphql.js library with the sheer number of features it has far surpassed it. Aside from the usual stuff you can expect from a 2.0 update like bug fixes or performance improvements we have a few completely new features:

relationship properties: This is the star of the show, adding relationships to your type definitions provides way more context for your data. This way when fetching data you will have a much clearer picture than you would with just disconnected nodes. This solution combines rich and interconnected data with the transparency of GraphQL letting you easily build apps even when using quite complex data sets.
Cursor-based pagination: on relationship connected fields in your schema you’re able to use cursor-based pagination which is especially handy for infinitely scrolling apps
Count queries: if cursor based pagination is not your thing you can now use a simple query for counting all user nodes

GraphQL = easy on the eye

That’s not all, the update also provides improvements to union relationship fields, more comprehensive validation of type definitions and various bug fixes. On the whole the key thing is still utilizing how good GraphQL is at displaying even complex data and relationships is probably the best way to take full advantage of that. Even if that doesn't convince you, with how quickly the development is going on this particular library, you can be sure a lot of additional features will be added very soon.

Oh and make sure to check this video presenting Neo4j GraphQL Library in action:

A guest blog post for GraphQL Editor blog by Michał Tyszkiewicz