Yupiik Stack: deliver, deliver, deliver!
Yupiik open-sourced a set of tools targeting application development and deployment. It aims at simplifying the all the aspect of development focusing on productivity and efficiency. Let's have a look at the bricks it is composed of.
The challenge
Today's the backend development evolved enough to join the frontend in terms of velocity requirement. It means that you should be able to develop and deploy a backend services in a few days and not weeks or months.
Another challenge is the fact the consumers multiply the requests done to the backends. This means that the resources consumption is rarely optimised and it often adds a lot of latency (if you use REST model for example).
On another side, the cloud showed that security is a key requirement of any application.
To solve these challenges, it is important to simplify the development stack to ensure:
-
You control it
-
Any developer can work with it very quickly - simplicity is often more important than other criteria for the velocity to stay high in time
-
BUT you can still optimize and improve it when needed for very high throughput applications for example
The stack
To answer modern needs, Yupiik developed these bricks:
-
Yupiik Logging^ : a simple but efficient and flexible Java Util Logging binding, it is cloud oriented (docker/Kubernetes) but works well in standalone application,
-
And the cherry on the cake is that it is GraalVM friendly so you can make your application native and logging configured at runtime!
-
-
Yupiik Simple Configuration^ : a simple POJO based configuration binding
-
Keeps the configuration light and documentation friendly
-
-
Yupiik UShip^ : a light backend stack based on Apache Tomcat and providing a JSON-RPC programming model,
-
JSON-RPC enables to develop "commands" and optionally to bulk them, this stack allows to optimize bulk requests very easily with any custom push-down logic (execution plan)
-
Since it is command oriented, it is compatible with CLI application (reuse, reuse, reuse) and messaging (JMS, Kafka) applications.
-
-
Yupiik BundleBee^ : a light deployment manager for Kubernetes
-
It allows to test locally very easily with minikube, microk8s, ... but also to deploy to production directly with the same recipe!
-
-
Yupiik Tools Minisite^ : a maven plugin which enables to create a "mini-site" holding the documentation of your project.
-
It is generation friendly - so you can generate the configuration documentation or API documentation from plain code. Living documentation - the fact to generate all you can to ensure it is up to date - is a key target of this module/
-
It is also github pages or gitlab pages friendly and handles the deployment for you.
-
-
For frontend applications we tend to use React^ or Preact^ and esbuild.
-
React/Preact are light, way less complex, unstable and are more javascript friendly than recent angular or Vue.JS versions (even if this last one tend to copy others version after version)
-
Esbuild is insanely fast, easy to integrate with a backend mock if needed an totally defeats webpack as of today when you start from scratch.
-
@startuml
skinparam handwritten true
skinparam linetype ortho
skinparam packageBorderColor LightGrey
skinparam ComponentBackgroundColor White
package Dev #1845AA {
[Git]
[Java 17]
[Apache Maven]
[Yupiik Logging]
[Yupiik Configuration]
[Yupiik UShip]
[Yupiik BundleBee]
}
package CI #05BEFC {
package Package {
[Package Registry] <<maven-deploy-plugin>>
[Container Registry] <<jib>>
[Pages] <<minisite>>
}
package Test {
[Deployment Tests]
[Application Tests]
}
package Build {
[mvn]
}
}
package Environments {
node "Minikube" {
[Kubernetes (dev)]
}
node Preprod {
[Kubernetes (preprod)]
}
node Prod {
[Kubernetes (prod)]
}
}
Dev -r-> CI
CI -r-> Environments
Build -d-> Test
Test -d-> Package
@enduml
The application flow is as follow:
-
The application is developed with Apache Maven and Java using Yupiik Stack
-
The CI takes any incoming changes and validate them (with tests for the application code but also the deployment)
-
Once validated, the changes are snapshoted in a binary (artifact + OCI/docker image) pushed on CI repositories
-
Finally, the changes are deployed on the related environments (depending on the building branch)
-
It can be dev environment + Github Pages (doc) or directly production
-
Rational of the stack
Being JSON-RPC focused enables to have to focus on the "commands" which literally means your own business and not any technical concerns. Concretely it means that if you need to add a feature you just do by adding a command. It also encourages atomic commands and the caller/consumer to orchestrate the commands thanks to default or an advanced bulk endpoint. This is a big difference with REST: you do not need to do any custom hack to have an "N application requests over 1 HTTP request", it is built in and works with any language: C, Java, Javascript, Go...
TIP
|
it does not prevent you to optimise some bulk pattern when needed by replacing the multiple atomic calls by a single one if relevant later. |
Being based on HTTP and JSON it is quite easy to integrate with any technology, and it is quite optimised as of today.
Using living documentation, you always have an up-to-date view of your deployment, configuration (environment variables for example), etc... No more "but in the documentation is not this name".
Finally, everything is testable, even the deployment, avoiding most of the surprises you can get at any stage of the pipeline.
Get started
If you are lost you can get started with a small generator^ .
You pick the features you want to it will generate you a ZIP you can download and run.
From the same author:
In the same categories: