Open Source

A change is coming: decoupled Open Social

After adding a new fresh design as extension it is now time to freshen up our — continue reading
Posted by Ronald te Brake
June 18, 2020

After adding a new fresh design as extension it is now time to freshen up our back-end to make it future proof as well. But what does this mean and, more importantly, what does this mean for you as a current (or future) Open Social client.

Where do we stand right now?

At the start of 2020, Open Social is still very much built using the traditional monolithic architecture model. This basically means we have our back-end and front-end coupled, making the authoring and delivery capabilities of the content of your platform part of the same system. Working off the same application, developers and content managers make adjustments to the data, configuration, and content while users interact with the front-end. But everyone is experiencing, viewing, and interacting with and within the same system. Below you can see a high-level example of what this looks like


As you can see it is one package that contains everything you need out of the box for a fully functional Open Social installation.

Which makes it:

  1. Easier to deploy, host and maintain: It’s only one package you need to keep an eye on and put on a server. This codebase will ensure that it grabs everything you need to roll out an all-in-one solution.
  2. Easier to do end-to-end testing: You can implement end-to-end testing by simply launching the application and testing the UI with existing tools like Selenium.
  3. Relatively easier to adopt development: Having one codebase where your code is running,  based on Drupal without many different tools or techniques, should make adoption simpler for Drupal developers.
  4. Simpler to scale: This usually means scaling horizontally, by running multiple copies behind a load balancer for example.
  5. Allows using Drupal’s functionalities: You get access to all modules Drupal and it’s community have to offer with a single click because our package also controls the front-end.

The last point is one of the deciding factors on why we started using Drupal in a coupled way in the first place. Our package ships with its core and a set of required contributed modules allowing all of us to benefit from all the hard work the Drupal community has put in. Opportunities like inline editing, drag and drop block placement, live preview rendering of your content, easy to use SEO offerings. All of this is available at the click of a button because of the above approach. The only thing left is coating it with a custom layer of Open Social and making sure we integrate it into our product. This allows us to match the look and feel and user experience expectations of Open Social users and clients.

With this in mind, it becomes apparent how Open Social has leveraged the powerful technology and community of Drupal to really kick-start its development and become a top open source Drupal distribution choice for online communities thanks to all the features and flexibility it provides.

Working like this has been very helpful for us for many years. But we have reached a moment in time where the drawbacks of this architecture style have caught up with us and our customers and we want to match the expectations that we all have of a continuously improving online community software solution.

Innovations in online experiences have accelerated in the past years, allowing us to present our data on multiple channels in a beautiful, silky smooth, user-friendly, accessible, and performant way. This has become the de-facto standard. Everyone expects instantaneous reactions, real-time updates, exciting engaging functionalities fully immersing you in all the great things the cloud has to offer.

At Open Social we see this as well: requests for real-time chat and collaborations, video conferencing, expectations of the latest integrations, native apps and push notifications, real-time updates in the stream, and more.

As a result of all these expectations headless and decoupled architectures popped up as an ideal solution and we have made the decision to move in that direction as well.

A headless application has nothing to do with ghosts. It merely means that the user-interface layer or front-end, which is referred to as the “head”, is decoupled from the back-end data repository and functions known as the “body”.

A headless or decoupled architecture will consequently allow us to:

  • Develop independently and focussed: By separating concerns amongst the front- and back-end we can develop and release our features whenever it’s ready.
  • Reduce barriers to adopt new technologies: Without having the front-end coupled to our back-end, and vice versa, it will be easier to adapt to the newest technologies. This will empower everybody to make use of the latest rich and interactive elements for the best user experience.
  • Scale services independently when necessary: Decoupling will allow more resources for the back-end, front-end, search or logging services. This allows for more flexibility in what to scale.
  • Open up to more integrations and external channels: With data being available over API’s but also opening up our back-end to allow for data to be changed we can serve a much wider range of channels and integrations.
  • Improve the back-end abstraction and design: A tightly coupled application meant that we didn’t always make the right decision on where to apply business logic. This is a moment to revert and improve that process for better business and development solutions.

What will the future look like?

We are planning to shift into the Decoupled gear, but we will do so gradually. This means that we will be going progressively decoupled at first. This requires us all to shift in our mindset. All the work we do should now be considered as if we are developing API first. The data should become available over endpoints in the format we expect it to be. We will remove or move a lot of the business logic done in the presentation layer to ensure the end-points also take this logic into account.

We will still support our front-end, including all of the templates and styles. However, this approach might change a bit over time. We might open source our front-end theme as a separate theme on Drupal to allow for a better decoupled situation,  similar to vartheme or thunder_admin. If you are part of our open source community, this will give you more possibilities, opportunities, and responsibilities on the coupled front-end so that you can still have a coupled or progressively decoupled option while we focus our back-end on becoming an API first headless application.

Progressive decoupling

With our design elements open sourced and improved developer documentation, you should be able to use Open Social in a coupled way. With your front-end connected to our back-end. Writing your own presentation logic and templates and styles if necessary.
You might use Open Social as a headless back-end, writing your own decoupled front-end(s) on top of this.

We believe this flexibility will be beneficial for everybody but we want to make sure we stick to our open source promise.

Our promise

Whether we provide you with a headless or a progressively decoupled Open Social installation is something we are still investigating. But we are giving you our promise that we will ensure the product itself is still available as open-source, featured, Drupal-based community software and with this you are still able to get a working community out of the box. What it will look like, we are not sure yet.

We are very much open to your feedback and super excited about all the possibilities this opens up for us. We hope you are too.

Do you see any issues or do you have helpful tips, wishes, requirements? Let us know and let’s see if we can make this transition as smooth as possible.


In this article we discuss

Related articles