A modern setup for digital products.
My team and I are often asked to explain how the digital products we build at Eli5 (a digital product building company) actually work and are set up. So I decided to write this article to explain our current approach on setting up digital products.
There is a giant knowledge gap between software development companies and their clients.Many of these software companies abuse this gap and take advantage of their clients; others have good intentions but feel misunderstood. From the very start of Eli5, it has always been our goal to bridge this gap (hence the name).
I’m writing this piece from a high level perspective, trying not to get too technical. I’m aware of the fact that some explanations are a bit too simplistic from a technical point of view, but the goal here is to explain the concept to people with potentially no technical knowledge on digital products. If you have any comments, or perhaps additions, please let me know. It would be great to improve this together.
Definitions
Before we dive into the setup of these products, I want to take you through the definitions of some of the terms I use in this article. This is crucial to ensure a correct explanation of the topic. However, feel free to skip this part for now and scroll back up when you need to.
Single Page Application (SPA)
Whereas it used to be normal to reload pages to show new information on your screen, SPAs now enable us to dynamically rewrite the page users are viewing. This creates a smoother user experience where users are not interrupted by loading pages to view data they have requested.
Nowadays, numerous Javascript frameworks support SPA principles — the most commonly used are React and Vue.js.
Application Programming Interface (API)
An API is a communication protocol between a client side application and a server side application. See it as an interface between your user interface and database. Or as a middle layer between your front-end and back-end. Further down this post it will become clear how this works.
Client-side
Client-side means the side of the user (client). The user interacts with your system via a client-side interface on their device, which can be via an internet browser, a mobile app, or an application for a desktop device (laptop, computer). The SPA we mentioned above is a client side interface.
Front-end Application
In this context a front-end application is a Graphical User Interface (GUI), which enables the user to interact with your system. The front-end application can be a platform or web application running in an internet browser, a mobile app, or an application running on a desktop device. A front-end application is always located in the client-side part of your digital landscape.
Front-end Developer
A front-end developer programs the code for applications that interact with your users. He or she converts the static user interface designs to a dynamic user interface, and enables the front-end to talk to the back-end when needed. The front-end developer also makes sure that the application works smoothly across a range of devices and that errors from the back-end system are communicated to the users in clear and understandable language.
Integration Layer
The Integration Layer is a central layer that can be connected with both your end-user solution (client side) and potentially your existing digital infrastructure (server side). The layer orchestrates and aggregates data from multiple connected systems, meaning you have one central point that orchestrates all connections instead of a spaghetti of APIs. The Integration Layer also enhances the security of your digital landscape. It only exposes the data that is necessary and it reduces exposure and security risks due to the loss of multiple access management and point-to-point connections. Next to that it is only available for systems and users that have been given access.
Server-side
Server-side refers to the application running on a server and the database. Within the server-side application of your digital product, most intelligence is written and data is stored. This allows us to connect multiple client-side applications (i.e. a mobile app and a website) to one server-side application; all have the same functionalities and show the same data but are tailored to your user’s device.
Back-end Application
A back-end application is the part of a product where most intelligence is located and is situated in the server-side of your digital product’s landscape. In short, a back-end application pulls data from a database, processes it, and sends it to the front-end application to be viewed by your product’s user. After the user has interacted with the data, the front-end application send the data back to the back-end application, which then processes this data again and stores the data accordingly in the database.
Back-end Developer
A back-end developer primarily develops and maintains the core logic of a digital product, which is the technology situated on the server-side. The systems they develop are delivering the data and services needed by the front-end application to enable users to interact with it. Next to the core logic of product, back-end developers also create databases, build integration systems, write APIs, and have a certain level of expertise within technical architecture of a digital product.
A modern approach on developing end-user solutions. Separating back-end from front-end.
Now that you’re up to speed, let’s get into it. Digital end-user solutions come in many shapes and forms. At Eli5, and along with many other forward thinking product building companies, we build solutions according to modern standards and today’s best and most common practices. This means we develop applications and platforms as Single Page Applications (SPA) with separate front- and back-end applications, which thereafter are connected by APIs. The pros of this approach are significant. Let me quickly take you through the main advantages.
Scalability
Separating front- and back-end means it’s easier to scale up your product with new client side solutions (ie. When you started with a web application and want to scale up by adding an iOS and an Android app). A stand-alone back-end solution allows you to connect as many client side solutions as you like via an API.
Improved user experience
Because the back-end application is running on a server instead of in your user’s browser, it enables the front-end application to provide the user with a more seamless user experience, dynamically pulling data from the back-end application without the need to load a page every time your user’s requesting new data.
Develop faster
Because the codebases are separate, dedicated developers can work on the application which they are trained for. A front-end developer works on the client side products and a back-end developer works on the server-side products. Both developers are less dependent on each other. They can test their own code, fix their own errors, and deploy their own application without needing to wait for each other.
Pivoting in tech is easier
Let’s say there’s a new framework for your front-end application, which enables significant improvements to your product. Because the front-end is built completely separate, it’s easier to build a new front-end product with this new framework and connect it via the same existing API to your back-end application. The same counts for the back-end.
Modularity
Another big advantage of separated codebases is this approach enables modularity. In both the front-end and back-end applications we are able to create modules. To give you an example, this way multiple front-end devs can work on several parts (modules) of the front-end application without the risk of messing up another developer’s code or overwriting it.
So what does this look like?
The setup of your system depends on the size of your digital products, amount of client side products (web app, iOS app, Android app, etc.), and other 3rd party digital services/products you’re using.
Simple set up — Early stage product
We will start with the most simple setup. Let’s say you’re building a web application (for internet browsers on desktop and mobile) and you build this product according to the approach mentioned above (separate front- and back-end). The setup of your system would be like the image below.
Both applications have separate codebases. The front-end application can send data to and retrieve data from the back-end application by talking to it through the communication protocol on top of the back-end, the API.
Adding new client side interfaces
Let’s say we want to take some steps to serve your users even better, by creating more interfaces for them which suits their needs in more situations. A good example for this is Slack. Slack serves their users via multiple client side applications. They have a web application, a mobile app for iOS and Android, and they have desktop applications for macOS and Windows. All of these client side applications communicate via the same API with the backend applications.
Because we use a separate front- and back-end you connect add as many client-side products to the same back-end without having to touch the back-end application.
Taking it to the next level of connectivity
The previous examples have demonstrated the benefits of building your back-end and front-end applications separate from each other. As further you go down the road of improving your product, the more you will benefit from this approach.
Your product has survived the first stages of its life cycle and you’re seeing more and more opportunities to connect your product to third party products.
To enable you and your product to take advantages of all these opportunities, we add an integration layer to manage all connections. This is a secure and scalable way to connect not only to your own applications but also to external applications.
The Integration Layer is a central unit in your digital landscape. All access control to any of your applications will need to go through the layer, which reduces exposure and security risks to your applications due to the removal of multiple access management and point-to-point connections.
The integration layer orchestrates and aggregates data from multiple underlying systems, which means you can focus completely on functionalities and exposing only what is necessary, without the need for each developer to understand all the underlying systems completely.
The layer also enables detailed insight into performance, access logs, issues and much more to give you governance over your exposed data.
The integration layer in action.
Let’s say your product is an online proposal tool and it would be very beneficial for your business to enable third party invoicing software tools to connect to your product, so you can attract more users.
Another thing you want is to connect your CRM tool (ie. Salesforce) with your back-end application so you don’t have to manually put in the necessary administration regarding accounts or invoicing.
The image below will explain to you what this will look like.
Final words
I hope this post has helped you understand our approach to developing digital products. This is the first version of it and I want to keep updating this over time. If you have any questions or suggestions on how to make this explanation better, feel free to reach out to me at wesley@eli5.io.
Have a great day!
