Forem: Matt Anderson

Building a no-code platform, continued...

Matt Anderson — Wed, 23 Sep 2020 11:08:08 +0000

I wrote an article recently that got a great response, especially given it was the very first article I'd posted on this forum, so thanks to those of you that gave it some appreciation! If you're coming to this article having not read it, I'd suggest you give it a skim-read for some context. I wanted to do a follow up article to coincide with the introduction of Yakety, a platform I built using the principles I'm about to cover.

The last article gave an explanation of how it's possible to use abstract, dynamic components to attach tangible components you have written to a page: dynamically. This article takes that one (small) step further by looking at the data side of things in a bit more detail.

I'll begin by reiterating that my central goal when developing this builder was to ruthlessly avoid something called coupling, everywhere and at all costs. For those of you unfamiliar with the concept of coupling, it's where you group data that doesn't really belong in the same group, usually out of convenience. This leads to the obvious problem of having to de-couple and extract data which, if you were to ignore the benefits of de-coupling, would lead to the dreaded spaghetti code and would require all sorts of "hacks" throughout your code. Not good. It's a well-known principle in programming that you avoid coupling where possible. I was intent on taking that to an extreme by de-coupling data that could arguably exist in the same group. You could say I was aggressively decoupling... Spoiler alert: The big problem you immediately encounter however is keeping a link between data that does eventually need to come together to produce meaning, keep that in mind.

I briefly discussed in the last article a pattern that I had decided upon using, where I make data extremely granular and highly specific, then pass it to the browser in a big batch, so that it is accessible from anywhere within my code. I had no real grasp of the end outcome, I just knew that if I stuck with this principle then I'd be much less likely to end up in a code cul-de-sac!

It's hard to pick a place to start in the code but I'll choose to run with how I store a page:

{
    "data": [
        "4af6738c-f7f3-11ea-adc1-0242ac120002"
    ],
    "blocks": [
        "4af6745e-f7f3-11ea-adc1-0242ac120002"
    ]
}

What you're looking at there is the definition of a page. The data key stores an array of references to top level components. The blocks key points to an array of all components that are required on the page. This was a key decision, I could have stored subcomponent references against their parent components, but that would have led to really messy code and given, as I discussed, my strategy is to make all components and data accessible anywhere, this would have been unnecessary. All the page needs to define is the data that is needed and the same goes for each component, it just requires references, a definition. So the page definition plays an important role in defining all the data that is required to render the page. There are convenient opportunities that arise here in caching, manipulating the order of references, switching out references with new references etc. etc. I'm not saying it's without issues but it's a pattern worth thinking about for sure.

Let's assume the data and blocks data is parsed (server-side) and that leads to fetching the data needed to render the page. The data might look like this:

{
   "type": "s-hero",
   "slug": "4af6738c-f7f3-11ea-adc1-0242ac120002",
   "data": [
      "4af6745e-f7f3-11ea-adc1-0242ac120002"
   ]
}

{
   "type": "s-title",
   "slug": "4af6745e-f7f3-11ea-adc1-0242ac120002",
   "title": "Hi"
}

As explained in the last article, all that will happen is the dynamic component will loop the data array in the page definition then, in a recursive manner, it will render a hero component that itself will loop its own "data" property. The data it needs however, is not present within the hero component definition. It is accessible however, it has been attached to the browser window, as have all the definitions required to render the page, so the component just reaches out for the data it needs using the reference, finds it references a title component and renders the title using the data definition.

Voilà.

Sure there's some overlap with the previous article here, but the key concept I'm highlighting is one of decoupling your data. You don't have to choose the method I've employed to the letter, it's something I've devised completely on my own so there could well be a much more intelligent way to achieve this outcome. However, if you choose not to decouple your data to this extent, then you are risking causing some real coding headaches further down the line in the development process. I've encountered quite a few landing page builders that have been developed by either one person or a small team (not that this mistake is limited to small outfits, not by a long stretch!) and you can see from the example landing pages they exhibit that they are extremely limited. You're really tied into a set of templates with a very rigid structure. That's a result of diving into coding, taking easy decisions without giving due thought to consequences that will arise and so on.

I'll stop there. I'll decouple this article from other related discussions I could have around this subject! I hope that wasn't too painful to digest and that you learnt something useful. If this proves useful for people I'll keep going.

Keep it real.

Matt

