Simple

The idea of maximum productivity encompasses all aspects of SaaS development and deployment. S8 brings a certain number of radical changes to make this simpler.

Language

First it proposes the development team to reduce to a single language JAVA, that — despite being seen as less hype than other new languages — is widely adopted, highly efficient but also very complete in terms of features. All the gory aspects of traditional JAVA project development have been left behind, to leverage only the very best of the language: JAVA core. We just ask our users not to use the expert-only parts, and to use JAVA as a simpler version of TypeScript.

Booting fast

S8 marks a clear cut with traditional web-app deployment on JAVA servers (Tomcat, etc.). S8 server-side boots in less than 1s on most environments, meaning you don’t care stopping and redeploying an instance anytime you want. This drastically reduces the development cycle by enabling super frequent tests in a real-world environment — especially for apps with advanced graphics where the entire db-back-front is required, even to play unit tests.

Single man orchestra

We wanted — day 1 — that S8 can be efficiently used to build and deploy a project with a record low number of people, so we squeezed all the params, configs and scripts around to just focus on app development. We broke the rule of having two servers, one dedicated for the back and another one for the front, and merged everything into a single stack.

Secure

Zero dependencies

While open source supplies valuable tools and features, it also creates uncontrolled dependencies from unchecked origins. Many incidents through two decades illustrated how easily a malicious contributor can inject vulnerabilities inside applications based on external modules. With open-source modules deeply nested inside layers of code, it becomes virtually impossible to guarantee a safe system. On top of that, any previously clear dependency can become malevolent through updates.

That’s why we decided to rebuild the entire stack from the ground up, carefully crafting and validating each of our modules. Therefore, we can guarantee the total absence of the traditional worms inside the code you will build on S8.

HTTPS and all the rest

We also implement HTTP2 and a TLS security layer with a somewhat restrictive inner policy to stay on the safe side.

Small

Small surface API is the key

Small surface API might be seen as a limitation. We see a strength: only key features are here, but all key features. This enables a fast learning curve, and an almost immediate kicking off. It also offers serenity for creators, when you know you sit on something that is taking care of fine-grain details, without having to spend time resolving problems — including integration problems — that have been solved so many times.

Multiple environments, one API

We have plans to build even more aggressive implementations of some modules, and to propose them in a future version. Having a high-level API enables you to take advantage of many implementation fine-tunings with the same codebase. It provides a stable environment, just as the JVM provides a standardized coding environment over different machines.

The flow

The key concept of this stack relies on the flow. The flow lets you access pretty much every feature of the stack in an asynchronous and unified way. The flow is the context against which you build the big lambda expression which is, in the end, your app.

Synced

One of the main obstacles into writing a scalable application is the proper handling of high concurrency through asynchronous task orchestration. Since this is a recurring problem, and a hard-to-solve one, we decided to embed deep into the S8 stack what we think is the best solution (and we have a high-level API that gives us plenty of room to make further improvements under the hood). Also, because the S8 stack is managing the server aspects, we needed to have this asynchronous engine ready to support the stack inner systems.

That’s why we designed a light-threads engine with a built-in thread workers pool along with a thread allocation mechanism that prevents congestion and enables high scaling up.

Storage

Every web-app relies at some point on databases. Moreover, the proximity with data is key to write easily complex treatment. Having noticed this, we came up to think that data must be served efficiently, seamlessly within the app through very simple accesses directly available in the flow. So every instance running on the S8 stack has by default the possibility of working with three types of databases, and build as many tables and objects on the fly.

Annotations

Object persistency relies on annotating object classes — the most robust approach so far. Access to objects is exclusively made through the call of methods on the flow, as well as all subsequent actions (saving, reverting, etc.).

Caching

Caching is a key part of performance, and one of the goals of S8 is to handle this seamlessly. As a result, you can make the assumption that data is always readily available since the caching will balance memory retention to reflect data usage.

Scaling and replicating

For the scaling-up versions, we will provide automatic synchronization of instances running S8 stack on our cloud to ensure that any modifications made to data contained on the databases of one instance are replicated to other instances, and efficiently handling copies to ensure a given requirement in terms of redundancy.

Structured

Key-value DB

Key-value db is probably the most efficient pattern to get data. S8 provides an efficient table-like list of objects you can search through or retrieve through id, effectively mimicking the core features of NoSQL-like db. For more advanced searches, selection with JAVA queries can be used.

Structured DB

Structured DB works with large objects, each representing a group of data you can navigate through points and methods. This group of data typically represents the data of a big project, including hundreds or even hundreds of thousands of sub-objects, but that belong to a same logical entity and need to remain grouped from a logical point of view (think of the plan of a building), even if you can traverse it easily.

Screen

One thing that makes SaaS so time-consuming to develop is that development is split between two realms, with different languages, logics, teams, deployment tools, etc. This gigantically increases the number of skills a team must master to deliver a webapp. So we came up with something different.

Your front as a remote screen

When you develop an app that will run on a local device (say desktop or mobile), things are much more simple: without exiting your development environment, you directly have access to all graphical components that come standard with the OS, and you can manipulate them in any imaginable way, even inside a deeply nested function. You don’t have to define an API between the back and the front so both can communicate. Everything is fused together, and that’s why it is so easy to achieve remarkable graphical complexity with minimum effort. We thought it was the way to go for SaaS as well.

Additional hidden benefits

S8 way of handling the front is radical: each graphical component comes as a JAVA realm object, that you can manipulate at will, and a ghost counterpart — that you never have to touch — that lives on the front side. Connection between both sides of the same entity is handled under the hood by S8. The tremendous benefits are:

• High compression throughput
• Natural caching strategies of large objects on the front, operated from the back
• Radical speed improvements when switching views of large objects (like opening the plan of building A, closing it, opening plan of building B, closing it and reopening plan of building B)

Scalable

Scalability is the long-time concern of every project builder. We designed the S8 stack to enable a natural and powerful way of scaling up: each node running S8 is a member of a cluster. It is a member of a database cluster. It is a member of lambda expression workers pools clusters. It is a member of a login cluster. And so on. Each node being able to perform the entire set of tasks required by the applications enables a smooth and arbitrarily large scale-up.