Forem: Graftini

Now deploy no-code projects using provided templates in Graftini

Sharad Chand — Wed, 11 Aug 2021 13:01:10 +0000

It can be tedious to create a new project from scratch and to work on it. As a solution for that, we have introduced creating projects from templates.

The following video highlights how you can get started with templates.

We will be adding more templates for the most popular use-cases that you have. So, stay tuned.

Graftini is an no-code SaaS to design and deploy dynamic web apps without having to write a single line of code.

Announcement - Graftini Early Access Release

Sharad Chand — Thu, 29 Jul 2021 07:03:31 +0000

Today we touched a significant milestone. We have been hard at work to move a step closer to our dream of not having to write code for deploying dynamic web apps.

We are releasing the app to the first batch of early access users 🎉. We are extremely psyched yet nervous about it.

The story we would like to tell via Graftini can be summed up in the following three steps:

Think
Design
Deploy

There should not be any extra step involved in bringing an idea to reality. An idea leads to a design which should immediately be shareable for the world to see. No more should there be a lag between design and code.

This is only the first of many iterations to come to the public. With Graftini, you can now:

Build static web apps that can be designed with an intuitive visual builder.
Images that are optimized by default so that the users get an optimized experience.
Deployments that do not take more than a minute.

To try it out, we are offering all our users 2 free projects for the duration of the Early Access (and possibly beyond). These come with the following perks:

10 GB Monthly Bandwidth
Unlimited Pages
Unlimited Deploys
Free Subdomain

We cannot wait to see what you build with it. Cheers to everyone.

If you already have access to Graftini, you can now login here. If you do not have access, you can request for it here.

Note: Since this is early access, there will be bugs that we will be fixing as it comes along.

How to change numeric input by dragging in React?

Sharad Chand — Tue, 29 Jun 2021 12:05:14 +0000

The above GIF is one of the interactions that I love about Figma . To change the position of an item, I do not have to use a keyboard at all. Just a mouse is enough.

So in this article we are going to create a numeric input field whose value can be changed by dragging on its label from scratch. We needed this for Graftini because we think a visual tool should not require keyboard for most interactions.

If you are eager to see the code and try it out for yourself, then jump to CodeSandbox at https://codesandbox.io/s/drag-number-input-z2rnj.

Let us first create a simple input

We can start by creating an input which reads from and writes the values to a state. If you have already created forms this should be simple enough to understand.

function Input() {
  const [value, setValue] = useState(0);

 const onInputChange = useCallback(
    (ev) => setValue(parseInt(ev.target.value, 10)),
    []
  );

  return (
    <input
        value={value}
        onChange={onInputChange}
        style={{
          padding: 8,
        }}
     />
  );
}

We are creating a state which stores the current value of the input. This state will be updated when the input changes via the keyboard.

Now we need a label that fits right in with the input

We need the label to be an anchor on which the mouse interactions can be added. The input itself cannot be the anchor because then it will ruin how input fields normally are expected to behave. The code that captures that idea can look like:

<div
    style={{
      display: "flex",
      border: "1px solid #CCC",
      alignItems: "center",
      borderRadius: 4,
      fontFamily: "sans-serif",
      width: 300,
    }}
>
   <span
      style={{
        padding: 8,
        color: "gray",
        cursor: "ew-resize",
        userSelect: "none",
      }}
    >
      Count
    </span>
   <input
      value={value}
      onChange={onInputChange}
      style={{
        flex: 1,
        padding: 8,
        border: "none",
        outline: "none",
      }}
   />
</div>

The above code is just visual cosmetics. You can make it to look however you see fit. Now the input should look something like:

Adding mouse interactions on the label

We will extract the label into its own component to make it easier to write & understand the code. Then we will add three mouse interactions in it. One on the label itself and two on the document. Why? We will discuss it along side the code.