PS If you would like to learn more about Yakety or get involved in building the platform, then drop me an email: matt@yakety.co.uk, register on the site, find me on social media, there are lots of ways to get in touch and lots of development tasks to get stuck into for all levels of ability (and non-development tasks for that matter) so please share this with your friends!

Yakety: A new way to develop systems.

Matt Anderson — Tue, 22 Sep 2020 16:39:22 +0000

Hi everyone, I'm Matt. I want to let you all know about a platform I've developed: Yakety (to "yak" is to talk, the platform is about interaction..okay it was cheap, the domain was cheap).

I was tired of learning/ hearing about these "no-code" web builders, Shopify, Wix, Webflow, all of them. I've been a web developer for 10 years plus and the idea that you can sit an individual (even one that has some development experience), in front of a computer and they can create something of value in its entirity, alone, without assistance, is to me well, off-the-scale crazy. As far as I'm concerned, agencies appearing all over the place to build websites and systems using these "no-code" tools is testament to how far fetched the claim of "no-code" development really is!

That isn't to say that I thought it not possible to improve the environment in which we develop systems. I wanted to build a tool that takes a more realistic approach and I'm not talking about a slight change either, more a hard refresh!

After a lot of consideration, I decided that centralisation and collaboration * was the only serious route to improvement. Something akin to a halfway house between DIY and calling in the professionals. It struck me that, alongside the rise of no-code-site-builders, a lot has happened in the world of social media and interaction on the web in general, whether it be video calls, AI chatbots, pinging each other DMs etc. So my aim was to do something that combined those two fields, development and interaction, with a view to creating, wait for it... an interactive development platform. See what I did there? Nice.

I was also keen to give that idea some structure, so I looked to the likes of GitHub/ Lab, and incorporated some project management into the mix, something which I felt was vital to keeping everyone involved on the same page or at least giving them the chance to get to the page that everyone else is on. "Real" development is complex after all, even for developers, let alone people from a non-technical background (and I really want those people to be involved because it takes a special person to be gifted with development and systems design and marketing and, you get the idea). All people involved with web related work have a significant part to play, otherwise their job wouldn't exist.

So I basically took inspiration from (my lawyer has helped me with the wording of this sentence) a load of platforms and put together a melting pot of features to facilitate development (could I have just said that, okay possibly). The result is Yakety.

