Simple

The idea of maximum productivity encompasses all aspects of the Saas development and deployment. S8 brings a certain number of radical changes to make this it 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. But have no fear! All the gory aspects of traditional JAVA project development have been left behind, to leverage only the very best of language: JAVA core. It’s even more than that: JAVA comes with a lot high level functions that require expert level team to master, but regarding this, we just ask our user not to use them and to use JAVA as a simpler version of TypeScript.

Booting fast

S8 marks a clear cut with traditional web-app deployment on JAVA server (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 it. This drastically reduces the development cycle by enabling super frequent test in real world testing environment. This is especially true for apps with advanced graphics where the entire db-back-front is required, even to play unit tests.

Single man orchestra

Ok, this is wild. But that’s how we built it. 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 squeeze all the {params, configs, scripts} around to just focus on app development. S8 enables to have your server life from any simple JAVA environment. We broke the rule of having two servers, one server dedicated for the back and another one for the front, and merged everything into a single stack, for the sake of simplicity and efficient project management.

Secure

Zero dependencies

While open source supply with 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. The number of those dependencies is out of control for most organizations and this results in random highly critical incidents. With open sources modules deeply nested inside layers and 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 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 a serenity for creator, 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 time. You leverage performance improvement of the entire stack effortlessly.

Multiple environnement, one API

Also, we have plans to build even more aggressive of some module (in a JAVA sense) of current ones, and to propose them on future version. Having a high-level API enables you to take advantage of many implementations fine tuning with the same codebase. It provides a stable environment, just as JVM provides a standardized coding environment over different machines.

The flow

The key concept of this stack relies on the flow. The flow let 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 embedded 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 prevent congestion and enable 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 have by default the possibility of working with three types of databases, and build as many tables, objects on the fly.

Annotations

Objects persistency relies on annotating object classes -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 with efficient table-like list of objects you can search through or retrieve through id, effectively mimicking the core features of NO SQL 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 represent the data of a big project, including hundreds or even hundreds of thousands 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 deiffrenet 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 a app that will run on 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 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 the following:

• High compression throughput
• Natural caching strategies of large objects on the front, operated from the back.
• Radical speed improvements when switching of 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 login cluster. And so on. Each node being able to perform the entire set of tasks required by the applications enables a smooth and arbitrary large scale up.