function DragLabel({ value, setValue }) {
  // We are creating a snapshot of the values when the drag starts
  // because the [value] will itself change & we need the original
  // [value] to calculate during a drag.
  const [snapshot, setSnapshot] = useState(value);

  // This captures the starting position of the drag and is used to 
  // calculate the diff in positions of the cursor.
  const [startVal, setStartVal] = useState(0);

  // Start the drag to change operation when the mouse button is down.
  const onStart = useCallback(
    (event) => {
      setStartVal(event.clientX);
      setSnapshot(value);
    },
    [value]
  );

  // We use document events to update and end the drag operation
  // because the mouse may not be present over the label during
  // the operation..
  useEffect(() => {
    // Only change the value if the drag was actually started.
    const onUpdate = (event) => {
      if (startVal) {
        setValue(event.clientX - snapshot);
      }
    };

    // Stop the drag operation now.
    const onEnd = () => {
      setStartVal(0);
    };

    document.addEventListener("mousemove", onUpdate);
    document.addEventListener("mouseup", onEnd);
    return () => {
      document.removeEventListener("mousemove", onUpdate);
      document.removeEventListener("mouseup", onEnd);
    };
  }, [startVal, setValue, snapshot]);

  return (
    <span
      onMouseDown={onStart}
      style={{
        padding: 8,
        color: "gray",
        cursor: "ew-resize",
        userSelect: "none",
      }}
    >
      Count
    </span>
  );
}

Now try running it up and voila 🎉🎊 you have your own drag to change numeric input.

It looks awesome doesn't it? Though the cursor during the operation does not look good. This could be something that you can fix. 😋

The full code is at CodeSandbox for you to try it out https://codesandbox.io/s/drag-number-input-z2rnj?file=/src/App.js.

Fork it & make improvements to it. Till then ✌️.

Rendering in an iframe in a React app

Sharad Chand — Fri, 04 Jun 2021 04:20:24 +0000

Sometimes you want to render a tree of components within an iframe. You may want to do this because you may be creating something like CodeSandbox that runs other people's code or developing a Storybook-kinda library to design & test components in isolation or you are building a visual editor for designing web apps likes us.

Whatever the reason may be, you would use an iframe for the following two features that iframe offers:

You want to isolate the styles between the parent document and the iframe document. Since the styles are inherited by the children because of the cascading nature of CSS. CSS stands for Cascading Style Sheets after all.

You want to sandbox JS used in an iframe for security. For example, the content in the iframe loads a script from an untrusted location.

As an initial effort to render a component within an iframe, I went ahead by writing the following straight-forward code:



function RenderingInIFrame() {
  return (
    <iframe>
      <MyComponent />
    </iframe>
  );
}

Codesandbox: https://codesandbox.io/s/render-in-iframe-1-eq4tn?file=/src/App.js

It rendered nothing 😭

Boy, to my surprise this did not work because iframe does not expect children. iframe is a nested full-fledged document so adding content to it would not be this simple.

So, I explored the ways that I could do it. The normal way to do it is to add the src attribute with the URL of the app that will run in it. Essentially you would be creating two separate React apps that run in different contexts. This makes it very difficult to share the state between these apps because JS is sandboxed in iframe. You would have to devise complicated setups to share the state and I am not going to explore that here.

Let us try another way that is simple enough, does not require two apps, and can share logic fairly easily. We will need to find a way to render the children within the body of the iframe.

That is where ReactPortal comes to the rescue. Portals are a way to render something virtually at one location and actually render at another. If you want to know more about Portals, you may read them here.

So, we need to create logic where we virtually render at the iframe's children but it renders within iframe's document body. So, here is my hack:



function IFrame({ children }) {
  const [ref, setRef] = useState();
  const container = ref?.contentWindow?.document?.body;

  return (
    <iframe ref={setRef}>
      {container && createPortal(children, container)}
    </iframe>
  );
}

Let me explain line-by-line. Here we created an IFrame wrapper that will render its children in an actual iframe. How we do it is:

Get the ref of the iframe by using useState rather than useRef because useState causes re-render when the ref is set.
We get the body of the iframe document and traverse with optional chaining because ref might not be readily available.
Then we create a portal that renders the children within the body of the iframe.

Now, let us try running the same example while using the newly created IFrame:



function RenderingInIFrame() {
  return (
    <IFrame>
      <MyComponent />
    </IFrame>
  );
}

Codesandbox: https://codesandbox.io/s/render-in-iframe-2-qgy4i?file=/src/App.js

Yay! it works 😃

You can pass in any children to this IFrame and it will work flawlessly. It works this way because the children are rendered in the context of the main app and DOM is updated via Portals. The event handlers on the components within the IFrame also work without issues granted that they are React's synthetic events. For ex:



<IFrame>
  <button onClick={increment}>Increment</button>
</IFrame>

Even though JS and events is not shared between the iframe and the main document, these event handlers work because React emulates the event mechanism using its own synthetic events. So any event that is caught by React will bubble up the tree. For the first time, I have found the why? behind React's own events and they are awesome.

Final Notes

Though you may now know how to render within an iframe by writing an IFrame wrapper from scratch, there is already a library that does this for you and has more features & use-cases built in called react-frame-component.

Hope this has helped you in some way.

Why we chose UUID over SERIAL in PostgreSQL?

Sharad Chand — Fri, 04 Jun 2021 04:15:29 +0000

At Graftini, while we were building schema for the database from the ground up, we faced an age-old question. Whether to use SERIAL or UUID as a primary key. In most of my previous works, I had used SERIAL and why would I not use it. It is fast, size-efficient, and more than anything it just works. Why over-engineer something if it works, right?

The General Problem (https://xkcd.com/974/)

To answer the question, let me tell you a little bit more about Graftini in the context of this article. It has users and projects that the user can create and manage. We created user-facing endpoints similar to /projects/{id} and /users/{id} which the user can navigate to and copy & bookmark. As such, the {id} also has an additional purpose other than being a primary key to uniquely identify a resource. It also has to be secure enough to be shared.

Why we chose UUID over SERIAL?

Because of the above requirements, SERIAL did not fit the bill. Since it is incrementing, anybody can easily guess the next ID and access a resource they were not meant to.

I do not mean to say that using UUID will automatically secure a resource. That it won't. UUID is never an alternative for well-built authentication and authorization. What UUID helps here is the perception that the resource is secure. It provides security through obscurity.

Another reason why SERIAL failed for this use case is that it leaks the meta-information about the system. For example: how many users are there? how many projects exist? This is something that I personally do not feel comfortable sharing with the general public. This information should be limited to appropriate stakeholders and the open internet is not one of them.

Using a UUID helps here because it inherently has no meaning. It is a random string of characters. You won't be able to project any meaningful information out of it.

Are we saying to always use UUID over SERIAL?

No, this post is not written to conclude that UUID is better. Rather we just wanted to show where UUID is appropriate. It is good for user-facing UI and where we do not want to expose any meta-information to the user. Whereas SERIAL is better where the user is not required to directly interact with it. We are using both of them where appropriate and it's fun that way 😄.

What about the slow performance of UUID compared to SERIAL?

I have never seen with my own naked eyes UUID being a source of performance issues. Most of the apps that I have worked with had issues with relation to I/O latency or network latency or memory leakage and never the database itself. From what I have read in other articles, UUID faces problems once it scales. And honestly, I have never worked on a project that has scaled to millions/zillions of users. So, if UUID becomes a performance bottleneck in our app, that would be an awesome problem to have.

Conclusion

All in all, choose whatever suits your requirements or whichever you are most accustomed to. If your requirements ever change in the future or your app becomes mighty popular, hopefully, you will have enough incentive to find a solution to your specific problem.

What is Graftini?

Sharad Chand — Thu, 20 May 2021 12:40:30 +0000

As developers, if we have to do a task, we try to do it in the most efficient way that we know of. Sometimes that means to do it manually. And, if we need to do it again, we oblige. But if we have to do the same repeatedly, the process soon becomes inefficient. And when that time comes, we find a way to automate it.

In our experience, working with clients and having to develop web apps for their specific problems has allowed us to explore new ways of solving them. Even in seemingly unique problems, we began to find repetition in the kind of solution we provided with regards to how we design, review, iterate and write them into code.

That is when it struck us that we need to automate the process. Imagine if we had a thing that lets us design a website using a visual editor, implement behavior without having to write a single line of code, and deploy it to production with a single tap of a button.

We began to scour the internet to find such a thing. We found tools that are tackling similar problems. But they were not able to express our use-cases fully.

Hence we created Graftini. A nocode designer that deploys your designs to full-fledged web apps.

Graftini is where there is no difference between designing and coding, where reviews are only limited to the actual design, and where devops is obsolete. The only task that a developer is responsible for is the design of a solution.

Request for early access to get an early taste when it's available. We are eagerly excited to see the kind of apps you will build with it.