It's all a bit of a mess at the moment as you will see if you choose to visit the site, but (hopefully) you can see some potential in what I'm trying to achieve and come on board with me (and anyone else that chooses to sign up for that matter, that's the idea after all). Another, facet(?) of Yakety is that people are encouraged to develop the core platform, not just by improving the core codebase itself, but also by building their own projects atop of it in order to progress the overall capability of the platform and drive it to new territory. So whether you have a great idea for a bespoke, headless eCommerce store with Shopify or you want to create some cool web app that uses WebRTC, well instead of doing that alone, why not come and develop it with us? If you don't have a groundbreaking idea and just like the idea of developing a production grade platform alongside other developers and web professionals then that's great too.

I hope that's convinced you to try out the platform. I'll reiterate one last time that there is a lot to do all over the place, from marketing to SEO to data structures, you name it, involvement really is open to anyone. Thanks for reading and if you're interested in having involvement by all means register but also email me or jump on the live chat (contact page) and we can discuss where your skills fit with the development that is required.

Matt

*At this moment in time. I can foresee a situation where "the platform" generally speaking, develops to the point whereby "sub-platforms" are spawned and things become a lot more sci-fi, but for now yeah I'd say we're at the centralisation and collaboration stage!

Using Dynamic Components And a Pattern I Devised Myself to Create a No Code Web Interface Builder

Matt Anderson — Fri, 14 Aug 2020 14:20:49 +0000

About two years ago I discovered VueJS, around the same time that “no code” solutions began to hit the shelves. I say I discovered Vue, I’d played with Vue, creating the ToDo list app (as you do/ did), but somewhere (I can’t remember where exactly) I encountered the dynamic component and this set me off on a two year journey developing what has now become yakety.co.uk, an interface builder that connects to APIs and cloud services. This article explains how the pattern I created allows for infinitely complex web interfaces to be developed, quickly, easily and using any back-end platform (as it is completely front-end driven).

Quick intro to Dynamic Components

For those of you that aren’t aware of them, may I introduce: Dynamic Components:

<component v-bind:is=”currentTabComponent”></component>

To quote the Vue docs:

Sometimes, it’s useful to dynamically switch between components, like in a tabbed interface.

This was a virtual apple dropping on my head. I saw an opportunity to use this component to create something I’d wanted to create for a while but was beaten to it: A Medium.com style editor. I’m a competitive person by nature so I thought to myself “I’ll still create an editor, only thanks to dynamic components, it will be better!”

I have no early versions to show you so you’ll have to make do with its current incarnation: https://yakety.co.uk/demo-article?edit

So "how does it work" you say? Read on.

1. Components

To build an interface builder the first thing you need are components. I decided to speed things up (he says, two years after starting work on this) by using Buefy, a VueJS component suite that uses styles from the (still quite well known in development circles I think?) Bulma.

You can add Buefy components into any project (that uses VueJS) like this:

<b-input type="is-danger" @input="handleInput"></b-input>

Which was a great speed gain, but I needed to have more (dynamic) control over the way these components look and behave so (out of pure necessity) I created a wrapper component, the template for which looks something like this:

<b-field
  :label="items.label"
  :message="items.message">
  <b-input
    :value="items.value"
    :name="items.name"
    :type="items.subtype"
    @input="handleInput">
  </b-input>
</b-field>

I named this component s-input to avoid a clash, then I looked at how I could fetch and set the properties from the server.

I must also mention, I had this idea that all the data required for the page would be fetched all at once and made available to all components by attaching it to the window object in the browser. That felt like a necessity in order allow the dynamic component to be well, dynamic. I wanted all the components to have access to all the data they may need so that I didn’t box myself into a development corner further down the road.

So here’s what I did (minus the endless trial and error).

2. Server

As with most web applications a page request is made and it hits a controller.

The objective here is to get all the properties required for all the components you wish to display on a page. So using the URI which for the Demo Article example link above is simply demo-article we run a query that fetches all the component properties for that particular route.

Let’s say we want to display an input and a button. In the most simple example, the query could return the following JSON:

[
  {
    "is": "s-input",
    "type": "text",
    "name": "Some input"
  },
  {
    "is": "s-button",
    "text": "Click Me"
  }
]

Then in a component dedicated to displaying other components (by using the dynamic component), we can loop this data and display our actual components:

<component
  v-for="(item, index) in components"
  :key="index"
  :is="item.is"
  :properties="item"
>
</component>

:is="item.is" tells the dynamic component which component to display.:properties="item" prop is used to pass the properties to the component, thus determining its behaviour. And of course, the loop is iterating, in this case, over the two JSON ‘blocks’ as I call them, so we have control over a linear flow of components, just like Medium.com's editor and voila:

That is as simple an explanation as I can give to the underlying pattern I used to create interfaces with Yakety. To create more complex interfaces involving columns and heavily nested components would take much explanation and I don’t want this to turn into War and Peace so I’ll stop there for now. If there is sufficient interest then of course I will develop this into a series in which I target specific parts of the pattern that are harder to explain and give you the recipes for developing your own dynamic interfaces, interfaces that are controlled entirely from a database. Which brings me to the last part of the article…

3. Database

The biggest takeaway from what I have achieved here, isn’t the use of dynamic components in VueJS (although that is pivotal to the whole pattern working). The major discovery I made, was to allow for the construction of an entire (or partial) interface using only a database and a bunch of components that, for the most part, are empty shells or vessels. This removes the need for both large (and multiple) templates and logic heavy controllers.

Just think of the possibilities that have opened up (or view Yakety and see to see some of the possibilities I’ve thought of, in action). Here is a summary of things I have considered:

You can store and therefore manage styles using a database
You can store and manage behaviour using a database
You can see in an instant which components exist on a page
You can easily switch the order and location of a component
You could theoretically present different components to different users
You can allow for the creation of content and functionality using a no code solution for non-technical staff
You can duplicate, update, edit and so on, entire groups of pages or target properties of individual components with ease (you even have the power to do this with a script!) all thanks to your page being defined in a database rather than a file
The whole pattern is completely platform agnostic. I use VueJS and Laravel. What’s stopping you from using React and ExpressJS?
Perhaps there are even more benefits that I just haven’t thought of yet (let me know in the comments if you have other ideas about potential uses for the pattern)

I’ll stop there. As I mentioned, if I’ve been overly brief and you would like more detail, just leave a comment and I’ll be happy to expand on anything I’ve said either in a reply or, if the question warrants it, further articles.

I hope you have a good play with Yakety and enjoy using it. I look forward to hearing your thoughts and suggestions.

PS In case you’re wondering, the whole codebase is currently sitting in a private repo. I will eventually get around to making it public and I’ll write some documentation to accompany it.