Style: Incoming backend framework project for Dart.

I need feedback for a new open source backend framework I am writing. Is syntax suitable for the backend, is it understandable? What can I add? What could be the advantages and disadvantages?
I will be happy if you answer questions like these and ask new questions to support this very exciting project for me.

This project is open source. I know there are conflicts(between this article-github) in the documentation. I hope these will be well received, as I am still in development.

GitHub Repository

Pub Package

Join our discord community https://discord.gg/bPcscvBM

You can subscribe to the medium account by e-mail to follow the developments. will not add an article on a topic other than this series and style and all is free-read. First story of series : Exception Handling with Style

Why I Need?

With Flutter, which has become increasingly popular lately, developers have become more familiar with the Dart language. So programmers like me who are not very experienced or are not at senior level in many languages consider meeting their needs with darts as their first choice.

With only the dart language, it is possible to develop the front and back ends of an application together. But there is no framework in the backend like flutter that is as easy to understand, is suitable for community development, and takes advantage of the class structure.

Firebase

Flutter developers use Firebase for many backend services.

Although Firebase has many advantages due to its simplicity, it also brings disadvantages, such as inflexibility of services.

I also had a lot of complaints specifically with Firestore. I’m sure many developers do too. And also there are many problems with the integration of apps with Firebase and google services.

In short, despite all its advantages, Firebase is not suitable for a more professional backend with its inflexibility and pricing policy.

Where did I start?

To meet this need, I needed to develop a framework that was open to community development (with package releases) and had easy integration.

I made the introduction of this framework with a project before.

The project only had controllers that facilitated the following services for my own needs:

• MongoDB Integration
• Query Standardization
• Permission Handler
• Auth
• Db Triggers
• Web Socket
• Cryptography
• Db Stream

I designed these services as interconnected modules. Ultimately, these dependencies resulted in a backend architecture that was difficult to manage and test. In addition, since it was designed entirely for web socket, adding new modules became difficult.

I felt these shortcomings even more when adding a standard error-catching and logging mechanism to my project.

In the end, I got enough motivation for a new framework with an easy and clear syntax from the beginning, and I started.

Flutter Like Syntax

First I needed to set a syntax. In my opinion, a server using this framework should be able to access multiple databases, connect to microservices, and easily manage complex routes. It was also a very flexible structure. Developers should be able to write a service for this framework and publish it for other developers to use.

I reviewed Flutter while trying to create a suitable architecture. I was impressed with the Flutter architecture and wanted to try what a similar architecture would look like for the backend.

Why did I need the Flutter architecture?

First, while developing an interface in flutter, we can divide the code into independent parts as we want, and all these parts work as parts of a large interconnected structure. So each widget just has its own dependencies. But when running, these dependencies work correctly with the dependencies of a parent and a child widget. We are using the same class, require Container) for different views.

But that wasn’t the case with the backend examples I’ve seen. We write a separate function for each route and services, these functions do not have any dependencies on each other. If there are 10 different endpoints on a service, and we need the same controls on 10 of them, we either write a separate function in 10 of them, or at best call the same function 10 times at different points (or add middleware).

Also, if you examine the Flutter source code, we will see a nice structure called ComponentElement(Stateless and Stateful widget’s elements). Although these widgets actually have no effect on rendering, they are a great tool for modular coding.

I also tried to write a backend service with the same architecture. I used Parent-Child structure for route-subroute, BuildContext logic for wrappers(middleware like).

Now I want to share the result I got from the codes with various examples.

I used images in the examples because the Style hasn’t been released yet, and it’s too early to try for now. I don’t think copying is needed. Also, colored codes better express what backend coding looks like with the Style.

Equivalents in Flutter :

• Component: Widget
• Binding : Element
• Calling : RenderObject
• BuildContext : BuildContext

In examples, All classes that do not start with “My” provides from framework.

Define Server :

Handle example.com/foo :

Or:

Use Gateway:

Use route to subroute with Route, and argument path segments:

Stateful-Stateless

Store data with, Stateful Components and Stateful Endpoints.

You can find your states with Key or Type on context

Services

Set default services

Specify Service for part of the server

Reach Service of current context

Gates

Gates like middleware

Gates affect every route and endpoint below it.

There are many gates like MethodFilterGate, SchemaGate, ResponseSchemaGate, PermissionGate or custom Gate.

Triggers

Trigger when request sending to child or response sending to parent.

You can ensure sent or responded.

Manipulate

Redirect

Redirect requests internal or external

Or generate redirect

Exception Handling

Throw exception anywhere:

Set defaults exception endpoints

Specify Exception by Type to routes

Access Point

Easy Endpoints

In the Future:

Firstly, many new gates, redirectors, simple endpoints etc. Let’s consider the features to be added under the main headings.

CLI App

A command line application that will start and run the service. A lot of information about running services can be accessed and changed here.

You will also be able to change basic properties of services and components. For example, you can deactivate or activate children of the gateway or address of redirects or attach or detach services.

Monitoring

An interface with all the capabilities of the command line app and where you can analyze all endpoints, services and their loads.

Role-Based Auth

Auth for server managers. Login monitoring app or CLI with admin and manage service by role owning.

Builder

Builder build services from JSON and build server integrated with angular-dart and docker.

Build Service From JSON like:

{
  "unknown": "BerberUnknownRequest",
  "root": "../home",
  "host": "localhost",
  "port": 9090,
  "rootName" : "berber_server",
  "gateway": [
    {
      "segment": "home",
      "handleUnknownAsRoot": true,
      "root": "MyHomePage",
      "child": {
        "gate": {
          "allowed_agents": [
            "webSocket"
          ]
        },
        "gate_child": {
          "gate": {
            "auth_required": true
          },
          "gate_child": "MySecondEndpoint"
        }
      }
    },

Thanks for reading!

If you give feedback, you will influence the development of the project.

Have a good day!

https://github.com/Mehmetyaz/style/tree/main/packages/style

mehmedyaz@gmail.com